Haruskah sesi pengguna memiliki mount SSHFS melalui VPN?

Me-mount folder bersama setelah VPN aktif melibatkan dua identitas yang mudah dikacaukan: komponen yang diizinkan mengonfigurasi jaringan, dan akun yang diizinkan masuk ke server file. Keduanya jarang sama. Hook VPN milik root adalah tempat yang buruk untuk memulai mount SSHFS pengguna desktop, karena tidak memiliki agen pengguna maupun kepemilikan mount yang dimaksud. Menetapkan kepemilikan dengan benar lebih dulu membuat pemicu menjadi sederhana.

Dua identitas, dua izin terpisah

Klien VPN membutuhkan hak istimewa untuk mengubah rute dan antarmuka. Mount SSHFS membutuhkan identitas SSH yang diterima server file dan mount FUSE milik akun yang akan membaca file. Satu skrip yang berjalan sebagai root memenuhi syarat pertama dan diam-diam melanggar syarat kedua.

Me-mount sebagai root meninggalkan file di luar sesi desktop dan mungkin tanpa akses ke agen yang menyimpan kunci pengguna. Mount ada, pengguna tidak dapat menulis melaluinya, dan kegagalan tampak seperti masalah izin di sisi server. Salah diagnosis itu memakan waktu satu sore dan tiket ke tim penyimpanan.

Putuskan akun mana yang memiliki mount sebelum menulis otomatisasi apa pun, karena pilihan itu menentukan di mana pemicu berada dan kredensial apa yang dapat dijangkau.

Siapkan dulu mount milik pengguna secara manual

Mulailah dari pengguna yang sudah masuk dengan titik mount kosong, akun SSH yang diotorisasi, dan jalur yang berfungsi ke server melalui terowongan. Mount manual menetapkan garis dasar yang harus direproduksi oleh otomatisasi apa pun.

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

Namanya adalah contoh, jadi ganti host dan jalur ekspor yang benar-benar ditawarkan server Anda. Verifikasi kunci host melalui proses yang disetujui pada koneksi pertama itu. Perhatikan bahwa kata sandi akun VPN tidak otomatis menjadi kredensial akun penyimpanan, dan itu penyebab umum percobaan yang gagal.

Jalankan sebagai pengguna biasa dengan titik mount yang dimiliki pengguna itu. Secara default hanya akun yang me-mount yang mencapai file, dan allow_other memperluas batas itu ke setiap pengguna lokal. Itu adalah perluasan akses yang disengaja, bukan jalan pintas untuk otomatisasi.

Biarkan pemicu bertindak dalam konteks sesi yang sama

Biarkan integrasi peristiwa VPN yang didukung meminta tindakan sesi pengguna dijalankan, alih-alih menganggap callback istimewa dapat meminjam kredensial desktop. Batasi pemicu ke pengenal koneksi yang dimaksud, bukan ke antarmuka apa pun yang kebetulan bernama tun0. Aturan pengirim yang cocok dengan hal yang salah menyala pada setiap perubahan jaringan, termasuk yang tidak ada hubungannya dengan mount ini.

Tindakan harus mengonfirmasi nama host yang diharapkan, menyadari mount yang ada, dan melakukan satu upaya terbatas. Loop jajak pendapat yang memulai proses SSHFS baru setiap beberapa detik, atau mengulang permintaan kredensial saat server mati, mengubah gangguan singkat menjadi tumpukan proses macet. Batasi upaya dengan batas waktu dan satu percobaan ulang.

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

Perintah pertama memberi pengenal koneksi yang harus dicocokkan oleh pengirim. Dua lainnya menunjukkan apakah upaya sudah berjalan, dan itulah pemeriksaan yang mencegah duplikat.

Layanan tanpa pengawasan membutuhkan kredensial yang disetujui sendiri dan pengaturan verifikasi host sendiri dalam konteks eksekusinya sendiri. Layanan itu tidak dapat menganggap agen grafis tidak terkunci, dan tidak boleh mencoba membuka kuncinya.

Rencanakan pemutusan sebelum memaksa pembersihan

Untuk pemutusan yang direncanakan, selesaikan operasi file dan lepaskan dari alur kerja pengguna yang me-mount itu sendiri. Sasaran titik mount, bukan prosesnya, dan konfirmasi hasilnya sebelum melaporkan keberhasilan.

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

Lepaskan hanya mount yang dibuat alur kerja ini. Jika sedang sibuk, itu keputusan aplikasi: pelepasan paksa yang ada untuk membuat hook mengembalikan keberhasilan menyembunyikan kehilangan data alih-alih mencegahnya.

Kehilangan tak terduga berperilaku berbeda. SSHFS mendokumentasikan bahwa gangguan jaringan dapat memblokir operasi sistem file, dan opsi reconnect memulihkan transport tanpa memulihkan handle: file yang dibuka sebelum penyambungan ulang dapat gagal pada penulisan berikutnya, dan penulisan yang terputus tidak dipertahankan. Perbedaan itu paling penting bagi editor yang membiarkan satu file terbuka selama berjam-jam. Rencanakan langkah pembukaan ulang alih-alih menganggap pemulihan.

Uji perilakunya dengan file sekali pakai sebelum mengandalkannya. Direktori yang muncul kembali setelah terowongan kembali tidak membuktikan bahwa handle sebelumnya atau pekerjaan yang belum disimpan selamat.