shfs - Das sichere Netzwerkdateisystem
Der Artikel liefert eine Einführung in shfs, ein Netzwerkdateisystem, welches auf dem Server lediglich eine Bourne Shell oder Perl benötigt, dabei standardmäßig SSH zum Verbindungsaufbau verwendet und somit weitreichend einsetzbar ist, da es entfernte Verzeichnisse einfach über einen SSH-Account mounten kann. Anschließend setzt sich der Artikel mit Lösungen zur Ersetzung von NFS durch shfs auseinander.
Es sind natürlich auch Einträge in /etc/fstab möglich, die die üblichen Mount-Optionen normal unterstützen.
rvb@netzverschmutzer.org /mnt/noxa shfs defaults,user,noauto 0 0
Damit könnte ich mein Homeverzeichnis auf netzverschmutzer.org lokal unter dem Verzeichnis /mnt/noxa einbinden, was aufgrund der noauto-Option nicht beim Booten geschieht. Hier sieht man, dass die Verwendung von shfs nicht nur im lokalen Netzwerk einfach machbar ist - es funktioniert auf jedem Rechner, auf dem man eine Shell erhalten kann. Damit es Benutzern ermöglicht wird, beliebige SSH-Server an Verzeichnisse zu mounten, muss das shfsmount-Executable mit root als Besitzer und dem SUID-Bit ausgestattet sein (chmod u+s shfsmount). Dies ist mit Vorsicht zu genießen, da eine Sicherheitslücke in shfsmount dazu verwendet werden könnte, root-Rechte auf dem lokalen System zu erlangen.
Für spezielle Wünsche stehen nunmehr zahlreiche Mount-Optionen zur Verfügung (die mit -o OPTION an den Mountbefehl angehängt werden oder in der fstab in der selben Spalte wie defaults,user stehen):
nocache | deaktiviert den Read/Write Cache. Dies führt zu erhöhter Serverlast und mehr Bandbreitenverschwendung, jedoch bleiben die Änderungen synchron. |
preserve | erhält die Besitzer- und Gruppeninformationen des Servers auf dem Client. Damit dies funktioniert, benötigt man auf den Server root-Zugriff. |
ttl=Sekunden | gibt die Zeit in Sekunden an, nachdem ein Verzeichnisinhalt neu gelesen wird, statt ihn aus dem Cache zu holen. Die Standardzeit für die Gültigkeit des Verzeichnis-Caches beträgt 30 Sekunden. |
uid=Nutzer, gid=Gruppe | legen den Besitzer der Dateien auf dem Client fest. Obwohl er der Besitzer der Dateien ist, werden ihm nur die Rechte zuteil, die der Benutzer auf dem Server hat. |
rmode=Modus | legt die Rechte des Mountpoints fest. Diese sind standardmäßig auf 700 (rwx------) festgelegt |
cmd-user=Nutzer | gibt den Benutzer an, in dessen Namen der Verbindungsaufbau geschehen soll. Dies kann nützlich sein, wenn ein bestimmter Benutzer im Besitz von Authentifizierungssschlüsseln ist. |
cmd=Befehl | ist der Befehl, mit dem die Verbindung aufgebaut wird. In diesem können die Formatzeichen %u, %h und %P verwendet werden. Diese werden dann durch Benutzername, Hostname und Port ersetzt. |
port=Port | wird verwendet um einen alternativen Port anzugeben. Wird dieser nicht angegeben, so wird %P nicht substituiert und das Programm zum Verbindungsaufbau verwendet in meisten Fällen den Standardport für das Protokoll. |
persistent | baut die Verbindung erneut auf, falls sie getrennt wird. |
stable | löst Symlinks auf dem Serversystem auf. Diese sind dann nicht länger als solche erkennbar und werden durch ihre Zieldateien ersetzt. |
type=Typ | kann entweder "perl" oder "shell" sein und gibt an, mit welchem der beiden Programme der Server gesteuert wird. Wird diese Option nicht angegeben, so versucht shfs durch Tests auf dem Server herauszufinden, welche Methode geeignet ist. Dies gelingt in den meisten Fällen. |
Aufbau eines NFS-Ersatzes
Der folgende Abschnitt hat eigentlich weniger mit shfs, sondern viel mehr mit SSH zu tun. Deshalb ist es ratsam, sich nach weiteren Authentifizierungsmöglichkeiten zu erkundigen. Pro-Linux hat unter anderem auch einen Kurztipp, der die PAM-Authentifizierung beschreibt. Im Folgenden werde ich mit Hilfe von DSA-Schlüsseln einen NFS-Ersatz auf Basis von shfs einrichten.
Das Problem
Zunächst sollte man sich Gedanken machen, was NFS kann, shfs mit dem bisherig-abgehandelten Wissen jedoch noch nicht: NFS lässt sich beispielsweise beim Bootvorgang mounten ohne diesen zu behindern, da keine Passworteingabe nötig ist. So ist es beispielsweise möglich, sein Home-Verzeichnis über NFS zu mounten. Um dies mit shfs zu realisieren, könnte man bei jedem Bootvorgang ein Passwort eingeben, was aber sehr lästig ist, da dieser dadurch unterbrochen wird.
Aus diesem Grunde ist es nötig, auf Alternativen zur Authentifizierung zurückzugreifen, wie beispielsweise auf DSA-Schlüssel.
Lösung durch DSA-Schlüssel
Da der Verbindungsaufbau beim Booten als root geschieht, müssen wir einen solchen Schlüssel für ihn generieren. (Wie oben beschrieben kann der Verbindungsaufbau auch im Namen anderer Benutzer erfolgen.) Also loggen wir uns als root ein und generieren einen Schlüssel:
su - ssh-keygen -t dsa
Die Dateinamen können, insofern ihr root-Nutzer nicht schon mehrere DSA-Schlüssel hat, bei ihren Standards belassen werden. Andernfalls wählen Sie einen Alternativnamen für den Schlüssel, dieser muss dann jedoch im Befehl zum Verbindungsaufbau angegeben werden. Die Frage nach der Passphrase für den Schlüssel lassen Sie an dieser Stelle leer, um einen Verbindungsaufbau ohne Passwort zu ermöglichen. Nach der Erzeugung der Schlüssel haben Sie zwei Dateien: /root/.ssh/id_dsa.pub und /root/.ssh/id_dsa. Die zweite Datei sollte unbedingt root gehören und nur für diesen lesbar sein, denn wer im Besitz dieser Datei ist, hat Zugriff auf den Server ohne Passwort! Dennoch ist auch der DSA-Schlüssel ohne Passwort sicherer als die Standardauthentifizierung des NFS, welche lediglich die IP-Adresse des Clients prüft.
Um mit dem generierten Schlüssel nun Zugriff auf den Server zu erhalten, hängen Sie den Inhalt der Datei /root/.ssh/id_dsa.pub auf dem Client an die Datei /root/.ssh/authorized_keys auf dem Server an. Diese muss nicht zwangsläufig im Verzeichnis des root-Nutzers sein. Insofern auf Merkmale wie die 1:1-Abbildung von Besitzer- und Gruppeninformation verzichtet werden kann, kann die Datei auf dem Server auch an die Datei /home/Nutzer/.ssh/authorized_keys angehängt werden, also an die des Benutzers, zu dem die Verbindung aufgebaut wird. In diesem Falle erlangt der Eindringling bei Missbrauch des Schlüssels keine root-Rechte.
