|
Secure Shell (SSH) - Public Key Authentication Public Key Authentication dient dazu, sich per SSH auf einem anderen Rechner einzuloggen oder Dateien zu übertragen, ohne sich jedes Mal mit einem Paßwort authentifizieren zu müssen. Technisch geschieht dies so, daß zwei zueinander passende Schlüssel-Dateien erzeugt werden - in der einen steht der Private Key, in der anderen der Public Key. Der Private Key bleibt beim Benutzer und muß vor fremdem Zugriff geschützt werden; der Public Key hingegen wird auf dem Server hinterlegt. Wenn der Benutzer sich nun anmelden möchte, überprüft der Server, ob er im Besitz eines zum hinterlegten Public Key passenden Private Keys ist, und gewährt nur dann den Zugang auch ohne Paßwort.
Sicherheit
Wenn man Public Key Authentication benutzt, dann ist ab sofort der Private Key dem normalen Paßwort gleichgestellt. So wie man sein Paßwort vor fremdem Zugriff schützen muß (z.B. in dem man es nicht aufschreibt und dann den Zettel rumliegen läßt - in einen Tresor gepackt, wäre ein solcher Zettel aber o.k.), so muß man jetzt den Private Key vor fremdem Zugriff schützen. Deswegen besteht die Möglichkeit, den Private Key wiederum mit einer Passphrase zu schützen - im Prinzip wie ein Paßwort für den Private Key, nur ohne Längenbeschränkung.
Wo ist denn da der Witz, werden sich nun manche fragen, wenn ich mich zwar ohne Paßwort einloggen kann, aber für den Private Key doch wieder eine Passphrase brauche? Nun, zum einen kann man sich später mit diesem einen Schlüssel auf viele verschiedene Rechner einloggen und muß sich nicht deren evtl. verschiedene Paßwörter merken. Zum anderen gibt es den SSH Agent, der in der Lage ist, sich die Passphrase für die Dauer ein Sitzung zu merken, so daß man sie nur einmal eingeben muß und bei allen weiteren Logins und Datei-Transfers nicht mehr gefragt wird. Drittens besteht auch die Möglichkeit, eine leere Passphrase zu verwenden - dann aber ist der Private Key ungeschützt! Jetzt muß man auf anderem Wege sicherstellen, daß niemand an den Schlüssel herankommt, d.h. z.B. die Datei-Zugriffsrechte dürfen nur dem Eigentümer den Zugriff erlauben. Außerdem darf die Datei mit dem Private Key niemals unverschlüsselt übertragen werden - man darf sie also niemals unverschlüsselt per Mail verschicken, nicht mit FTP übertragen, und - was leicht übersehen wird - auch nicht auf einem Fileserver speichern, da die Übertragungsprotokolle NFS und SMB/CIFS ebenfalls unverschlüsselt sind. Versionswirrwarr
SSH ist nicht gleich SSH - im Unix-Umfeld sind drei gängige Varianten im Umlauf: SSH1 und SSH2 von ssh.com sowie OpenSSH, die in einem Programm beide Prtotokollvarianten vereinigt. Je nach verwendeter Programmversion auf Client bzw. Server ergeben sich unterschiedliche Vorgehensweisen: Mit SSH1 auf dem Client zu einem Server mit SSH1 oder OpenSSH
Mit SSH2 auf dem Client zu einem Server mit SSH2 oder OpenSSH
Mit OpenSSH auf dem Client zu einem Server mit SSH1, SSH2 oder OpenSSH Falls man sich nicht sicher ist, welchen Client man hat, kann man einfach mal ssh -V aufrufen, dann sieht man bei SSH1: SSH Version 1..., bei SSH2: SSH Secure Shell 2... oder SSH Secure Shell 3... und bei OpenSSH: OpenSSH_.... Wenn man nicht weiß, welche Version auf dem Server läuft, dann hilft ein beherztes telnet server 22 wobei für server natürlich der Name des entsprechenden Servers einzusetzen ist. Es erscheint dann bei einem SSH1 Server: SSH-1.5-1..., bei einem SSH2 Server: SSH-1.99-2... oder SSH-1.99-3... oder SSH-2.0-2... oder SSH-2.0-3..., und bei einem OpenSSH Server: SSH-1.99-OpenSSH_... oder SSH-2.0-OpenSSH_....
Fehlersuche
Schiefgehen kann natürlich viel, ein paar der häufigsten Fehlerquellen sind aber: Der SSH Server ist (zu Recht!) sehr pingelig, was die Zugriffsrechte angeht. So darf niemand außer Ihnen selbst Schreib-Rechte auf Ihr Home-Verzeichnis oder auf das SSH-Verzeichnis (also .ssh oder .ssh2) haben - sonst geht der Server davon aus, daß nicht Sie selbst, sondern jemand anderes die Authentifizierungs-Datei in Ihr Verzeichnis gelegt haben könnte. Solch ein potentieller Versuch, Ihren Account zu hacken, wird natürlich postwendend mit Ablehnung der paßwortlosen Authentifizierung geahndet. Sollte der Server also partout ein Paßwort verlangen, überprüfen Sie zunächst die Zugriffsrechte. |
Linux 
