Weiter zum Inhalt

SSH mal als Filesystem nutzen

Da ich gerade beruflich viel mit Linux und der Anbindung an einen Server arbeite kommt mal wieder ein kleiner Artikel zum Thema.

Jeder kennt wohl SSH. Viele kennen auch sftp – das was primär bei scp und WinSCP im Hintergrund werkelt und für den sicheren Dateitransfer gedacht ist. Nun, diese Komponenten können wir auch als Remote-Filesystem nutzen. Aber wie kam ich nun gerade (wieder) auf dieses Filesystem?

Die Anforderung

Eigentlich ist es eine einfache Anforderung, die ich momentan auf Arbeit habe: Über das Netzwerk soll ein Image verfügbar gemacht werden. Das Image darf auf dem Client nicht gespeichert werden, weil schlichtweg der Speicherplatz nicht zur Verfügung steht. Nun, soweit ist das alles nichts besonderes, wenn ich einmal davon absehe, das NFS keine Option ist.
Die erste Idee war WebDAV via davfs2 zu nutzen, da momentan nur HTTPS Verbindungen zulässig sind. Aber das Protokoll ist leider nicht für größere Dateien gedacht und kopiert stets im Hintergrund die komplette Datei bei Zugriffen (also vom Server beim Lesen und vom Client beim Schreiben). Damit fiel diese Lösung leider heraus.
Als nächstes fiel mir ein altes Experiment mit fuse wieder ein. Damals hatte ich versucht SSH Zugriffe über das Filesystem zu realisieren. Das funktionierte damals schon super und warum sollte es diesmal nicht funktionieren.

SSHFS, die Lösung

Unter Debian ist natürlich alles wieder zügig installiert:

aptititude install sshfs

Ist die Installation erst einmal durchgelaufen kann es theoretisch schon los gehen. Damit wir aber eine etwas lesbarere fstab Syntax erhalten, bauen wir noch einen kleinen mount-Helper, wie wir ihn schon bei der ntfs-3g Installation kennengelernt haben:

ln -s /sbin/mount.fuse /sbin/mount.fuse.sshfs

Nun kann ein Mount-Point in der fstab deklariert werden:

@:  fuse.sshfs user,allow_other,noauto 0 0

Sieht noch etwas kryptisch aus. Aber nehmen wir mal als Beispiel, das es einen Server source.example.com gibt, welchen wir gerade einrichten. Außerdem existiert der Server target.example.com, welcher als SSH Server genutzt werden soll. Auf dem Server target.example.com existiert der Nutzer example, welcher Zugriff auf das Verzeichnis /var/sshfs hat. Dieses Verzeichnis soll nun auf source.example.com über das Verzeichnis /media/ssh verfügbar gemacht werden. Daraus ergibt sich folgende fstab Zeile:

example@target.example.com:/var/sshfs /media/ssh fuse.sshfs user,allow_other,noauto 0 0

Wenn ein User nun

mount /media/ssh

eingibt, wird versucht auf den Server target.example.com zuzugreifen. Ist das erfolgreich, wird entweder versucht mit dem SSH Key des Users eine Authentifikation durchzuführen oder das Passwort für den Account example wird abgefragt. Grundsätzlich empfehle ich den Weg über den SSH Schlüssel.

SSH Keys

SSH nutzt asymmetrische Verschlüsselung, welche einen öffentlichen und einen privaten Schlüssel benötigt. Wie die Namen schon andeuten ist der private Schlüssel unter keinen Umständen weiter zu geben und soweit möglich immer mit einem Passwort zu versehen. Der öffentliche Schlüssel kann frei verfügbar sein. Dieser wird zum Beispiel vom Administrator des Zielsystems benötigt um Zugriff auf das System mittels der Schlüssel zu ermöglichen. Aber eins nach dem anderen.

SSH Key erzeugen

SSH Keys sind zügig erstellt. Am einfachsten führt der User, welcher die Keys nutzen möchte, ssh-keygen aus. Ein Beispiel könnte so aussehen:

ssh-keygen -b 2048 -C "My SSH Key"

Damit erzeugen wir einen Schlüssel mit einer Bitlänge von 2048 (-b) und fügen den Kommentar „My SSH Key“ ein. Nach dem Start fragt ssh-keygen nach dem Namen der Datei – im Falle das der Key auch gleich für den aktuellen User genutzt werden soll kann hier einfach Enter gedrückt werden. Wird der Key für einen anderen Nutzer erstellt, ist die Wahl grundsätzlich erst einmal frei. Damit openssh später den Key findet muss der private Schlüssel als identity oder als id_rsa bzw. id_dsa im Verzeichnis .ssh des Home-Verzeichnisses verfügbar sein. Ob rsa oder dsa der richtige Suffix ist hängt vom Algorithmus ab, mit dem der Schlüssel erzeugt wurde. Wenn der Schlüssel mit dem Beispielbefehl generiert wird, wird der Standard – RSA – genutzt. Wer mehr zum Thema wissen möchte kann sich bei Wikipedia die Artikel zu RSA und DSA einmal ansehen.

Aber zurück zum Generieren der Schlüssel. Ist die Frage nach dem Dateinamen geklärt fragt ssh-keygen noch nach einer Passphrase. Es ist verlockend hier kein Passwort zu nutzen – ist der Key doch das eigentliche Passwort – aber dieser Versuchung sollte so gut wie nie nachgegeben werden. Denn jeder, der diesen Key einmal in die Hände bekommt hat auch Zugang zu sämtlichen Systemen die für diesen Key freigegeben sind. Wird keine Passphrase vergeben so sollte noch mehr auf den Schlüssel geachtet werden und die Zugriffsrechte sollten auf ein Minimum beschränkt werden.
Und wo ich gerade bei guten Ratschlägen bin: Es ist gut, das hier nach einer Passphrase und nicht (nur) nach einem Passwort gefragt wird. Es ist wirklich besser einen ganzen Satz oder gar eine Redewendung zu nutzen. Diese lassen sich meist besser merken und sind durch Brute-Force-Attacken nicht so einfach mit vertretbarem Aufwand herausfindbar.

Nachdem nun auch eine Passphrase eingegeben wurde wird der Schlüssel generiert. Nach dem Generieren existieren zwei Dateien (daher ist auch immer die Rede von den Schlüsseln). Beide haben den Dateiamen der während des Generierens konfiguriert wurde. Eine Datei hat zusätzlich den Anhang .pub. Das ist der öffentliche Schlüssel. Beide Dateien sollte vorsichtshalber an einem sicheren Ort als Kopie gelagert werden. Für Firmenschlüssel bietet es sich an, beide Dateien auf Papier zu bannen (es ist schliesslich „nur“ ein ganz großer String pro Datei) und zusammen mit einem Datenträger, welcher die Dateien digital enthält, in einen Safe zu packen.

Die Schlüssel einspielen

Wie bereits kurz angemerkt, gehört der private Schlüssel per default in das Verzeichnis .ssh, welches unterhalb des jeweiligen Nutzerverzeichnisses liegt. Der Dateiname sollte identity oder id_rsa bzw. id_dsa lauten.Wenn wir annehmen, das auf dem Server source.example.com der Nutzer bob existiert und den Schlüssel nutzen soll, so sollte der oben generierte Key unter dem Pfad /home/bob/.ssh/id_rsa existieren.

Auf dem Server target.example.com wird der Inhalt der Datei mit dem Suffix .pub an die Datei authorized_keys angehangen. Angehangen ist dabei das wichtigste Wort. Die Datei authorized_keys enthält eine Menge an öffentlichen SSH Schlüsseln von Nutzern, die ebenfalls Zugang zu dem Nutzeraccount bekommen sollen. Sobald der Inhalt eines öffentlichen Schlüssel einfach nur nach authorized_keys kopiert wird, haben alle anderen Schlüssel keinen Zugang mehr!
Wenn der öffentliche Schlüssel als Datei id_rsa.pub auf target.example.com kopiert wurde, kann er einfach durch die Befehlszeile

cat id_rsa.pub >> /home/example/authorized_keys

an die Datei mit den erlaubten Schlüsseln angehangen werden. Natürlich kann auch der Inhalt der Datei als String kopiert werden und in die Datei authorized_keys kopiert werden.

SSH konfigurieren

Eigentlich sollte SSH bereits so konfiguriert sein, das es sowohl SSH Keys als auch Passwörter akzeptiert. Da SSH Schlüssel nicht einfach erraten werden können, lasse ich normalerweise nur Anmeldungen via SSH zu, aber das nur am Rande und als kleiner Tipp.
Die magische Konfigurationszeile, welche SSH Keys zulässt, in der Datei /etc/ssh/sshd_config lautet:

PubkeyAuthentication yes

Wenn das gesetzt ist, akzeptiert der Server SSH Authentifikation. Zum Testen genügt es, einfach eine SSH Verbindung aufzunehmen. Angenommen, wir sind als User bob auf source.example.com angemeldet und die SSH Keys sind an Ort und Stelle, dann sollte

ssh example@source.example.com

nach dem SSH Key Passwort fragen.

Der finale Test

Ok, jetzt sollte ja alles vorhanden sein. Also kann der User bob los legen:

mount /media/ssh

Wenn alles geklappt hat, sollte jetzt nach dem Passwort des SSH Keys gefragt werden. Wenn dieser richtig eingegeben wurde, sollte unter /media/ssh das zu finden sein, was auf dem Server target.example.com im Verzeichnis /var/sshfs zu finden ist.

Links

Wer jetzt Blut geleckt hat, kann auch einen Blick auf folgende Links werfen:

  • OpenSSH – Die freie SSH Implementierung
  • PuTTY – Für alle, die noch unter Windows arbeien müssen, aber einen SSH Client brauchen.
  • fuse Dateisysteme – eine Liste mit anderen Dateisystemen, die auf fuse aufbauen

Kommentar verfassen

Dein E-Mail wird nicht veröffentlicht oder weitergegeben. Pflichtfelder sind mit * markiert.

By continuing to use the site, you agree to the use of cookies. more information

The cookie settings on this website are set to "allow cookies" to give you the best browsing experience possible. If you continue to use this website without changing your cookie settings or you click "Accept" below then you are consenting to this.

Close