SSHFS – der derzeit gepflegte Fork von SSHFS

 (github.com/deadbeefsociety)
3 Punkte von GN⁺ 2023-09-06 | 1 Kommentare | Auf WhatsApp teilen
  • SSHFS ermöglicht das Mounten entfernter Dateisysteme über SFTP und kann ohne Arbeiten auf der Serverseite verwendet werden, da die meisten SSH-Server SFTP-Zugriff standardmäßig unterstützen und aktivieren
  • Der Maintenance-Fork deadbeefsociety/sshfs wurde archiviert, weil SSHFS nicht mehr sich selbst überlassen ist; verwendet werden sollte libfuse/sshfs
  • SSHFS ist in wichtigen Linux-Distributionen enthalten und wird auf vielen Systemen seit Langem produktiv eingesetzt, hat derzeit jedoch keine regelmäßig aktiven Mitwirkenden; bekannte Issues finden sich im Bugtracker
  • Der aktuelle Maintainer übernimmt weiterhin Pull Requests und veröffentlicht regelmäßig Releases, hat aber außer bei Issues mit hoher Auswirkung keine Kapazität für Entwicklung; Bugreports ohne Pull Request oder nicht kritische Issues erhalten wahrscheinlich keine Antwort
  • Das grundlegende Aufrufformat ist sshfs [user@]hostname:[directory] mountpoint; die Ausführung als normaler Benutzer wird empfohlen, und der Mountpoint sollte diesem Benutzer gehören
    • Wenn der Benutzername weggelassen wird, wird der lokale Benutzername verwendet
    • Wenn das Verzeichnis weggelassen wird, wird das entfernte Home-Verzeichnis eingehängt
    • Wenn ein Passwort erforderlich ist, fragt ssh, das von sshfs ausgeführt wird, nach dem Passwort
  • Es können verschiedene ssh-Optionen einschließlich -oport=PORT angegeben werden; zum Aushängen verwendet man unter Linux fusermount -u mountpoint, unter BSD und macOS umount mountpoint
  • Für den Build werden libfuse 3.1.0 oder neuer bzw. eine mit libfuse3 kompatible Schnittstelle, Glib mit Development-Headern, Meson 0.38 oder neuer und Ninja benötigt; zum Ausführen der Tests wird das Python-Modul py.test benötigt

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2023-09-06
Hacker-News-Kommentare

  • Wenn man etwas im Userspace möchte und Emacs in Ordnung ist, gibt es TRAMP „Transparent Remote (file) Access, Multiple Protocol“: https://www.gnu.org/software/tramp/
    Ich nutze es häufig, um vom MacBook Pro aus auf Serverdateien zuzugreifen.

    • Das Beste an TRAMP ist, dass man in ein Verzeichnis auf dem Remote-System cden kann und dann aus dem aktuellen Arbeitsverzeichnis heraus Dateien auf die lokale Maschine oder auf ein anderes Remote-System cpen kann – und umgekehrt auch von lokal in das aktuelle Remote-Arbeitsverzeichnis kopieren kann.
      Bevor ich TRAMP nutzte, musste ich per SSH auf das Remote-System, mit cd und ls die Kopierstelle suchen, die SSH-Session beenden, die Datei mit scp oder rsync übertragen und mich meist wieder per SSH einloggen.
    • Übrigens funktionieren viele, vielleicht die meisten oder sogar alle Emacs-Funktionen transparent mit Tramp. Dazu gehören dired, eshell und magit.

  • Interessant. Ich dachte immer, sshfs sei Teil von OpenSSH, aber man lernt jeden Tag etwas Neues.
    Das sshfs, das in Slackware verwendet wird, scheint ebenfalls verwaist zu sein: https://github.com/libfuse/sshfs
    Angesichts des Zitats im Link frage ich mich, ob dieses Projekt der „Nachfolger“ werden könnte.

    If you would like to take over this project, you are welcome to do so. Please fork it and develop the fork for a while. Once there has been 6 months of reasonable activity, please contact Nikolaus@rath.org and I'll be happy to give you ownership of this repository or replace with a pointer to the fork.
    Ich frage mich auch, ob es wegen der RHEL-Umstrukturierung verwaist ist, ähnlich wie bei Bluetooth.

    • Es wirkt, als würde es gut zu den OpenSSH-Maintainern passen. Ich hatte ebenfalls gedacht, dass das zur zentralen SSH-Infrastruktur von Linux gehört.

  • Nur als Hinweis: Nachdem ich auf dem Mac jahrelang macFUSE + sshfs genutzt habe, installiere ich inzwischen nur noch das hervorragende Tool Mountain Duck. Damit kann man über Finder und Mount-Punkte auf SFTP-Endpunkte zugreifen.
    Sehr gute Software und für mich unverzichtbar.

    • Ich bin vor Kurzem wieder Kunde bei rsync.net geworden und war beim Überfliegen der Doku etwas überrascht, dass dort Fuse/sshfs immer noch als empfohlene Option für die Mac-Integration aufgeführt ist: https://www.rsync.net/resources/howto/mac_sshfs.html
      Vor ein paar Monaten habe ich deswegen ExpanDrive/StrongSync ausprobiert; von Mountain Duck habe ich erst jetzt gehört. Cyberduck mag ich. Ich werde es jetzt ausprobieren – wenn es gut funktioniert, wäre es schön, wenn diese Seite für andere aktualisiert würde. Ansonsten bin ich ein zufriedener Kunde.
    • Der Vollständigkeit halber: Für macOS gibt es inzwischen https://www.fuse-t.org/. Es funktioniert ohne Kernel-Erweiterung und startet im Hintergrund einen lokalen NFS-Server, mit dem sich macOS dann verbindet.
      Eine sshfs-Implementierung ist ebenfalls unter https://github.com/macos-fuse-t/fuse-t/wiki#sample-filesyste... aufgeführt.
    • Ich nutze ebenfalls hauptsächlich Mountain Duck. In VSCode ist Microsofts Remote-SSH-Erweiterung allerdings eine große Hilfe bei der Arbeit an Repositories in VMs oder auf anderen Remote-Maschinen.
      Libfuse/SSHFS ist unter macOS seit einigen Jahren ziemlich mühsam zu nutzen geworden, und deshalb bin ich ebenfalls zu Mountain Duck gewechselt.

  • Schade, dass sshfs nicht mehr gepflegt wird. In der Uni habe ich sshfs genutzt, um Code mit meinen zahlreichen Vim-Plugins zu bearbeiten, ohne sie alle auf den Remote-Rechenservern der Hochschule installieren zu müssen.
    Ich war überrascht, wie reibungslos das System funktionierte.

  • Ich halte SFTP für ein gutes, aber unterschätztes Protokoll. Manchmal ist es sinnvoller, bidirektional zu spiegeln, als einen Dateibaum von einer Seite auf die andere zu replizieren.
    Nachdem ich den SSHFS-Code geforkt und mir angesehen habe, pflege ich unter https://hackmd.io/@q/sftp-over-ws eine Sammlung relevanter Materialien und persönlicher Gedanken.

    • SFTP war eine große Verbesserung gegenüber FTP, aber auf Serverseite gibt es noch viel ungenutztes Potenzial; das lässt sich nicht einfach durch bessere Clients lösen.
      Sowohl die OpenSSH- als auch die GNU-lsh-Server bieten nur alte Protokollversionen an, vermutlich v2. Dieses Alter ist eine bewusste Entscheidung: https://marc.info/?l=openssh-unix-dev&m=168488976013498&w=2

  • Die Technikkombination ist etwas anders, aber ich nutze seit einiger Zeit recht zufrieden NFS über WireGuard.

    • Wenn der TCP-Kanal zurückgesetzt wurde, handhabt NFS die Wiederverbindung eleganter; das ist ein großer Vorteil.
      Außerdem sind mehr Dateisystemfunktionen implementiert, sodass df-Berichte die Nutzung des Remote-Dateisystems korrekt widerspiegeln.
      Zusätzlich bietet NFSv4 „Delegations“, mit denen einem Client die vollständige Kontrolle über eine Datei in Form eines auslaufenden Leases gegeben werden kann. Moderne NFS-Clients haben außerdem „polite delegations“, die die Lease-Dauer implizit verlängern.
      SSHFS ist sehr praktisch für ein „schnelles und grobes“ Mounten mit minimaler Konfiguration.
    • Ich bin in die andere Richtung gegangen. Die VPN-Infrastruktur ist sehr stabil, aber ich bin auf ein Storage-Verfahren umgestiegen.
      Ich synchronisiere Dateien mit einem sehr einfachen DVFS-Storage-Utility und habe es seitdem nicht bereut. Ich mag es, mehrere Kopien an verschiedenen Orten zu haben.
    • Ich bin vor ein paar Jahren von sshfs auf NFSv4 + WireGuard umgestiegen, und es funktioniert sehr gut.

  • Derzeit nutze ich meist rclone mount, wenn ich sshfs-Funktionalität brauche. Performance, Stabilität und Cache-Optionen sind besser.

    • Allerdings kann rclone nicht mitten in eine Datei schreiben, ohne die ganze Datei zu übertragen. Das ist das größte Problem.
      sshfs könnte dieselbe Einschränkung auch haben.

  • Leider wirkt dieser Fork nicht besonders aktiv. Der letzte Commit ist von März, und bei PRs und Issues passiert ebenfalls kaum etwas.
    Darauf würde ich nicht setzen.

    • Wie viel Aktivität erwartest du denn bei einem stabilen Projekt?
    • „Aktiv“ bedeutet nach JavaScript-Definition, etwas, das gut läuft, anzufassen und kaputtzumachen.

  • Nautilus, also der Datei-Explorer von Ubuntu, unterstützt das Mounten von SFTP-Ordnern. Intern scheint es gvfs zu verwenden.
    Da SFTP für Dateiübertragungen eine SSH-Verbindung nutzt, habe ich im Vergleich zu SSHFS keinen UI-Unterschied gesehen.

    • Man kann in der Nautilus-GUI SFTP-Endpunkte durchsuchen, aber legt es gleichzeitig auch einen Mount-Punkt im Dateisystem an, den man im Terminal nutzen kann?
      Ich erinnere mich nicht mehr genau.

  • Hat jemand unter Mac OS X rclone oder sshfs zusammen mit macFUSE/osxfuse ausprobiert?

    • Ich binde mit Macfuse all meine Server wie lokale Ordner ein. Funktioniert gut.
      Für jeden Server habe ich ein kleines Skript. Zum Beispiel mount_fooserver.sh:
      umount -f ~/mounts/fooserver
      sshfs -o kill_on_unmount,reconnect,allow_other,defer_permissions,direct_io username@server:/ ~/mounts/fooserver -ovolname=foo
    • Ich mounte auf einem M1 mit macFUSE und sshfs ein Laufwerk einer Linux-Kiste im Büro. Im Großen und Ganzen okay, aber es hat diese typische Ruckeligkeit.
      Die Einrichtung fühlte sich ziemlich abenteuerlich an, und ein paar Mal fragte ich mich, ob das wirklich richtig ist, aber als ich drangeblieben bin, funktionierte es gut.
    • Schau dir meinen obersten Kommentar weiter oben an. Die Antwort ist „Mountain Duck“.
    • Unter Monterey auf einem M1 funktioniert sshfs, ist aber eher langsam.