Jak automatycznie zamontować zdalny katalog SSHFS podczas rozruchu w systemie Debian

Konfigurujesz montowanie SSHFS, potwierdzasz jego działanie, restartujesz Debiana i nagle katalog zdalny znów jest pusty. Polecenie ręczne zadziałało, ponieważ byłeś zalogowany, sieć była już online, a SSH mógł zadawać pytania, jeśli potrzebował hasła lub potwierdzenia klucza hosta. Montowanie w czasie rozruchu nie oferuje takich udogodnień.

Niezawodnym rozwiązaniem jest ustawienie uwierzytelniania SSH jako nieinteraktywnego, utworzenie trwałego /etc/fstabwpisu i poinformowanie systemd, że system plików jest zależny od sieci. Ten przewodnik rozpoczyna się od najprostszej działającej konfiguracji, a następnie dodaje opcje dla powolnych sieci i zerwanych sesji SSH. W przykładach użyto user@server.example.com:/srv/datakatalogu zdalnego i /mnt/remotelokalnego punktu montowania.

Strona pakietów Debiana zawiera obecnie listę SSHFS 3.7.3 dla Debiana 12 (Bookworm), a SSHFS korzysta z podsystemu SFTP udostępnianego przez SSH. Więcej informacji można znaleźć na stronie pakietu Debian SSHFS oraz w podręczniku źródłowym SSHFS . Wersje pakietów różnią się w zależności od wydania Debiana, ale poniższa metoda boot-mount opiera się na standardowym zachowaniu fstab i systemd.

Dlaczego montowanie SSHFS działa ręcznie, ale nie udaje się przy rozruchu?

Za większość awarii odpowiadają trzy przyczyny. Po pierwsze, SSH może nadal wymagać podania hasła, frazy kluczowej lub potwierdzenia klucza hosta przy pierwszym uruchomieniu. Zadanie rozruchowe nie ma terminala, na którym mogłoby odpowiedzieć na te monity. Po drugie, montowanie może się rozpocząć, zanim sieć lub DNS będą w pełni użyteczne. Po trzecie, długotrwałe połączenie SSH może później stać się nieaktualne po przerwaniu połączenia sieciowego.

Dokumentacja systemu systemd w Debianie wyjaśnia, że _netdev​​opcja wymusza traktowanie montowania jako montowania sieciowego. Montowania sieciowe są sortowane po network-online.target. Ta sama dokumentacja informuje, że /etc/fstabwpisy są konwertowane na natywne jednostki montowania systemd podczas rozruchu. Zobacz systemd.mount(5) w Debianie .

1. Zainstaluj SSHFS i utwórz punkt montowania

Zainstaluj spakowanego klienta SSHFS i utwórz katalog lokalny, który będzie udostępniał pliki zdalne:

sudo apt update
sudo apt install sshfs
sudo mkdir -p /mnt/remote

SSHFS jest oparty na FUSE, interfejsie systemu plików Linux w przestrzeni użytkownika. W systemie Debian 12 sshfspakiet zależy od FUSE 3 i klienta OpenSSH.

2. Skonfiguruj uwierzytelnianie SSH, które może działać bez monitu

W przypadku montowania całego systemu uruchomionego przez systemd, dedykowany klucz należący do użytkownika root jest prosty, ponieważ pomocnik montowania działa jako użytkownik root. Wygeneruj klucz bez hasła tylko wtedy, gdy sam komputer jest zaufany, a klucz jest przeznaczony wyłącznie do tego celu:

sudo ssh-keygen -t ed25519 -f /root/.ssh/sshfs_remote
sudo ssh-copy-id -i /root/.ssh/sshfs_remote.pub user@server.example.com

Drugie polecenie zazwyczaj prosi o podanie hasła do konta zdalnego raz. Następnie sprawdza dokładną tożsamość w trybie nieinteraktywnym:

sudo ssh -i /root/.ssh/sshfs_remote -o BatchMode=yes user@server.example.com true

Jeśli polecenie zakończy się pomyślnie bez monitu, uwierzytelnianie jest gotowe do uruchomienia. Jeśli pojawi się prośba o potwierdzenie odcisku palca serwera, połącz się raz interaktywnie jako root, zweryfikuj odcisk palca z zaufanym źródłem i zaakceptuj go. Nie należy obchodzić błędów klucza hosta, wyłączając weryfikację hosta.

Dokumenty OpenSSH BatchMode=yesprzeznaczone specjalnie dla skryptów i zadań wsadowych, ponieważ wyłączają monity o podanie hasła i potwierdzenie. Klucze hosta są sprawdzane z plikiem użytkownika known_hosts. Zobacz podręcznik Debian ssh(1) i ssh_config(5) .

3. Przed edycją pliku fstab potwierdź ręcznie podłączenie SSHFS

Nie debuguj kolejności rozruchu, dopóki podstawowe polecenie SSHFS nie zadziała. Zamontuj katalog raz, używając tego samego klucza:

sudo sshfs user@server.example.com:/srv/data /mnt/remote   -o IdentityFile=/root/.ssh/sshfs_remote   -o reconnect   -o ServerAliveInterval=15   -o ServerAliveCountMax=3

Sprawdź, czy możesz wyświetlić listę plików zdalnych, a następnie odmontuj je przed testowaniem fstab:

ls -la /mnt/remote
sudo fusermount3 -u /mnt/remote

Podręcznik SSHFS zaleca reconnectponowne nawiązywanie przerwanych połączeń. Wyjaśnia również, że ServerAliveIntervalmożna zapobiec pozornemu zawieszeniu się połączenia, gdy bezczynne połączenie SSH zostanie bezgłośnie zerwane. Przy interwale 15 sekund i domyślnej liczbie trzech nieodpowiedzianych prób w OpenSSH, niedziałające połączenie jest wykrywane w ciągu około 45 sekund; w tym przypadku liczba ta jest podana jawnie, aby zachowanie było oczywiste.

4. Dodaj trwały wpis SSHFS do /etc/fstab

Przed edycją pliku wykonaj jego kopię zapasową:

sudo cp /etc/fstab /etc/fstab.backup
sudo nano /etc/fstab

Dodaj jedną linię:

user@server.example.com:/srv/data /mnt/remote fuse.sshfs _netdev,IdentityFile=/root/.ssh/sshfs_remote,BatchMode=yes,reconnect,ServerAliveInterval=15,ServerAliveCountMax=3,default_permissions 0 0

Podtyp fuse.sshfsjest rozpoznawany przez narzędzia montowania Debiana. Podręcznik SSHFS w systemie źródłowym również opisuje sshfstyp systemu plików fstab oraz uwagi dotyczące kompatybilności. Podręcznik fstab(5)fuse.sshfs Debiana opisuje sześć pól fstab i zaleca notację podtypu systemu plików, taką jak .fuse.sshfs

5. Przetestuj wpis fstab przed ponownym uruchomieniem

Literówkę /etc/fstabznacznie łatwiej naprawić przed ponownym uruchomieniem. Poproś systemd o ponowne załadowanie wygenerowanych jednostek montowania, a następnie przetestuj wpis:

sudo systemctl daemon-reload
sudo mount -a
findmnt -T /mnt/remote
ls -la /mnt/remote

Jeśli mount -anie zwróci błędu i findmntzgłosi , składnia fstab zostanie zaakceptowana, a system plików zostanie zamontowany. Podręcznik mount(8)fuse.sshfs Debiana potwierdza, że ​​montuje systemy plików fstab z wyjątkiem wpisów oznaczonych .mount -anoauto

A co jeśli sieć nie będzie gotowa wystarczająco szybko?

_netdevSystemd zapewnia poprawną semantykę kolejności, ale network-online.targetjej dokładność zależy od usługi zarządzania siecią, która ją udostępnia. Wi-Fi, VPN, opóźnienia DHCP i DNS oraz nietypowe stosy sieciowe mogą nadal sprawiać, że natychmiastowe montowanie systemu w trybie rozruchowym będzie niepewne.

W takim przypadku użyj automatycznego montowania systemd, aby proces rozruchu utworzył punkt automatycznego montowania i nawiązał połączenie SSHFS tylko wtedy, gdy coś po raz pierwszy uzyska do niego dostęp /mnt/remote. Dodaj x-systemd.automountdo opcji:

user@server.example.com:/srv/data /mnt/remote fuse.sshfs _netdev,x-systemd.automount,IdentityFile=/root/.ssh/sshfs_remote,BatchMode=yes,reconnect,ServerAliveInterval=15,ServerAliveCountMax=3,default_permissions 0 0

Często jest to lepszy wybór w przypadku laptopów, systemów Wi-Fi lub serwerów, gdzie zdalny host może być czasami niedostępny. Nieznacznie zmienia to semantykę: automount jest przygotowywany podczas rozruchu, ale faktyczne połączenie SSH jest nawiązywane przy pierwszym dostępie. Jeśli aplikacja bezwzględnie wymaga połączenia ze zdalnym katalogiem przed uruchomieniem, należy zachować standardowe montowanie sieciowe i ustawić jednostkę systemd tej aplikacji jako zależną od jednostki montowania.

Czy potrzebujesz allow_other?

Domyślnie montowanie FUSE jest dostępne tylko z uprawnieniami powiązanymi z kontekstem montowania. W podręczniku SSHFS opisano allow_other, jak zezwolić na dostęp innym użytkownikom lokalnym. Nie dodawaj tego, chyba że usługa lub inne konto rzeczywiście potrzebuje zamontowanych plików.

Jeśli korzystasz z allow_other, zapoznaj się /etc/fuse.confnajpierw z implikacjami bezpieczeństwa FUSE. Połączenie go z default_permissionsjest zazwyczaj odpowiednie, aby lokalne sprawdzanie uprawnień w systemie Unix nie zostało pominięte. Zdalne konto SSH ostatecznie decyduje o tym, jakie operacje serwer dopuszcza.

Rozwiązywanie problemów z błędami SSHFS podczas rozruchu

Wierzchowiec czeka na hasło

Powtórz dokładny test nieinteraktywny z sudo ssh ... -o BatchMode=yes. Jeśli się nie powiedzie, popraw uwierzytelnianie kluczem publicznym przed dotknięciem systemd. Klucz chroniony hasłem będzie również wymagał agenta lub innego mechanizmu szyfrowania w czasie rozruchu; zwykły montowanie fstab nie wpisze hasła za Ciebie.

Weryfikacja klucza hosta nie powiodła się

Nie ustawiaj tego StrictHostKeyChecking=nojako rozwiązania ogólnego. Sprawdź, czy serwer został przebudowany lub czy jego klucz hosta został legalnie zmieniony. Sprawdzanie klucza hosta SSH to zabezpieczenie przed podszywaniem się i atakami typu man-in-the-middle.

Montaż działa po zalogowaniu, ale nie podczas rozruchu

Sprawdź wygenerowaną nazwę jednostki i jej dziennik. W przypadku /mnt/remote, systemd zazwyczaj zmienia ścieżkę na mnt-remote.mount:

systemctl status mnt-remote.mount
journalctl -b -u mnt-remote.mount

Jeżeli dodałeś x-systemd.automount, sprawdź także:

systemctl status mnt-remote.automount

Dostęp zawiesza się po zniknięciu serwera lub sieci

Włączono opcje Keep reconnecti SSH keepalive. Podręcznik SSHFS ostrzega, że ​​operacje na systemie plików mogą być blokowane na czas nieokreślony, jeśli zerwane połączenie nie zostanie wykryte. Keepalive ograniczają wykrywanie awarii, ale każde wejście/wyjście, które było w toku w momencie zerwania połączenia, może nadal zakończyć się niepowodzeniem i wymagać ponownego uruchomienia przez aplikację.

Jak sprawdzić, czy mocowanie rzeczywiście przetrwa ponowne uruchomienie

Po mount -apomyślnym wykonaniu tej czynności należy ponownie uruchomić komputer:

sudo reboot

Po ponownym połączeniu wykonaj następujące sprawdzenia:

findmnt -T /mnt/remote
systemctl is-active mnt-remote.mount
ls -la /mnt/remote

Jeśli wybierzesz x-systemd.automount, jednostka montowania może być nieaktywna do pierwszego dostępu. Najpierw sprawdź automontowanie, a następnie uruchom je za pomocą ls:

systemctl is-active mnt-remote.automount
ls -la /mnt/remote
findmnt -T /mnt/remote

Pomyślna konfiguracja ma cztery obserwowalne właściwości: uwierzytelnianie SSH kończy się bez interakcji, wpis fstab jest prawidłowy mount -a, systemd rozpoznaje montowanie jako zależne od sieci, a pliki zdalne są dostępne po ponownym uruchomieniu. Jeśli którakolwiek z tych kontroli się nie powiedzie, należy rozwiązać problem bezpośrednio na tej warstwie, zamiast losowo dodawać kolejne opcje montowania.