Beim Datenzugriff auf entfernte Rechner kombinieren SSH-basierte Dateisysteme einfache Konfiguration und sichere Verschlüsselung.

Weit verbreitete Netzwerk-Dateisysteme wie NFS oder Samba verschlüsseln zu übertragende Daten standardmäßig nicht. Die häufig verwendete Version 3 von NFS benützt zum Authentifizieren nur die IP-Adresse des Clients [1]. Version 4 hat gerade erst Einzug in die Distributionen gefunden, gilt jedoch noch nicht als stabil und wie Samba als mitunter aufwändig zu konfigurieren [2].

SSH-Dateisysteme wie SHFS und SSHFS bieten sich als Alternative an: Sie stellen geringe Anforderungen an die Software des Servers, lassen sich leicht konfigurieren und sind sehr sicher. Das in der Praxis erprobte und bewährte SSH-Protokoll authentifiziert Benutzer anhand eines Passworts oder eines Schlüssels [4]. Es verschlüsselt zudem alle übertragenen Daten inklusive Passwort und eignet sich daher auch für den Zugriff auf einen Server im Internet.

Anders als beim FTP-Client Lftp oder dem entsprechende KDE-Kio-Slave via FISH-Protokoll [5] erlaubt ein SSH-Dateisystem den transparenten Zugriff von allen Anwendungen aus (Abbildung 1). Es gibt gegenwärtig zwei reine SSH-Dateisysteme für Linux: Das Dateisystem SSHFS läuft im Userspace und greift auf FUSE zurück, um Kernel-bezogene Dateisystemfunktionen auszuführen (siehe [6] und [7]). Serverseitig nutzt es SFTP und funktioniert daher mit jedem Server, auf dem SSH-Daemon und -Client installiert sind.

Abbildung 1: Sowohl KDE als auch LFTP greifen von Haus aus via SSH auf entfernte Dateien zu.

Der andere Ansatz, SHFS, ist als Kernelmodul implementiert [8], das bislang noch nicht zum Standardkernel zählt. Es lädt entweder ein Perl-Programm oder ein Shellskript auf den Server, das jeweils die Anfragen ans Dateisystem bearbeitet. Das erfordert auf dem Server neben SSH also nur eine Shell oder Perl. Laut Projekt verhält sich das standardmäßig verwendete Perl-Programm robuster und schneller als das Shellskript.

Server einrichten

Installieren Sie für beide Dateisysteme auf dem Server zunächst SSH. Dazu verwenden Sie unter Suse das Paket openssh, unter Debian “Sarge” ssh. Bei Debian “Etch”/”Sid” sowie Ubuntu richten Sie openssh-server ein, das openssh-client mitzieht. Der SSH-Server lauscht standardmäßig auf Port 22.

Jeder SSH-Server verfügt zumindest über einen Host-Schlüssel, den Sie nach der Installation beziehungsweise dem ersten Start des Servers im Verzeichnis /etc/ssh finden. Der für Verbindungen eingesetzte Schlüssel hängt von der Protokollversion und dem Verschlüsselungsverfahren ab [9]. Jeder Schlüssel hat einen eindeutigen Fingerabdruck. Mit diesem überprüfen Sie, ob Sie sich wirklich mit dem richtigen Server verbinden. Erstellen Sie mit find /etc/ssh -name "*key" | xargs -n1 ssh-keygen -lf eine Liste der Fingerabdrücke und verwahren Sie diese an einem sicheren Ort.

Testen Sie den Zugang, indem Sie sich vom Client aus mit

ssh Benutzername@HostnameOderIP-Adresse

am Server für eine Shell-Sitzung anmelden. Überprüfen Sie dabei, ob der vom Client angezeigte Fingerabdruck in der eben erstellten Liste zu finden ist. Klappt der Login, verlassen Sie mit exit oder [Strg]+[D] die Remote-Shell wieder.

SSHFS

Für SSHFS benötigen Sie einen Kernel mit FUSE-Support. Die Standardkernel von Suse 10.1, Debian “Etch” und “Sid” sowie Ubuntu “Dapper Drake” enthalten FUSE bereits. Unter Debian “Sarge” installieren Sie einen Kernel aus den Backports [10]. Alternativ verwenden Sie das Paket module-assistant und kompilieren mit m-a a-i fuse (module-assistant auto-install) das Kernelmodul für FUSE. Unter Ubuntu “Breezy” und älter sollte das gleiche Vorgehen funktionieren. Alternativ übersetzen Sie einen eigenen Kernel mit der Option Filesystem | Filesystem in Userspace support (CONFIG_FUSE_FS) als Modul.

Installieren Sie das Paket sshfs oder bauen Sie die aktuelle Version 1.7 mit dem bekannten Dreisatz ./configure; make; su -c "make install" aus dem Quelltext. Installieren Sie hierfür die Entwicklerpakete fuse-devel und glib2-devel unter Suse beziehungsweise libfuse-dev und libglib2.0-dev unter Debian und Ubuntu.

Laden Sie mit modprobe fuse das Kernelmodul. Tragen Sie unter Debian und Ubuntu den Modulnamen in die Datei /etc/modules ein, um das Modul beim Booten zu laden. Bei Suse gehört er in die Datei /etc/sysconfig/kernel unter MODULES_LOADED_ON_BOOT.

Nun ist SSHFS bereits einsatzbereit, jedoch darf nur root ein Dateisystem mounten. Fügen Sie unter Debian oder Ubuntu mittels adduser Benutzer fuse ihren Benutzer der Gruppe fuse hinzu, damit er FUSE verwenden darf. Unter Suse verwenden Sie YaST, um den Benutzer der Gruppe trusted hinzufügen. Oder zeigen Sie mittels groups die aktuellen Gruppen Ihres Benutzers an, und geben Sie mit groupmod -A Benutzername trusted an, dass der Benutzer der neuen Gruppe angehören soll.

Nun ist es Zeit für einen ersten Test: Erstellen Sie mit mkdir Verzeichnis ein Verzeichnis und mounten Sie mittels

sshfs Benutzer@Host:LokalesVerzeichnis -o reconnect

das Home-Verzeichnis des angegeben Benutzers (siehe Tabelle “Mount-Optionen”). Nun greifen Sie auf die entfernten Dateien zu, als seien es lokale Dateien (siehe Abbildung 2 und Abbildung 3). Nach getaner Arbeit melden Sie das Verzeichnis mittels fusermount -u LokalesVerzeichnis wieder ab. Häufig benötigte SSHFS-Mounts tragen Sie in die /etc/fstab ein (siehe Listing 1 und [11]).

Abbildung 2: Transparenter Zugriff auf entfernte Dateien mit SSHFS und SHFS.

Abbildung 3: Gigantischer Speicherplatz mit SSHFS. SHFS bleibt realistisch.

SHFS

Bei der Installation von SHFS sind Debian- und Ubuntu-Anwender klar im Vorteil: Installieren Sie die Pakete shfs-utils und falls noch nicht geschehen module-assistant. Kompilieren Sie mit m-a a-i shfs dann das Kernelmodul für SHFS. Für Suse 10.1 gibt es indes keine fertigen Pakete. Holen Sie sich den Quelltext von der Heft-CD oder aus dem Internet. Für Kernel ab Version 2.6.16 ist ein Patch erforderlich [12], für GCC ab Version 4 ebenfalls [13].

Installieren Sie, falls noch nicht geschehen, die Kernelquellen. Die des Standardkernels finden Sie im Paket kernel-source. Entpacken Sie das Quelltextarchiv von SHFS mit tar -xvzf shfs-0.35.tar.gz. Wechseln Sie in das Verzeichnis shfs-0.35 und wenden Sie gegebenenfalls mit patch -p0 < d_entry-2.6.16.diff den Patch für den Kernel und mit patch -p1 < gcc4-compilefix.patch den Patch für GCC an.

SHFS übersetzen Sie mittels make in eine ausführbare Datei. Es ergibt jedoch mehr Sinn, eigene RPM-Pakete zu erstellen. Diese lassen sich leichter wieder deinstallieren. Ersetzen Sie dazu in den beiden Dateien rpm/shfs-module.spec.in und rpm/shfs-utils.spec.in die Zeile Copyright: GPL durch License: GPL. Mit make rpm erstellen Sie zwei RPM-Pakete, die Sie mit rpm -i Paketname installieren. Möchten Sie den Mount- und den Umount-Befehl für SHFS als Benutzer nutzen, setzen Sie mit chmod u+s /usr/bin/shfsmount und chmod u+s /usr/bin/shfsmount das SUID-Recht.

Nach der Installation von SHFS laden Sie modprobe shfs das Kernelmodul. Mit shfsmount -p Benutzer@Host: Lokales Verzeichnis mounten Sie das Home-Verzeichnis des entferntes Benutzers (siehe Tabelle “Mount-Optionen”). Mit shfsumount Lokales Verzeichnis melden Sie es wieder ab. Einen /etc/fstab-Eintrag zeigt Listing 1.

# /etc/fstab (Beispiel)
# Abschnitt für SSHFS/SHFS
sshfs#martin@mondschein:   /mnt/netz/mondschein-sshfs  fuse   user,noauto,reconnect    0   0
martin@mondschein:         /mnt/netz/mondschein-shfs   shfs   user,noauto,persistent   0   0

Benutzer, Gruppen, Rechte

Sowohl SSHFS und SHFS arbeiten auf den entfernten Server mit den Rechten des angegebenen Benutzers. Bei SHFS gehören Dateien auf dem Client dem lokalen Benutzer. SSHFS verwendet Benutzer- und Gruppen-ID der entfernten Datei. Beide Dateisysteme bieten diverse Optionen, um Benutzer, Gruppen und Rechte anders umzusetzen. Der Einstieg fällt jedoch am leichtesten, wenn Sie dem Benutzer auf dem Server die gleiche Benutzer- und Gruppen-ID zu geben wie auf dem Client.

Mehr Komfort, bitte!

Häufig verwendete SSH-Server konfigurieren Sie in ~/.ssh/config. Ein Beispiel zeigt Listing 2. Es reicht fortan, den Host anzugeben. Noch mehr Komfort und zusätzliche Sicherheit bieten SSH-Schlüssel und ssh-agent. Erstellen Sie auf dem Client, sofern noch nicht geschehen, mit dem Befehl ssh-keygen -b 2048 -t rsa einen Schlüssel. Geben Sie für ihn ein sicheres Passwort ein, wie es der Befehl pwgen liefert.

# ~/.ssh/config (Beispiel)
# mondschein.eine-domain.de
Host mondschein
Hostname mondschein.eine-domain.de
# evtl. anderer Port:
# Port 2121
User martin
# evtl. kürzeres KeepAliveInterval:
#ServerAliveInterval 15

Es ist möglich, einen SSH-Schlüssel ohne Passwort zu erstellen. Wer diesen Schlüssel entwendet, erhält jedoch leichten Zugang zu Ihrem SSH-Server. Verwenden Sie daher besser einen Schlüssel mit Passwort – insbesondere für den Root-Zugriff. Anders als bei NFS hat jemand, der mit SHFS und SSHFS auf den Server zugreift, auch die Möglichkeit, eine SSH-Shell zu starten. Die Funktion, für root Benutzer und Gruppe wie bei NFS auf nobody umzusetzen, bieten prinzipbedingt weder SSHFS noch SHFS.

Machen Sie den öffentlichen Teil des Schlüssels mit

ssh-copy-id -i ~/.ssh/id_rsa.pub Benutzer@Host

dem Server bekannt. Der Befehl kopiert den öffentlichen Teil des Schlüssels auf den Server und fügt ihn dort der Datei ~/.ssh/authorized_keys hinzu.

Beim nächsten Login via SSH geben Sie statt des Benutzerpassworts nun das des Schlüssels ein. Das brauchen Sie aber nicht jedes mal zu tun: Führen Sie den Befehl ssh-add aus, und geben Sie das Schlüsselpasswort an. Der SSH-Agent entschlüsselt damit Ihren privaten Schlüssel und hält diesen im Speicher. Mit ssh-add -l erhalten Sie eine Liste der im Speicher gehaltenen Schlüssel und mit ssh-add -d entfernen Sie einen Schlüssel aus dem RAM.

Tragen Sie PermitRootLogin without-password in die Konfigurationsdatei des SSH-Servers (/etc/ssh/sshd_config) ein, damit Root sich nur noch mit einem Schlüssel anmelden darf. Die Option PermitRootLogin no verbietet den Root-Login komplett – Ihnen bleibt dann die Möglichkeit, sich als Benutzer anzumelden und anschließend mit su die Identität zu wechseln.

Mit PasswordAuthentication no verbieten Sie allen anderen Benutzern, sich via Passwort anzumelden. Nur mit ChallengeResponseAuthentication no funktionieren PermitRootLogin without-password und PasswordAuthentification no unabhängig von Ihrer PAM-Konfiguration, da SSH in diesem Fall zum Authentifizieren nicht auf PAM zurückgreift.