Wie man ein entferntes SSHFS-Verzeichnis beim Systemstart in Debian automatisch einbindet

Sie konfigurieren eine SSHFS-Einbindung, überprüfen deren Funktion, starten Debian neu und plötzlich ist das Remote-Verzeichnis wieder leer. Der manuelle Befehl funktionierte, weil Sie angemeldet waren, das Netzwerk bereits bestand und SSH bei Bedarf eine Passwort- oder Host-Key-Bestätigung anfordern konnte. Einbindungen beim Systemstart bieten diese Vorteile nicht.

Die zuverlässige Lösung besteht darin, die SSH-Authentifizierung nicht-interaktiv zu gestalten, einen persistenten /etc/fstabEintrag zu erstellen und systemd mitzuteilen, dass das Dateisystem vom Netzwerk abhängt. Diese Anleitung beginnt mit der einfachsten funktionierenden Konfiguration und ergänzt diese um Optionen für langsame Netzwerke und unterbrochene SSH-Sitzungen. In den Beispielen wird user@server.example.com:/srv/dataals Remote-Verzeichnis und /mnt/remoteals lokaler Mountpunkt verwendet.

Die Debian-Paketseite listet derzeit SSHFS 3.7.3 für Debian 12 (Bookworm) auf. SSHFS nutzt das von SSH bereitgestellte SFTP-Subsystem. Siehe die Debian-SSHFS-Paketseite und das zugehörige SSHFS-Handbuch . Die Paketversionen variieren je nach Debian-Version, die unten beschriebene Methode zum Einbinden beim Systemstart basiert jedoch auf dem Standardverhalten von fstab und systemd.

Warum funktioniert die SSHFS-Einbindung manuell, schlägt aber beim Systemstart fehl?

Drei Ursachen sind für die meisten Fehler verantwortlich. Erstens kann SSH weiterhin ein Passwort, eine Passphrase oder eine erstmalige Bestätigung des Host-Schlüssels erfordern. Ein Bootvorgang verfügt über kein Terminal, in dem er diese Eingabeaufforderungen beantworten kann. Zweitens kann der Mountvorgang beginnen, bevor Netzwerk oder DNS vollständig verfügbar sind. Drittens kann eine langjährige SSH-Verbindung nach einer Netzwerkunterbrechung ungültig werden.

Die systemd-Dokumentation von Debian erklärt, dass diese _netdevOption erzwingt, dass ein Mount als Netzwerk-Mount behandelt wird. Netzwerk-Mounts werden nach dem Mounten eingeordnet network-online.target. Dieselbe Dokumentation merkt an, dass /etc/fstabEinträge beim Systemstart in native systemd-Mount-Units umgewandelt werden. Siehe systemd.mount(5) in Debian .

1. Installieren Sie SSHFS und erstellen Sie den Mountpunkt.

Installieren Sie den mitgelieferten SSHFS-Client und erstellen Sie das lokale Verzeichnis, das die Remote-Dateien freigibt:

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

SSHFS basiert auf FUSE, der Linux-Dateisystemschnittstelle für den Benutzermodus. Unter Debian 12 sshfsbenötigt das Paket FUSE 3 und den OpenSSH-Client.

2. Richten Sie eine SSH-Authentifizierung ein, die ohne Eingabeaufforderung ausgeführt werden kann.

Bei einer systemweiten Einbindung, die von systemd gestartet wird, ist ein dedizierter Schlüssel im Besitz von root unkompliziert, da der Einbindungshelfer als root ausgeführt wird. Generieren Sie einen Schlüssel ohne Passphrase nur dann, wenn der Rechner selbst vertrauenswürdig ist und der Schlüssel ausschließlich für diesen Zweck bestimmt ist.

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

Der zweite Befehl fragt normalerweise einmal nach dem Passwort des Remote-Kontos. Anschließend wird die genaue Identität nicht-interaktiv überprüft:

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

Wird dieser Befehl ohne Eingabeaufforderung erfolgreich ausgeführt, ist die Authentifizierung für den Systemstart bereit. Falls Sie zur Bestätigung des Server-Fingerabdrucks aufgefordert werden, stellen Sie einmal interaktiv als Root eine Verbindung her, überprüfen Sie den Fingerabdruck anhand einer vertrauenswürdigen Quelle und akzeptieren Sie ihn. Deaktivieren Sie die Host-Verifizierung nicht, um Host-Key-Fehler zu umgehen.

OpenSSH ist BatchMode=yesspeziell für Skripte und Batch-Jobs dokumentiert, da es Passwort- und Bestätigungsabfragen deaktiviert. Host-Schlüssel werden mit der Benutzerdatei abgeglichen known_hosts. Siehe das Debian-Handbuch ssh(1) und ssh_config(5) .

3. Überprüfen Sie die SSHFS-Einbindung manuell, bevor Sie die fstab bearbeiten.

Die Bootreihenfolge sollte erst dann überprüft werden, wenn der grundlegende SSHFS-Befehl funktioniert. Das Verzeichnis muss einmalig mit demselben Schlüssel eingebunden werden.

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

Prüfen Sie, ob Sie die Remote-Dateien auflisten können, und hängen Sie das Laufwerk dann aus, bevor Sie fstab testen:

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

Das offizielle SSHFS-Handbuch empfiehlt Maßnahmen reconnectzur Wiederherstellung unterbrochener Verbindungen. Es erklärt auch, dass dies ServerAliveIntervalein scheinbar eingefrorenes Mounten verhindern kann, wenn eine inaktive SSH-Verbindung stillschweigend getrennt wird. Bei einem Intervall von 15 Sekunden und der standardmäßigen OpenSSH-Anzahl von drei unbeantworteten Anfragen wird eine unterbrochene Verbindung nach etwa 45 Sekunden erkannt; die Anzahl wird hier explizit angegeben, um das Verhalten zu verdeutlichen.

4. Fügen Sie einen permanenten SSHFS-Eintrag zu /etc/fstab hinzu.

Sichern Sie die Datei, bevor Sie sie bearbeiten:

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

Füge eine Zeile hinzu:

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

Der fuse.sshfsSubtyp wird von den Mount-Tools von Debian erkannt. Das zugehörige SSHFS-Handbuch dokumentiert ihn ebenfalls sshfsals fstab-Dateisystemtyp und gibt Hinweise zur Kompatibilität. Das fstab(5)-Handbuchfuse.sshfs von Debian beschreibt die sechs fstab-Felder und empfiehlt die Verwendung von Dateisystem-Subtyp-Notation wie z . B. .fuse.sshfs

5. Überprüfen Sie den fstab-Eintrag vor dem Neustart.

Ein Tippfehler /etc/fstablässt sich vor einem Neustart viel einfacher beheben. Weisen Sie systemd an, die generierten Mount-Units neu zu laden, und testen Sie dann den Eintrag:

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

Wenn mount -akein Fehler zurückgegeben wird und findmnteine Meldung erscheint fuse.sshfs, wird die fstab-Syntax akzeptiert und das Dateisystem wird eingebunden. Das Debian- Handbuch mount(8) bestätigt, dass mount -afstab-Dateisysteme mit Ausnahme der mit gekennzeichneten Einträge eingebunden werden noauto.

Was passiert, wenn das Netzwerk nicht rechtzeitig bereit ist?

_netdevSystemd erhält zwar die korrekte Reihenfolgessemantik, network-online.targetist aber nur so genau wie der Netzwerkverwaltungsdienst, der sie bereitstellt. WLAN, VPNs, DHCP- und DNS-Verzögerungen sowie ungewöhnliche Netzwerkarchitekturen können ein sofortiges Boot-Mounten weiterhin unzuverlässig machen.

Verwenden Sie in diesem Fall systemd-Automounting, sodass der Bootvorgang einen Automount-Punkt erstellt und die SSHFS-Verbindung erst herstellt, wenn zum ersten Mal darauf zugegriffen wird /mnt/remote. Fügen Sie Folgendes x-systemd.automountzu den Optionen hinzu:

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

Dies ist oft die bessere Wahl für Laptops, WLAN-Systeme oder Server, bei denen der Remote-Host gelegentlich nicht erreichbar sein kann. Die Semantik ändert sich dadurch geringfügig: Die automatische Einbindung wird beim Systemstart vorbereitet, die eigentliche SSH-Verbindung wird jedoch erst beim ersten Zugriff hergestellt. Benötigt eine Anwendung unbedingt eine Verbindung zum Remote-Verzeichnis vor dem Start, sollte die normale Netzwerkeinbindung beibehalten und die Systemd-Unit der Anwendung stattdessen von der Einbindungseinheit abhängig gemacht werden.

Benötigen Sie allow_other?

Standardmäßig ist ein FUSE-Mount nur mit den Berechtigungen zugänglich, die dem Mount-Kontext zugeordnet sind. Das SSHFS-Handbuch beschreibt allow_other, wie der Zugriff für andere lokale Benutzer ermöglicht wird. Fügen Sie ihn nur dann hinzu, wenn ein Dienst oder ein anderes Benutzerkonto die gemounteten Dateien unbedingt benötigt.

Wenn Sie es verwenden allow_other, prüfen Sie /etc/fuse.confvorher die Sicherheitsauswirkungen von FUSE. Die Kombination mit default_permissionsist im Allgemeinen sinnvoll, damit lokale Unix-Berechtigungsprüfungen nicht übersprungen werden. Das Remote-SSH-Konto bestimmt letztendlich weiterhin, welche Operationen der Server zulässt.

Fehlerbehebung bei SSHFS-Fehlern während des Systemstarts

Die Mount-Funktion wartet auf ein Passwort.

Wiederholen Sie den nicht-interaktiven Test sudo ssh ... -o BatchMode=yes. Falls er fehlschlägt, beheben Sie die Probleme mit der Public-Key-Authentifizierung, bevor Sie systemd ändern. Ein durch eine Passphrase geschützter Schlüssel benötigt außerdem einen Agenten oder einen anderen Mechanismus zur Geheimhaltung beim Systemstart; eine einfache Einbindung über die fstab kann die Passphrase nicht automatisch eingeben.

Überprüfung des Host-Schlüssels fehlgeschlagen

Diese Maßnahme sollte nicht StrictHostKeyChecking=nopauschal angewendet werden. Prüfen Sie, ob der Server neu aufgesetzt oder sein Host-Schlüssel rechtmäßig geändert wurde. Die Überprüfung des SSH-Host-Schlüssels dient der Sicherheit gegen Identitätsdiebstahl und Man-in-the-Middle-Angriffe.

Die Einbindung funktioniert nach dem Anmelden, aber nicht während des Systemstarts.

Überprüfen Sie den generierten Unit-Namen und sein Journal. Für /mnt/remotesystemd wird der Pfad zu mnt-remote.mount: normalerweise maskiert.

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

Wenn Sie etwas hinzugefügt haben x-systemd.automount, überprüfen Sie auch Folgendes:

systemctl status mnt-remote.automount

Der Zugriff ist nicht mehr möglich, nachdem der Server oder das Netzwerk ausgefallen ist.

Keepalives reconnectund SSH-Keepalives sind aktiviert. Das offizielle SSHFS-Handbuch warnt davor, dass Dateisystemoperationen unbegrenzt blockieren können, wenn eine unterbrochene Verbindung nicht erkannt wird. Keepalives begrenzen die Fehlererkennung, jedoch können alle E/A-Operationen, die zum Zeitpunkt des Verbindungsabbruchs liefen, weiterhin fehlschlagen und müssen gegebenenfalls von der Anwendung wiederholt werden.

Wie man überprüft, ob die Halterung einen Neustart tatsächlich übersteht.

Nach mount -aerfolgreichem Abschluss starten Sie den Rechner neu:

sudo reboot

Führen Sie nach der Wiederherstellung der Verbindung folgende Prüfungen durch:

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

Wenn Sie diese Option gewählt haben x-systemd.automount, ist die Mount-Einheit möglicherweise bis zum ersten Zugriff inaktiv. Überprüfen Sie zuerst die automatische Einbindung und lösen Sie sie dann mit folgendem Befehl aus ls:

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

Eine erfolgreiche Einrichtung zeichnet sich durch vier beobachtbare Eigenschaften aus: Die SSH-Authentifizierung wird ohne Eingriff abgeschlossen, der fstab-Eintrag ist erfolgreich mount -a, systemd erkennt die Einbindung als netzwerkabhängig und die entfernten Dateien sind nach einem Neustart erreichbar. Schlägt eine dieser Prüfungen fehl, beheben Sie das Problem direkt auf dieser Ebene, anstatt wahllos weitere Einbindungsoptionen hinzuzufügen.