How to Mount a Remote SSHFS Directory Automatically at Boot in Debian

To mount a remote SSHFS directory automatically in Debian, configure noninteractive SSH authentication and add an SSHFS entry to /etc/fstab. With systemd, you can either connect during boot or activate an automount at boot and connect when the directory is first accessed. The second approach is useful when the remote server or network may be unavailable during startup.

This reference uses Debian 13 “trixie” documentation reviewed on October 9, 2026, including SSHFS 3.7.3 and systemd 257 documentation. The commands are configuration examples, not results from a tested deployment. Check your installed manuals if you use another release.

Choose when the SSHFS connection should start

The main example uses an on-demand mount. The distinction matters: an active automount does not mean an SSHFS connection already exists. See Debian’s systemd automount manual for the relationship between the automount and its matching mount unit.

Before you start

• The Debian client uses systemd and you have sudo access.
• The remote account supports SFTP and can access the intended directory.
• The client can reach the remote host, including any required VPN or jump host.
• You have a way to verify the remote server’s SSH host-key fingerprint.
• The local mount point is empty and is not a critical system directory.

Replace files@storage.example.net:/srv/data with your remote username, hostname, and directory. The hostname is a placeholder. The local mount point is /mnt/remote; the dedicated key is /root/.ssh/sshfs_boot.

This is an administrator-managed system mount. It runs locally as root but logs into the remote server as files, not remote root. The SSHFS project documentation generally recommends running ordinary interactive mounts as a regular user. A system boot mount requires deliberate credential and access management.

1. Install the client packages

sudo apt update
sudo apt install sshfs openssh-client
sshfs --version
systemctl --version

Install SSHFS on the Debian client. The remote system needs working SFTP service; it does not need an SSHFS installation just to serve files. If package installation fails, resolve the repository or connectivity issue before editing boot configuration.

2. Prepare the mount point and dedicated key

sudo install -d -m 0700 /root/.ssh
sudo mkdir -p /mnt/remote
sudo ssh-keygen -t ed25519 -f /root/.ssh/sshfs_boot -N ''
sudo chmod 0600 /root/.ssh/sshfs_boot

Überschreiben Sie keinen vorhandenen Schlüssel unter diesem Pfad. Wählen Sie gegebenenfalls einen anderen Namen und verwenden Sie diesen im Folgenden einheitlich. Die leere Passphrase ist in diesem Beispiel für die unbeaufsichtigte Entsperrung beabsichtigt: Während des Systemstarts ist niemand verfügbar, der den Schlüssel entsperren kann. Schützen Sie den Client und erteilen Sie dem Remote-Konto nur die benötigten Verzeichnisberechtigungen. Falls Ihre Richtlinie verschlüsselte Schlüssel erfordert, richten Sie stattdessen einen verwalteten, unbeaufsichtigten Entsperrmechanismus ein.

Die Optionen zur Schlüsselerzeugung sind im Debian- Handbuch zu ssh-keygen dokumentiert . Ein im Desktop-SSH-Agent freigeschalteter Schlüssel steht dem System-Mount nicht automatisch zur Verfügung.

3. Schlüssel autorisieren und unbeaufsichtigtes SFTP verifizieren.

sudo ssh-copy-id -i /root/.ssh/sshfs_boot.pub files@storage.example.net

Vergleichen Sie während dieser Verbindungsherstellung den angezeigten Host-Key-Fingerabdruck mit einem Wert, den Sie vom Serveradministrator über einen vertrauenswürdigen Kanal erhalten haben, bevor Sie die Verbindung akzeptieren. Der Befehl wird als lokaler Root-Benutzer ausgeführt, daher wird der Host-Key-Eintrag üblicherweise in den SSH-Dateien des Root-Benutzers gespeichert. Falls die passwortbasierte Einrichtung auf dem Server deaktiviert ist, lassen Sie den Administrator stattdessen den öffentlichen Schlüssel installieren.

Testen Sie anschließend SFTP mit derselben Identitäts- und Host-Schlüsseldatei, die auch für die Boot-Einbindung verwendet wird:

sudo sftp -i /root/.ssh/sshfs_boot \
  -o IdentitiesOnly=yes -o BatchMode=yes \
  -o StrictHostKeyChecking=yes \
  -o UserKnownHostsFile=/root/.ssh/known_hosts \
  files@storage.example.net

Geben Sie an der SFTP-Eingabeaufforderung `sft` und ls /srv/dataanschließend `sft` ein bye. Dies muss ohne Passwortabfrage oder Bestätigungsaufforderung funktionieren. `sft` verhindert die interaktive Authentifizierung; die explizite Host-Key-Einstellung gewährleistet die Authentifizierung. Diese Optionen sind im OpenSSH-Client-KonfigurationshandbuchBatchMode=yes definiert .

Verwenden Sie für einen nicht standardmäßigen Port die Optionen -p 2222`ssh-copy-id`, -P 2222`sftp` und ` port=2222SSHFS`. Falls ein Jump-Host erforderlich ist, konfigurieren und testen Sie diese Route auch im SSH-Kontext von root.

4. Überprüfen Sie, ob die manuelle Montage funktioniert.

sudo sshfs files@storage.example.net:/srv/data /mnt/remote \
  -o IdentityFile=/root/.ssh/sshfs_boot,IdentitiesOnly=yes,BatchMode=yes \
  -o StrictHostKeyChecking=yes,UserKnownHostsFile=/root/.ssh/known_hosts
sudo ls /mnt/remote
sudo umount /mnt/remote

Prüfen Sie, ob sich das Verzeichnis im gewünschten Remote-Verzeichnis befindet. In diesem Beispiel ist der Zugriff zunächst nur dem lokalen Mount-Besitzer (root) gestattet. Verwenden Sie daher für die Prüfung sudo. Hängen Sie das Verzeichnis anschließend aus, bevor Sie die systemd-verwaltete Konfiguration starten. Schließen Sie alle Shells und Anwendungen, die das Verzeichnis verwenden, falls es belegt ist.

SSHFS verwendet die Berechtigungen des Remote-Kontos. Root-Rechte auf dem Client gewähren keine zusätzlichen Berechtigungen auf dem Server. Beheben Sie Authentifizierungs-, SFTP- oder Remote-Pfadfehler hier, bevor Sie die Konfiguration speichern.

5. Fügen Sie den persistenten fstab-Eintrag hinzu.

sudo cp -a /etc/fstab /etc/fstab.sshfs-backup
sudoedit /etc/fstab

Wählen Sie einen anderen Sicherungsdateinamen, falls die Sicherung bereits existiert. Fügen Sie Folgendes als eine einzige Zeile hinzu und ersetzen Sie dabei den Beispielserver und -pfad:

files@storage.example.net:/srv/data /mnt/remote sshfs _netdev,nofail,x-systemd.automount,x-systemd.mount-timeout=30s,IdentityFile=/root/.ssh/sshfs_boot,IdentitiesOnly=yes,BatchMode=yes,StrictHostKeyChecking=yes,UserKnownHostsFile=/root/.ssh/known_hosts,ConnectTimeout=10,reconnect,ServerAliveInterval=15,ServerAliveCountMax=3 0 0

Das SSHFS-Handbuch von Debian gibt sshfsden Dateisystemtyp für fstab an und akzeptiert ihn fuse.sshfsaus Kompatibilitätsgründen. Die letzten Felder deaktivieren die Planung von Dump und Dateisystemprüfung für diesen Eintrag. Konsultieren Sie die fstab-Formatreferenz, falls Pfade Leerzeichen enthalten.

Die systemd-spezifischen Optionen sind im Debian-Systemd-Mount-Handbuch dokumentiert . Das Mount-Timeout setzt keine Frist für jede nachfolgende Dateioperation.

6. Laden Sie systemd neu und aktivieren Sie die automatische Einbindung.

sudo findmnt --verify --verbose
sudo systemctl daemon-reload
sudo systemctl start mnt-remote.automount
systemctl status mnt-remote.automount
sudo ls /mnt/remote
findmnt -t fuse.sshfs

Prüfen Sie die Bestätigungsmeldungen, bevor Sie fortfahren. Das Handbuch von findmnt beschreibt die Überprüfung der fstab-Datei; dabei wird die Konfiguration geprüft, nicht die Funktion der Remote-Anmeldeinformationen. Der Zugriff auf das Verzeichnis führt einen separaten Verbindungstest durch.

Die oben genannten Einheitennamen entsprechen /mnt/remote. Für einen anderen Pfad leiten Sie den Mount-Namen mit ab systemd-escape --path --suffix=mount /your/path. Aus fstab generierte Einheiten benötigen keinen separaten systemctl enableBefehl.

Soll beim Systemstart ein Verbindungsversuch erfolgen, entfernen Sie x-systemd.automountden entsprechenden Eintrag. Nachdem die Benutzer des Verzeichnisses freigegeben wurden, stoppen Sie dessen automatische Einbindung und die Mount-Einheiten, laden Sie systemd neu und starten Sie die zugehörige Mount-Einheit. Behalten Sie den Eintrag bei, nofailwenn der Speicher optional bleiben soll.

7. Überprüfen Sie das Verhalten nach einem Neustart.

Starten Sie das System zu einem geeigneten Wartungszeitpunkt neu. Überprüfen Sie bei der On-Demand-Konfiguration zuerst die automatische Einbindung und greifen Sie dann auf das Verzeichnis zu:

systemctl status mnt-remote.automount
sudo ls /mnt/remote
systemctl status mnt-remote.mount
findmnt -t fuse.sshfs

Erwartete Anzeichen sind ein aktives automatisches Mounten nach dem Systemstart und ein tatsächliches SSHFS-Mounten nach dem Zugriff. Ein autofsEintrag allein beweist nicht, dass entfernte Dateien verbunden sind. Überprüfen Sie eine bekannte entfernte Datei oder ein Verzeichnis, nicht nur, ob der lokale Mountpunktordner existiert.

Falls eine Anwendung diesen Speicher vor dem Start benötigt, fügen Sie ihrem Dienst ein Drop-in hinzu, das Folgendes enthält:

[Unit]
RequiresMountsFor=/mnt/remote

Diese in systemd.unit dokumentierte Abhängigkeit lädt und ordnet die notwendigen Mounts. Laden Sie systemd neu und testen Sie den Start der Anwendung separat. Die Anwendung benötigt außerdem die entsprechenden lokalen Zugriffsrechte.

8. Fehlerbehebung nach Fehlertyp

sudo journalctl -b -u mnt-remote.mount
sudo journalctl -b -u mnt-remote.automount

network-online.targetEs handelt sich um einen Startsynchronisierungspunkt, nicht um eine Garantie für die Erreichbarkeit eines bestimmten Servers oder VPNs. Die Erklärung zu systemd network-online beschreibt diese Einschränkung.

Für den gezielten Zugriff durch einen lokalen Benutzer sollten Sie allow_other,default_permissions,uid=1000,gid=1000die lokalen IDs durch die entsprechenden lokalen IDs ersetzen. Dadurch wird der Zugriff über den Mount-Inhaber hinaus ermöglicht, während die Kernel-Berechtigungsprüfungen weiterhin gelten. Die UID/GID-Optionen ändern die angezeigte, nicht die serverseitige Eigentümerschaft. Root-Mounts benötigen keine Konfiguration user_allow_otherin der fuse.conf; diese Richtlinie ermöglicht es Nicht-Root-Mounts, einen umfassenderen Zugriff anzufordern. Weitere Informationen finden Sie im FUSE-Berechtigungshandbuch . Testen Sie die Anwendung nach der Änderung dieser Optionen erneut als der vorgesehene Benutzer.

Nachdem das zugrundeliegende Problem behoben wurde, löschen Sie den fehlgeschlagenen Mount-Status und versuchen Sie den Zugriff erneut:

sudo systemctl reset-failed mnt-remote.mount
sudo ls /mnt/remote

Die Wiederherstellung nach dem erneuten Verbinden ist nicht für jede Anwendung transparent: Zuvor geöffnete Dateien können beschädigt werden und müssen möglicherweise erneut geöffnet werden. Unterbrochene Schreibvorgänge können zu Datenverlust führen. Wählen Sie ein anderes Speicherdesign, wenn Ihre Arbeitslast höhere Ausfallsicherheit erfordert.

Betriebscheckliste und Rollback

• Unattended SFTP funktioniert mit der exakten Boot-Identität.
• Der Host-Schlüssel wird überprüft und in der erwarteten Datei gespeichert.
• Der fstab-Eintrag wird analysiert und enthält keine Passwörter oder Inhalte privater Schlüssel.
• Der Zugriff nach einem Neustart führt zum gewünschten Remote-Aufruf.
• Der jeweilige lokale Benutzer oder Dienst kann die benötigten Dateien lesen.
• Sie verstehen, wie die Anwendung mit nicht verfügbarem Speicherplatz umgeht.

Um die Konfiguration zu deaktivieren, beenden Sie die Anwendungen, die das Verzeichnis verwenden, mnt-remote.automountund mnt-remote.mountentfernen Sie anschließend nur diesen Eintrag aus der fstab sudo systemctl daemon-reload. Führen Sie dann den Befehl aus. Die übrigen fstab-Einträge bleiben erhalten. Durch das Entfernen der Mount-Konfiguration werden keine Remote-Dateien gelöscht und der autorisierte Remote-Schlüssel nicht widerrufen.