Kullanıcı oturumu VPN üzerindeki SSHFS bağlamasının sahibi olmalı mı?

VPN açıldıktan sonra paylaşılan bir klasörü bağlamak, kolayca karıştırılan iki kimliği içerir: ağı yapılandırma izni olan bileşen ve dosya sunucusuna oturum açma izni olan hesap. Nadiren aynıdırlar. Root'a ait bir VPN kancası, masaüstü kullanıcısının SSHFS bağlamasını başlatmak için kötü bir yerdir çünkü ne kullanıcının aracısına ne de amaçlanan bağlama sahipliğine sahiptir. Sahipliği önce doğru ayarlamak tetikleyiciyi basit hale getirir.

İki kimlik, iki ayrı izin

VPN istemcisinin rotaları ve arayüzleri değiştirmek için ayrıcalıklara ihtiyacı vardır. SSHFS bağlamasının dosya sunucusunun kabul ettiği bir SSH kimliğine ve dosyaları okuyacak hesabın sahip olduğu bir FUSE bağlamasına ihtiyacı vardır. Root olarak çalışan tek bir betik ilk gereksinimi karşılar ve ikincisini sessizce bozar.

Root olarak bağlamak, dosyaları masaüstü oturumunun dışında ve muhtemelen kullanıcının anahtarını tutan aracıya erişim olmadan bırakır. Bağlama vardır, kullanıcı üzerinden yazamaz ve hata sunucu tarafında bir izin sorunu gibi görünür. Bu yanlış teşhis bir öğleden sonraya ve depolama ekibine bir bilete mal olur.

Herhangi bir otomasyon yazmadan önce bağlamanın hangi hesaba ait olduğuna karar verin, çünkü bu seçim tetikleyicinin nerede yaşadığını ve hangi kimlik bilgilerine ulaşabileceğini belirler.

Önce elle kullanıcıya ait bir bağlama kurun

Boş bir bağlama noktası, yetkili bir SSH hesabı ve tünel üzerinden sunucuya çalışan bir yolu olan oturum açmış bir kullanıcıyla başlayın. Elle bağlama, herhangi bir otomasyonun yeniden üretmesi gereken temeli oluşturur.

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

Adlar örnektir, bu yüzden sunucunuzun gerçekte sunduğu ana bilgisayarı ve dışa aktarma yolunu değiştirin. İlk bağlantıda onaylanmış süreç aracılığıyla ana bilgisayar anahtarını doğrulayın. VPN hesabı parolasının otomatik olarak depolama hesabının kimlik bilgisi olmadığını unutmayın ve bu, başarısız denemelerin yaygın bir nedenidir.

Bunu, o kullanıcıya ait bir bağlama noktasıyla normal kullanıcı olarak çalıştırın. Varsayılan olarak dosyalara yalnızca bağlayan hesap ulaşır ve allow_other bu sınırı her yerel kullanıcıya genişletir. Bu, erişimin kasıtlı olarak genişletilmesidir, otomasyon için bir geçici çözüm değildir.

Tetikleyicinin aynı oturum bağlamında hareket etmesine izin verin

Desteklenen VPN olay entegrasyonunun bir kullanıcı oturumu eylemini çalıştırmasını istemesine izin verin, ayrıcalıklı bir geri çağırmanın masaüstü kimlik bilgisini ödünç alabileceğini varsaymak yerine. Tetikleyiciyi rastgele tun0 adını taşıyan herhangi bir arayüz yerine amaçlanan bağlantı tanımlayıcısıyla sınırlayın. Yanlış şeyle eşleşen bir dağıtıcı kuralı, bu bağlamayla ilgisi olmayanlar da dahil olmak üzere her ağ değişikliğinde tetiklenir.

Eylem beklenen ana bilgisayar adını doğrulamalı, mevcut bir bağlamayı fark etmeli ve tek bir sınırlı deneme yapmalıdır. Birkaç saniyede bir yeni bir SSHFS süreci başlatan veya sunucu kapalıyken kimlik bilgisi istemini yineleyen bir yoklama döngüsü, kısa bir kesintiyi bir yığın takılı sürece dönüştürür. Denemeyi bir zaman aşımı ve tek bir yeniden denemeyle sınırlayın.

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

İlk komut, dağıtıcının eşleşmesi gereken bağlantı tanımlayıcısını verir. Diğer ikisi bir denemenin zaten çalışıp çalışmadığını gösterir ve bu, yinelenenleri önleyen kontroldür.

Denetimsiz bir hizmetin kendi yürütme bağlamında kendi onaylanmış kimlik bilgilerine ve kendi ana bilgisayar doğrulamasına ihtiyacı vardır. Grafik bir aracının kilidinin açık olduğunu varsayamaz ve birini açmaya çalışmamalıdır.

Temizliği zorlamadan önce bağlantıyı kesmeyi planlayın

Planlanmış bir bağlantı kesme için dosya işlemlerini bitirin ve bağlayan kullanıcının kendi iş akışından ayırın. Süreç yerine bağlama noktasını hedefleyin ve başarı bildirmeden önce sonucu doğrulayın.

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

Yalnızca bu iş akışının oluşturduğu bağlamayı ayırın. Meşgulse bu bir uygulama kararıdır: bir kancanın başarı döndürmesi için var olan zorunlu ayırma, veri kaybını önlemek yerine gizler.

Beklenmeyen kayıp farklı davranır. SSHFS, bir ağ kesintisinin bir dosya sistemi işlemini engelleyebileceğini ve reconnect seçeneğinin tanıtıcıları geri yüklemeden taşımayı geri yüklediğini belgeler: yeniden bağlanmadan önce açılan bir dosya sonraki yazmada başarısız olabilir ve kesintiye uğrayan yazma korunmaz. Bu fark en çok bir dosyayı saatlerce açık tutan düzenleyiciler için önemlidir. Kurtarmayı varsaymak yerine yeniden açma adımını planlayın.

Davranışı, ona güvenmeden önce tek kullanımlık dosyalarla test edin. Tünel geri geldikten sonra yeniden görünen bir dizin, önceki tanıtıcıların veya kaydedilmemiş çalışmanın hayatta kaldığını kanıtlamaz.