Daten sicher teilen

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.