Unterwegs sicher und überall stabil arbeiten mit SSHFS

Sicher und überall stabil arbeiten mit SSHFS! Wer viel unterwegs ist – ob als Entwickler, Admin oder Digitalnomade – kennt das Problem: Man braucht Zugriff auf Dateien, die auf einem Server liegen, hat aber keinen stabilen LAN-Zugang, sondern ist auf Hotel-WLAN, Tethering oder mobiles Internet angewiesen.

Zu Hause im eigenen Netzwerk ist NFS oft die erste Wahl: Es arbeitet effizient, bringt wenig Overhead mit, hat geringe Latenzen und ist besonders schnell beim Zugriff auf große und viele kleine Dateien.

Unterwegs hingegen ist NFS weniger geeignet – es reagiert empfindlich auf hohe Latenzen, wechselnde IPs und selbst kurze Verbindungsabbrüche können dazu führen, dass das Dateisystem nicht mehr reagiert oder sogar blockiert. Hier kommt SSHFS in Spiel, ein Protokoll das Euch als Roadwarrior das Leben um einiges leichter machen wird.

Was ist SSHFS

SSHFS (SSH File System) erlaubt es, ein Verzeichnis auf einem Remote-Server über eine bestehende SSH-Verbindung ins lokale Dateisystem einzubinden – und das verschlüsselt, firewallfreundlich und benutzerbasiert. Das funktioniert sogar, ohne root-Rechte auf dem Server oder dem Client zu benötigen.

Ihr braucht nur:

• Einen SSH-Server auf der Gegenseite wie auf einer NAS oder einem Standard Linux Server.
• Die sshfs-Software lokal installiert

Ein simples Beispiel für einen Connect mit einem Client.

sshfs -o reconnect,ServerAliveInterval=15,ServerAliveCountMax=3,compression=yes user@remote.host:/pfad/auf/dem/server /mnt/lokaler_ordner

Warum SSHFS ideal für unterwegs ist

1. Kein Port-Gefrickel wie zum Beispiel bei NFS4 und Kerberos

SSH nutzt Port 22 – und der ist fast überall offen. NFS hingegen benötigt mehrere Ports (111, 2049, dynamische RPC-Ports), die in Hotels, Firmenfirewalls oder Mobilfunknetzen blockiert sind. Selbst mit Workarounds wie Port-Forwarding wird NFS schnell zur Frickelei.

2. Robust gegenüber Verbindungsabbrüchen

NFS ist sehr empfindlich bei Verbindungsabbrüchen. Wenn die Verbindung einmal kurz hängt, frieren Prozesse ein, es entstehen I/O-Fehler, und schlimmstenfalls geht gar nichts mehr – besonders bei NFSv3. SSHFS hingegen erkennt einen Verbindungsverlust meist sauber und kann (wenn richtig konfiguriert) automatisch wieder verbinden.

Deshalb in der Praxis extrem wichtig:

-o reconnect,ServerAliveInterval=15,ServerAliveCountMax=3

Das sorgt dafür, dass SSH regelmäßig prüft, ob die Verbindung noch lebt, und automatisch neu verbindet, falls sie verloren geht.

3. Verschlüsselung ab Werk

NFSv3 überträgt alles im Klartext. NFSv4 kann mit Kerberos abgesichert werden, aber das ist kompliziert und auf mobilen Geräten kaum praxistauglich. NFS sollte also IMMER über einen VPN Tunnel genutzt werden, falls der Server nicht im eigenen Netzwerk liegt. SSHFS hingegen nutzt die starke Verschlüsselung von OpenSSH – inklusive moderner Schlüsselverfahren (z. B. ed25519) und Zwei-Faktor-Authentifizierung.

4. Benutzerfreundlich und schnell eingerichtet

Ein typischer SSHFS-Mount dauert Sekunden – kein Serverkonfig, kein Exportfile, keine UID-Mapping-Probleme. Ihr mountet einfach, was Ihr braucht, und fertig. Für Roadwarriors, die flexibel bleiben wollen, ist das ein echter Vorteil.

5. Durch Firewalls und NATs hindurch

SSH funktioniert auch durch NAT, mit Jump Hosts, über Bastion-Server oder über Port 443 getunnelt. NFS hingegen erwartet ein offenes, vertrauenswürdiges Netzwerk. In der realen Welt von mobilen Hotspots und Hotel-WLANs ist das einfach nicht praktikabel.

Hier sind zwei vollständige SSHFS-Setupbeispiele mit Public-Key-Authentifizierung – eines über WireGuard, das andere über das öffentliche Internet via Port 22 und NAT.

Beide Varianten sind ideal für Roadwarriors, aber unterscheiden sich im Hinblick auf Sicherheit, Geschwindigkeit und Komplexität.

Variante 1: SSHFS über WireGuard

Ziel: Sicherer Zugriff auf einen entfernten Server über ein privates VPN-Netzwerk. SSHFS wird über WireGuard getunnelt. Ihr braucht keine offenen SSH Ports nach außen – perfekt für Heimserver oder Officeserver hinter NAT.

Voraussetzungen

• WireGuard serverseitig und clientseitig ist auf beiden Seiten eingerichtet (wg0-Interface vorhanden).
• SSH Port ist auf dem Server offen und erreichbar.
• Public-Key-Authentifizierung ist auf dem Server eingerichtet und die Public-Keys der Clients sind auf dem Remote Server über ssh-copy-id bereits hinterlegt worden.
• Lokaler Mount Point auf dem Client ist eingerichtet, z.B. /mnt/lokaler_ordner, kann aber auch /home/benutzername/storage_server sein oder ähnliches.

Client-Konfiguration (z. B. Laptop)

# 1. Stellt sicher, dass WireGuard aktiv ist

sudo wg-quick up wg0

# 2. SSHFS-Mount

sshfs -o reconnect,ServerAliveInterval=15,ServerAliveCountMax=3,compression=yes,follow_symlinks \
user@server_ip:/pfad/auf/eurem/server /mnt/lokaler_ordner

• server_ip: am besten immer die lokale Netzwerk IP des Servers und nicht die Wireguard Interface IP, ansonsten klappt der Zugriff dann im eigenen LAN Netzwerk dann zuhause nicht mehr.
• /mnt/lokaler_mnt_ordner: Lokales Mount-Ziel

Variante 2: SSHFS direkt über Port 22 + NAT (öffentlich erreichbar)

Ziel: Direktzugriff auf den Server über das Internet. Ideal für VPS oder Heimserver mit Portweiterleitung (z. B. WAN:22 → LAN:22). Kein VPN Overhead.

Voraussetzungen

• Auf dem Router ist eine Portweiterleitung eingerichtet:
  • z. B. WAN-Port 22 auf 192.168.1.100:22 (Server-IP)
• SSH auf dem Server ist konfiguriert:
  • Nur Public-Key-Auth (keine Passwörter!)
  • Fail2Ban + evtl. Port-Knocking empfohlen
• Öffentlicher Dynamischer DNS-Name oder feste IP vorhanden. Auf Synology z.B. mit dem eigenen DynDNS Dienst.
• Lokaler Mount Point auf dem Client ist eingerichtet, z.B. /mnt/lokaler_ordner, kann aber auch /home/benutzername/storage_server sein oder ähnliches.

Client-Mount auf dem Laptop

sshfs -o reconnect,ServerAliveInterval=15,ServerAliveCountMax=3,compression=yes,follow_symlinks \ benutzer@yourdomain.dyndns.org:/pfad/auf/dem/server /mnt/lokaler_ordner

• yourdomain.dyndns.org: DDNS-Hostname oder feste IP
• Auch hier muss der Public Key des Clients vorher auf dem Server eingetragen sein.

Public-Key-Authentifizierung aktivieren (Serverseitig, NAS)

Standard Linux Server

Falls noch nicht geschehen:

1. Server-Konfig anpassen: sudo nano /etc/ssh/sshd_config Folgendes sicherstellen: PasswordAuthentication no PubkeyAuthentication yes Danach: sudo systemctl restart ssh
2. Public Key auf dem Server speichern: via ssh-copy-id

Sonderfall Synology NAS

Hier muss das Benutzerverzeichnis der Benutzer zuerst aktiviert werden, damit ihr euch mit Public-Keys authentifizieren könnt. Danach könnt ihr wie im Artikel beschrieben, für die jeweiligen Nutzer eure Public-Keys hinterlegen.

Ausserdem empfiehlt es sich auch bei der Synology keine Passwörter zu akzeptieren, falls ihr auf diese ohne Wireguard bzw. ohne VPN zugreift:

Server-Konfig anpassen: sudo nano /etc/ssh/sshd_config Folgendes sicherstellen: PasswordAuthentication no PubkeyAuthentication yes
Danach: sudo synoservicectl --reload sshd

Fixes Mounting via fstab

Die Befehle in den Beispielen sind manuelle Befehle um die Verbindung einzuleiten. Wer nicht jedesmal die Verbindung einleiten will, trägt sich die Mount Points in die /etc/fstab ein. Öffnet diese mit sudo nano /etc/fstab und tragt folgenden Befehl ein:

user@1.2.3.4:/pfad/auf/dem/remote-server /mnt/lokaler_ordner fuse.sshfs noauto,x-systemd.automount,_netdev,reconnect,ServerAliveInterval=15,ServerAliveCountMax=3,compression=yes,follow_symlinks  0  0

Ihr könnt eine DynDNS Domain, oder auch eine Fixe IP verwenden. Der user ist natürlich der User auf dem Server, mit dem ihr euch einloggen wollt.

Falls die Clients noch nicht mit dem Server verbunden waren, empfiehlt es sich, vorher den Server in die known_hosts einzutragen:

ssh-keyscan -H server_oder_nas_ip >> ~/.ssh/known_hosts

Ansonsten funktioniert der fstab Eintrag nicht, da bei jeder neuen SSH Verbindung dem remote_server ja zuerst vertraut werden muss.

Empfehlung

Wenn Ihr Wert auf maximale Sicherheit und Performance legt, ist WireGuard + SSHFS die beste Lösung:

• keine offenen Ports im Internet
• stabilere Verbindung
• private IPs
• zusätzliche Verschlüsselungsschicht

Falls Ihr aber keine Möglichkeit habt, ein VPN zu nutzen, ist der direkte Zugriff via SSHFS über NAT absolut solide – vor allem mit einem abgesicherten SSH-Setup (z. B. Fail2Ban, Public-Key-only, restriktive Firewall).

Fazit

Wenn Ihr oft unterwegs seid und aus wechselnden Netzen heraus sicher auf deine Serverdateien zugreifen wollt, ist SSHFS die bessere Wahl. NFS ist ein Arbeitstier im LAN – aber im wilden Westen der mobilen Netzwerke ist SSHFS stabiler, sicherer und deutlich angenehmer in der Praxis. Wir hoffen der Beitrag "Sicher und überall stabil arbeiten mit SSHFS" hat euch gefallen und Euch Euren Road Warrio Alltag etwas leichter gemacht!