Czy sesja użytkownika powinna posiadać montowanie SSHFS przez VPN?

Montowanie udostępnionego folderu po podniesieniu VPN obejmuje dwie tożsamości, które łatwo pomylić: komponent uprawniony do konfigurowania sieci oraz konto uprawnione do logowania się na serwer plików. Rzadko są tym samym. Hak VPN należący do roota to złe miejsce na rozpoczęcie montowania SSHFS użytkownika pulpitu, ponieważ nie ma ani agenta użytkownika, ani zamierzonego właścicielstwa montowania. Ustalenie najpierw właściwego właścicielstwa upraszcza wyzwalacz.

Dwie tożsamości, dwa odrębne uprawnienia

Klient VPN potrzebuje uprawnień do zmiany tras i interfejsów. Montowanie SSHFS potrzebuje tożsamości SSH akceptowanej przez serwer plików oraz montowania FUSE należącego do konta, które będzie czytać pliki. Jeden skrypt uruchamiany jako root spełnia pierwszy wymóg i po cichu łamie drugi.

Montowanie jako root pozostawia pliki poza sesją pulpitu i być może bez dostępu do agenta przechowującego klucz użytkownika. Montowanie istnieje, użytkownik nie może przez nie pisać, a awaria wygląda na problem uprawnień po stronie serwera. Ta błędna diagnoza kosztuje popołudnie i zgłoszenie do zespołu przechowywania.

Zdecyduj, które konto posiada montowanie, zanim napiszesz jakąkolwiek automatyzację, ponieważ ten wybór decyduje, gdzie mieszka wyzwalacz i do jakich poświadczeń może dotrzeć.

Najpierw ręcznie ustanów montowanie należące do użytkownika

Zacznij od zalogowanego użytkownika z pustym punktem montowania, autoryzowanym kontem SSH i działającą ścieżką do serwera przez tunel. Ręczne montowanie ustala podstawę, którą musi odtworzyć każda automatyzacja.

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

Nazwy są przykładami, więc zastąp hosta i ścieżkę eksportu, które twój serwer rzeczywiście oferuje. Zweryfikuj klucz hosta przez zatwierdzony proces przy tym pierwszym połączeniu. Pamiętaj, że hasło konta VPN nie jest automatycznie poświadczeniem konta przechowywania, i jest to częsta przyczyna nieudanych prób.

Uruchom to jako zwykły użytkownik z punktem montowania należącym do tego użytkownika. Domyślnie tylko konto montujące dociera do plików, a allow_other rozszerza tę granicę na każdego lokalnego użytkownika. To celowe rozszerzenie dostępu, a nie obejście dla automatyzacji.

Pozwól wyzwalaczowi działać w tym samym kontekście sesji

Pozwól obsługiwanej integracji zdarzeń VPN poprosić o uruchomienie akcji sesji użytkownika, zamiast zakładać, że uprzywilejowany callback może pożyczyć poświadczenie pulpitu. Ogranicz wyzwalacz do zamierzonego identyfikatora połączenia, a nie do dowolnego interfejsu, który przypadkiem nazywa się tun0. Reguła dyspozytora dopasowana do niewłaściwej rzeczy uruchamia się przy każdej zmianie sieci, w tym przy tych, które nie mają nic wspólnego z tym montowaniem.

Akcja powinna potwierdzić oczekiwaną nazwę hosta, zauważyć istniejące montowanie i wykonać jedną ograniczoną próbę. Pętla odpytywania, która co kilka sekund uruchamia nowy proces SSHFS lub powtarza prośbę o poświadczenia, gdy serwer jest niedostępny, zamienia krótką awarię w stos zawieszonych procesów. Ogranicz próbę limitem czasu i jednym ponowieniem.

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

Pierwsze polecenie podaje identyfikator połączenia, do którego dyspozytor powinien dopasować. Pozostałe dwa pokazują, czy próba już trwa, i to jest kontrola, która zapobiega duplikatom.

Nienadzorowana usługa potrzebuje własnych zatwierdzonych poświadczeń i własnej weryfikacji hosta we własnym kontekście wykonania. Nie może zakładać, że agent graficzny jest odblokowany, i nie powinna próbować go odblokować.

Zaplanuj rozłączenie, zanim wymusisz czyszczenie

W przypadku planowanego rozłączenia dokończ operacje na plikach i odmontuj z własnego przepływu pracy użytkownika montującego. Celuj w punkt montowania, a nie w proces, i potwierdź wynik, zanim zgłosisz sukces.

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

Odmontuj tylko montowanie utworzone przez ten przepływ pracy. Jeśli jest zajęte, to decyzja aplikacji: wymuszone odłączenie, które istnieje po to, by hak zwrócił sukces, ukrywa utratę danych zamiast jej zapobiegać.

Nieoczekiwana utrata zachowuje się inaczej. SSHFS dokumentuje, że przerwa w sieci może zablokować operację systemu plików, a opcja reconnect przywraca transport bez przywracania uchwytów: plik otwarty przed ponownym połączeniem może zawieść przy następnym zapisie, a przerwany zapis nie jest zachowywany. Ta różnica ma największe znaczenie dla edytorów, którzy trzymają jeden plik otwarty godzinami. Zaplanuj krok ponownego otwarcia zamiast zakładać odzyskanie.

Przetestuj zachowanie na plikach jednorazowych, zanim na nim polegniesz. Katalog, który pojawia się ponownie po powrocie tunelu, nie dowodzi, że wcześniejsze uchwyty lub niezapisana praca przetrwały.