wiki:linux/Network/ssh/sshfs

scp, sshfs


Archwiki -> sshfs
heise: Toolbox: Dateizugriffe mit sshfs

Lösung via sshfs und /etc/fstab-Eintrag

Die einfachste Variante, bei der das Serververzeichnis über einen Eintrag in der /etc/fstab beim Booten eingebunden wird.
Falls es allerdings zu Verbindungsabbrüchen kommt, nachdem längere Zeit nicht auf den Server zugegriffen wurde, kann die auf ubuntuusers beschriebene Lösung (ServerAliveInterval 15) helfen. Zuverlässig arbeitete auch die Variante über `autofs`.
Update: Die `autofs`-Variante ist zuverlässiger, da autofs die Probleme, die sshfs unter anderem mit Verbindungsabbrüchen (z. B. nach einem Suspend) hat, IMHO ganz gut handelt. Nach einem Suspend musste ich erstmal die Prozesse des ssh-Servers und sshfs killen, um überhaupt auf meine lokales Dateisystem via ls zugreifen zu können und den Server erneut einzubinden. Sehr unbefriedigend... ;-)
Dadurch, dass autofs die Verbindungen nach einer bestimmten Zeit (siehe timeout-Paramter) kappt und erst bei einem erneuten Zugriff darauf aufbaut, tauchen solche Probleme kaum noch auf. Fühlt sich zwar auch irgendwie wie ein Hack an, aber wenn's hilft...

Auf dem Client

Nachdem das Paket sshfs installiert ist, sollte der ssh-Zugang auf den Server ohne Passwortabfrage erfolgen können.

Serververzeichnis mounten
$ sshfs USER@HOSTNAME_OR_IP:/REMOTE/DIRECTORY/ /LOCAL/MOUNTPOINT

Ähnlich umount wird ein so eingebundenes Verzeichnis mit fusermount ausgehängt:

$ fusermount -u /LOCAL/MOUNTPOINT
Serververzeichnis via /etc/fstab einbinden

Wichtig ist, dass root ohne Passwortabfrage einloggen kann, d. h., die Schlüsseldatei id_rsa muss in dessen .ssh-Verzeichnis kopiert werden.

Dazu folgenden Eintrag in die /etc/fstab anfügen:

USER@HOSTNAME_OR_IP:/REMOTE/DIRECTORY/ /LOCAL/MOUNTPOINT fuse.sshfs _netdev,user,idmap=user,transform_symlinks,allow_other,default_permissions,uid=USER_UID,gid=USER_GID 0 0

Eine Erklärung der Optionen siehe manpage zu sshfs.

Ubuntu geht hier einen etwas anderen Weg: Statt fuse.sshfs als Dateisystem muss es fuse sein, zudem wird am Anfang der Zeile eine Art shebang erwartet:

sshfs#USER@HOSTNAME_OR_IP:/REMOTE/DIRECTORY/ /LOCAL/MOUNTPOINT fuse _netdev,user,idmap=user,transform_symlinks,allow_other,default_permissions,uid=USER_UID,gid=USER_GID 0 0

Lösung via sshfs und autofs

Diese Lösung wird beschrieben, falls die einfache Variante via sshfs und einem Eintrag in der /etc/fstab wegen Verbindungsabbrüchen nicht zum Erfolg führt.

Auf dem Client

Die beiden Pakete sshfs und autofs installieren:

# apt-get install sshfs autofs

Damit sshfs verwendet werden kann, muss der jeweilige Nutzer der Gruppe fuse angehören:

# usermod -a mutetella -G fuse

Damit die neue Gruppenzugehörigkeit auch greift, muss an dieser Stelle neu gestartet bzw. komplett ab- und wieder angemeldet werden.

UPDATE: Mindestens seit Debian Jessie wurde die Gruppe fuse auch nach einer Installation von sshfs nicht gefunden wobei eine Einbindung des Servers auch ohne einer Zugehörigkeit des Users funktioniert!

Damit sich root ohne Passwortabfrage als mutetella beim Server melden kann muss wie hier beschrieben zuerst ein Schlüssel generiert werden.

Damit sich auch nun root beim Server anmelden kann, muss die Schlüsseldatei id_rsa in dessen Verzeichnis kopiert werden (in einer root-Shell! ).

.ssh-Verzeichnis in root's home-Verzeichnis erstellen:

# mkdir ~/.ssh

Den gerade generierten Schlüssel dorthin kopieren:

# cp /home/mutetella/.ssh/id_rsa ~/.ssh

Nun noch testen, ob es klappt und dabei gleich die known_hosts von root aktualisieren (die Frage danach mit 'yes' beantworten):

# ssh mutetella@192.168.2.9

Wenn alles richtig gemacht ist, müsste sich root ohne Eingabe eines Passworts anmelden können.

Als Ort zum Einhängen ein Verzeichnis /mnt/sshfs erstellen:

# mkdir /mnt/sshfs

Den gerade erstellen mountpoint jetzt in die Datei /etc/auto.master eintragen. Dafür folgende Zeile an die Datei anhängen:

/mnt/sshfs /etc/auto.ssh uid=1000,gid=1000,--timeout=60,--ghost
  • uid=1000: Bestimmt den lokalen User (in diesem Fall mutetella), der auf den mountpoint (in diesem Fall '/mnt/sshfs) zugreifen darf.
  • gid=1000: Bestimmt die lokale Gruppe (in diesem Fall mutetella), die auf den mountpoint (in diesem Fall /mnt/sshfs) zugreifen darf.
  • --timeout=60: Zeit in Sekunden, nach der das entfernte Verzeichnis bei Nichtbenutzung wieder ausgehängt werden soll. default-Wert = 600, ein Wert von 0 verhindert das automatische Aushängen.
  • --ghost: Verhindert, dass autofs den mountpoint nach dem Aushängen löscht.

Nun eine /etc/auto.ssh, die die Informationen zum eigentlichen Einhängen enthält:

srv -fstype=fuse,rw,nodev,nonempty,noatime,allow_other :sshfs#mutetella@192.168.2.9:/srv
  • srv: Der Teil (Pfad) innerhalb des mountpoints, in den eingehängt wird (in unserem Fall /mnt/sshfs/srv).

Die darauf folgenden Optionen entsprechen den fuse mount bzw. mount Optionen:

  • fuse: fuse regelt den ssh-Verkehr
  • rw: read-write
  • nodev: Erstellt keine device nodes (/dev) für das eingehängte Verzeichnis
  • nonempty: Erlaubt das Einhängen in Verzeichnisse, die nicht leer sind.
  • noatime: Verhindert das Aktualisieren der Inodetabelle nach jedem Dateizugriff.
  • allow_other: Nicht nur der User, der das Verzeichnis eingehängt hat (in unserem Fall root) darf auf den mountpoint zugreifen.

Der Ort, der eingehängt werden soll, wird folgendermaßen definiert:

  • :sshfs#mutetella@192.168.2.9:/srv: Bezeichnet das Verzeichnis /srv auf dem Server 192.168.2.9, eingeloggt via ssh als mutetella.
    Im Netz findet sich auch die Schreibweise
    :sshfs\#mutetella@192.168.2.9\:/srv. Das Escaping (\# und \:) sei notwendig, da autofs das # ansonsten als Kommentarzeichen interpretieren und das : ebenfalls falsch deuten würde.
    Ich konnte das bisher nicht feststellen.

Nach einem Neustart von autofs steht das entfernte Verzeichnis mutetella@192.168.2.9:/srv im lokalen mountpoint /mnt/sshfs/srv zur Verfügung und kann auf Wunsch noch über einen Link darauf im /home/mutetella-Verzeichnis zugänglich gemacht werden:

# /etc/init.d/autofs restart

bzw.

# service autofs restart
$ ln -s /mnt/sshfs/srv /home/mutetella/srv

Problemlösungen

Änderung der IP-Adresse

Sollte sich die IP-Adresse des Servers einmal ändern, muss diese neue IP auch auf dem Client bekannt sein. Dazu einfach als User ...

$ ssh mutetella@neueIPadresse

... und danach als root ...

# ssh mutetella@neueIPadresse

anmelden und die Frage, ob diese neue IP permanent zu den bekannten Hosts zugefügt werden soll, mit 'yes' beantworten.

Danach ein

# /etc/init.d/autofs restart

und gut ist!

Last modified 5 years ago Last modified on Nov 18, 2014, 10:51:49 PM