Patutkah sesi pengguna memiliki mount SSHFS melalui VPN?

Me-mount folder dikongsi selepas VPN naik melibatkan dua identiti yang mudah dikelirukan: komponen yang dibenarkan mengkonfigurasi rangkaian, dan akaun yang dibenarkan log masuk ke pelayan fail. Kedua-duanya jarang sama. Hook VPN milik root ialah tempat yang buruk untuk memulakan mount SSHFS pengguna desktop, kerana ia tidak mempunyai ejen pengguna mahupun pemilikan mount yang dimaksudkan. Menetapkan pemilikan dengan betul dahulu menjadikan pencetus mudah.

Dua identiti, dua kebenaran berasingan

Klien VPN memerlukan keistimewaan untuk menukar laluan dan antara muka. Mount SSHFS memerlukan identiti SSH yang diterima pelayan fail dan mount FUSE milik akaun yang akan membaca fail. Satu skrip yang berjalan sebagai root memenuhi syarat pertama dan memecahkan yang kedua secara senyap.

Me-mount sebagai root meninggalkan fail di luar sesi desktop dan mungkin tanpa akses kepada ejen yang memegang kunci pengguna. Mount wujud, pengguna tidak boleh menulis melaluinya, dan kegagalan kelihatan seperti masalah kebenaran di pihak pelayan. Salah diagnosis itu memakan satu petang dan tiket kepada pasukan storan.

Tentukan akaun mana yang memiliki mount sebelum menulis sebarang automasi, kerana pilihan itu menentukan di mana pencetus berada dan kelayakan apa yang boleh dicapainya.

Sediakan dahulu mount milik pengguna secara manual

Mulakan dengan pengguna yang telah log masuk dengan titik mount kosong, akaun SSH yang dibenarkan dan laluan berfungsi ke pelayan melalui terowong. Mount manual menetapkan garis dasar yang mesti dihasilkan semula oleh mana-mana automasi.

mkdir -p "$HOME/mnt/team"
sshfs [email protected]:/exports/team "$HOME/mnt/team"
mount | grep sshfs

Nama ialah contoh, jadi gantikan hos dan laluan eksport yang benar-benar ditawarkan pelayan anda. Sahkan kunci hos melalui proses yang diluluskan pada sambungan pertama itu. Perhatikan bahawa kata laluan akaun VPN bukan secara automatik kelayakan akaun storan, dan itu punca biasa percubaan yang gagal.

Jalankannya sebagai pengguna biasa dengan titik mount yang dimiliki pengguna itu. Secara lalai hanya akaun yang me-mount mencapai fail, dan allow_other meluaskan sempadan itu kepada setiap pengguna tempatan. Itu ialah peluasan akses yang disengajakan, bukan jalan pintas untuk automasi.

Biarkan pencetus bertindak dalam konteks sesi yang sama

Biarkan integrasi peristiwa VPN yang disokong meminta tindakan sesi pengguna dijalankan, bukannya menganggap callback istimewa boleh meminjam kelayakan desktop. Hadkan pencetus kepada pengecam sambungan yang dimaksudkan dan bukan kepada mana-mana antara muka yang kebetulan bernama tun0. Peraturan penghantar yang sepadan dengan perkara yang salah menyala pada setiap perubahan rangkaian, termasuk yang tiada kaitan dengan mount ini.

Tindakan itu harus mengesahkan nama hos yang dijangka, menyedari mount sedia ada dan membuat satu percubaan terbatas. Gelung tinjauan yang memulakan proses SSHFS baharu setiap beberapa saat, atau mengulang permintaan kelayakan semasa pelayan mati, mengubah gangguan singkat menjadi longgokan proses tersekat. Hadkan percubaan dengan had masa dan satu percubaan semula.

nmcli -g UUID connection show --active
systemctl --user list-units 'sshfs*'
pgrep -a sshfs

Perintah pertama memberikan pengecam sambungan yang perlu dipadankan oleh penghantar. Dua lagi menunjukkan sama ada percubaan sudah berjalan, dan itulah pemeriksaan yang menghalang pertindihan.

Perkhidmatan tanpa pengawasan memerlukan kelayakan yang diluluskan sendiri dan pengesahan hos sendiri dalam konteks pelaksanaannya sendiri. Ia tidak boleh menganggap ejen grafik tidak berkunci, dan tidak patut cuba membuka kuncinya.

Rancang pemutusan sebelum memaksa pembersihan

Untuk pemutusan yang dirancang, selesaikan operasi fail dan lepaskan mount daripada aliran kerja pengguna yang me-mount itu sendiri. Sasarkan titik mount dan bukan proses, dan sahkan hasilnya sebelum melaporkan kejayaan.

fusermount3 -u "$HOME/mnt/team"
mountpoint "$HOME/mnt/team"

Lepaskan hanya mount yang dicipta oleh aliran kerja ini. Jika ia sibuk, itu keputusan aplikasi: pelepasan paksa yang wujud untuk membuat hook mengembalikan kejayaan menyembunyikan kehilangan data dan bukannya menghalangnya.

Kehilangan tidak dijangka berkelakuan berbeza. SSHFS mendokumenkan bahawa gangguan rangkaian boleh menyekat operasi sistem fail, dan pilihan reconnect memulihkan pengangkutan tanpa memulihkan pengendali: fail yang dibuka sebelum sambungan semula mungkin gagal pada penulisan seterusnya, dan penulisan yang terganggu tidak dipelihara. Perbezaan itu paling penting bagi editor yang membiarkan satu fail terbuka berjam-jam. Rancang langkah pembukaan semula dan bukannya menganggap pemulihan.

Uji kelakuan dengan fail sekali guna sebelum bergantung padanya. Direktori yang muncul semula selepas terowong kembali tidak membuktikan bahawa pengendali terdahulu atau kerja yang tidak disimpan terselamat.