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.

SSH Version 1

Vorgehensweise bei Verwendung von SSH Version 1 (wobei auf dem Server auch OpenSSH laufen darf): Auf dem Rechner, von dem aus man sich auf einem anderen Rechner ohne Paßwort einloggen will, ruft man folgendes Kommando auf:

    ssh-keygen

Nach Aufruf des Kommandos werden zwei Schlüssel erzeugt. Jetzt fragt das Kommando, in welche Datei man die Schlüssel schreiben will - hier kann man einfach den vorgegebenen default übernehmen. Danach wird eine Passphrase für die Schlüssel abgefragt; gibt man hier nichts ein, so wird der Private Key unverschlüsselt abgelegt - das sollte man nur tun, wenn man sich den obigen Abschnitt über Sicherheit genau durchgelesen hat und sich sicher ist, daß die Datei nicht auf einem Fileserver abgelegt wird. Nun gibt das Kommando den auf dem entfernten Rechner zu installierenden Public Key aus - es wird aber auch noch mal in eine Datei geschrieben, und wegen zu erwartender Probleme mit Zeilenumbrüchen ist es empfehlenswert, den Schlüssel nicht mit Cut'n'Paste, sondern als Datei zu übertragen.

Zunächst übertragen wir also den Public Key auf den Server:

    scp $HOME/.ssh/identity.pub user@server:

wobei für server natürlich der Name des entsprechenden Servers und für user der Account auf dem Server einzusetzen sind. Noch muß man sich natürlich mit seinem Paßwort authentifizieren, auch wenn scp bereits den neuen Schlüssel zu verwenden versucht und deshalb ggf. nach der Passphrase fragt.

Jetzt loggt man sich auf dem Server ein, um die Public Key Authentication einzurichten:

    ssh user@server

und ein letztes Mal authentifizieren wir uns mit unserem Paßwort - noch kann die Public Key Authentication ja nicht funktionieren, auch wenn ssh dies bereits versucht und evtl. nach der Passphrase fragt.

Der Public Key wurde als identity.pub hochgeladen und muß nun als .ssh/authorized_keys abgespeichert werden; ggf. muß dazu erst noch das Verzeichnis .ssh eingerichtet werden:

    mkdir .ssh
    chmod 700 .ssh
    mv identity.pub .ssh/authorized_keys

Wenn man auf dem Account bereits einen anderen Schlüssel für Public Key Authentication eingerichtet hat (z.B. um sich von einem anderen Rechner aus ohne Paßwort einzuloggen), darf man die Datei .ssh/authorized_keys natürlich nicht einfach überschreiben, sondern hängt den neuen Schlüssel hintendran:

    cat identity.pub >>.ssh/authorized_keys
    rm identity.pub

Jetzt sollte alles so eingerichtet sein, daß man sich ohne Paßwort einloggen kann.

SSH Version 2

Vorgehensweise bei Verwendung von SSH Version 2: Auf dem Rechner, von dem aus man sich auf einem anderen Rechner ohne Paßwort einloggen will, ruft man folgendes Kommando auf:

    ssh-keygen2

Nach Aufruf des Kommandos wird ein Schlüssel-Paar erzeugt. Danach wird die Passphrase für das Schlüssel-Paar abgefragt; gibt man hier nichts ein, so wird der Private Key unverschlüsselt abgelegt - das sollte man nur tun, wenn man sich den Abschnitt über Sicherheit genau durchgelesen hat und sich sicher ist, daß die Datei nicht auf einem Fileserver abgelegt wird.

Jetzt übertragen wir den Public Key auf den Server:

    scp2 $HOME/.ssh2/id_dsa_2048_a.pub user@server:

wobei für server natürlich der Name des entsprechenden Servers und für user der Account auf dem Server einzusetzen sind.

Jetzt loggt man sich auf dem Server ein, um die Public Key Authentication einzurichten:

    ssh2 user@server

und ein letztes Mal authentifizieren wir uns mit unserem Paßwort - noch kann die Public Key Authentication ja nicht funktionieren.

Der Public Key wurde als id_dsa_2048_a.pub hochgeladen und muß nun im Verzeichnis .ssh2 abgespeichert werden:

    mkdir .ssh2
    chmod 700 .ssh2
    mv id_dsa_2048_a.pub .ssh2

Diesen Public Key muß man nun nur noch für Public Key Authentication freigeben:

    echo "Key id_dsa_2048_a.pub" >>.ssh2/authorization

Jetzt loggt man sich wieder aus und richtet den auf dem lokalen Rechner verbliebenen Private Key zur Authentifizierung ein:

    echo "IdKey id_dsa_2048_a" >>$HOME/.ssh2/identification

Jetzt sollte bereits alles so eingerichtet sein, daß man sich ohne Paßwort einloggen kann.

Will man sich von mehreren Accounts bzw. Rechnern aus auf dem Server einloggen. dürfen natürlich nicht alle Public Keys gleich heissen. Sinnvollerweise benennt man daher die hochgeladenen Schlüssel nach lokalem Account und/oder lokalem Rechner. Damit ergeben sich für die auf dem Server auszuführenden Kommandos folgende Änderungen:

    mkdir .ssh2
    chmod 700 .ssh2
    mv id_dsa_2048_a.pub .ssh2/ Diese E-Mail Adresse ist gegen Spam Bots geschützt, du musst Javascript aktivieren, damit du sie sehen kannst
    echo "Key Diese E-Mail Adresse ist gegen Spam Bots geschützt, du musst Javascript aktivieren, damit du sie sehen kannst " >>.ssh2/authorization

wobei auch hier für client natürlich der Name des lokalen Rechners und für account der Account auf dem lokalen Rechner einzusetzen sind. Natürlich kann man sich auch eine beliebige andere Namensgebung ausdenken.

SSH Version 2 -> OpenSSH

Auf dem Rechner, von dem aus man sich auf einem anderen Rechner ohne Paßwort einloggen will, ruft man folgendes Kommando auf:

    ssh-keygen2

Nach Aufruf des Kommandos wird ein Schlüssel-Paar erzeugt. Danach wird die Passphrase für das Schlüssel-Paar abgefragt; gibt man hier nichts ein, so wird der Private Key unverschlüsselt abgelegt - das sollte man nur tun, wenn man sich den Abschnitt über Sicherheit genau durchgelesen hat und sich sicher ist, daß die Datei nicht auf einem Fileserver abgelegt wird.

Jetzt übertragen wir den Public Key auf den Server:

    scp2 $HOME/.ssh2/id_dsa_2048_a.pub user@server:

wobei für server natürlich der Name des entsprechenden Servers und für user der Account auf dem Server einzusetzen sind.

Jetzt loggt man sich auf dem Server ein, um die Public Key Authentication einzurichten:

    ssh2 user@server

und ein letztes Mal authentifizieren wir uns mit unserem Paßwort - noch kann die Public Key Authentication ja nicht funktionieren.

Der Public Key wurde als id_dsa_2048_a.pub hochgeladen und muß nun in's OpenSSH-Format umgewandelt und als .ssh/authorized_keys abgespeichert werden; ggf. muß dazu erst noch das Verzeichnis .ssh eingerichtet werden:

    mkdir .ssh
    chmod 700 .ssh
    ssh-keygen -i -f id_dsa_2048_a.pub >>.ssh/authorized_keys
    rm id_dsa_2048_a.pub

Jetzt sollte alles so eingerichtet sein, daß man sich ohne Paßwort einloggen kann.

OpenSSH

Jetzt das Ganze für OpenSSH: Auf dem Rechner, von dem aus man sich auf einem anderen Rechner ohne Paßwort einloggen will, ruft man folgendes Kommando auf:

    ssh-keygen -t dsa

Nach Aufruf des Kommandos wird ein Schlüsselpaar erzeugt. Jetzt fragt das Kommando, in welche Datei man die Schlüssel schreiben will - hier kann man einfach den vorgegebenen default übernehmen. Danach wird eine Passphrase für die Schlüssel abgefragt; gibt man hier nichts ein, so wird der Private Key unverschlüsselt abgelegt - das sollte man nur tun, wenn man sich den obigen Abschnitt über Sicherheit genau durchgelesen hat und sich sicher ist, daß die Datei nicht auf einem Fileserver abgelegt wird.

Nun übertragen wir den Public Key auf den Server:

    scp $HOME/.ssh/id_dsa.pub user@server:

wobei für server natürlich der Name des entsprechenden Servers und für user der Account auf dem Server einzusetzen sind. Noch muß man sich natürlich mit seinem Paßwort authentifizieren, auch wenn scp bereits den neuen Schlüssel zu verwenden versucht und deshalb ggf. nach der Passphrase fragt.

Jetzt loggt man sich auf dem Server ein, um die Public Key Authentication einzurichten:

    ssh user@server

und ein letztes Mal authentifizieren wir uns mit unserem Paßwort - noch kann die Public Key Authentication ja nicht funktionieren, auch wenn ssh dies bereits versucht und evtl. nach der Passphrase fragt.

Der Public Key wurde als id_dsa.pub hochgeladen und muß nun als .ssh/authorized_keys abgespeichert werden; ggf. muß dazu erst noch das Verzeichnis .ssh eingerichtet werden:

    mkdir .ssh
    chmod 700 .ssh
    mv id_dsa.pub .ssh/authorized_keys

Wenn man auf dem Account bereits einen anderen Schlüssel für Public Key Authentication eingerichtet hat (z.B. um sich von einem anderen Rechner aus ohne Paßwort einzuloggen), darf man die Datei .ssh/authorized_keys natürlich nicht einfach überschreiben, sondern hängt den neuen Schlüssel hintendran:

    cat id_dsa.pub >>.ssh/authorized_keys
    rm id_dsa.pub

Jetzt sollte alles so eingerichtet sein, daß man sich ohne Paßwort einloggen kann.

OpenSSH -> SSH Version 1

Da OpenSSH von SSH1 abgeleitet ist, entspricht die Vorgehensweise bis auf die erforderliche Angabe des Schlüssel-Typs der bei einer reinen SSH1 Konstellation.

Auf dem Rechner, von dem aus man sich auf einem anderen Rechner ohne Paßwort einloggen will, ruft man folgendes Kommando auf:

    ssh-keygen -t rsa1

Nach Aufruf des Kommandos wird ein Schlüsselpaar erzeugt. Jetzt fragt das Kommando, in welche Datei man die Schlüssel schreiben will - hier kann man einfach den vorgegebenen default übernehmen. Danach wird eine Passphrase für die Schlüssel abgefragt; gibt man hier nichts ein, so wird der Private Key unverschlüsselt abgelegt - das sollte man nur tun, wenn man sich den obigen Abschnitt über Sicherheit genau durchgelesen hat und sich sicher ist, daß die Datei nicht auf einem Fileserver abgelegt wird.

Nun übertragen wir den Public Key auf den Server:

    scp $HOME/.ssh/identity.pub user@server:

wobei für server natürlich der Name des entsprechenden Servers und für user der Account auf dem Server einzusetzen sind. Noch muß man sich natürlich mit seinem Paßwort authentifizieren, auch wenn scp bereits den neuen Schlüssel zu verwenden versucht und deshalb ggf. nach der Passphrase fragt.

Jetzt loggt man sich auf dem Server ein, um die Public Key Authentication einzurichten:

    ssh user@server

und ein letztes Mal authentifizieren wir uns mit unserem Paßwort - noch kann die Public Key Authentication ja nicht funktionieren, auch wenn ssh dies bereits versucht und evtl. nach der Passphrase fragt.

Der Public Key wurde als identity.pub hochgeladen und muß nun als .ssh/authorized_keys abgespeichert werden; ggf. muß dazu erst noch das Verzeichnis .ssh eingerichtet werden:

    mkdir .ssh
    chmod 700 .ssh
    mv identity.pub .ssh/authorized_keys

Wenn man auf dem Account bereits einen anderen Schlüssel für Public Key Authentication eingerichtet hat (z.B. um sich von einem anderen Rechner aus ohne Paßwort einzuloggen), darf man die Datei .ssh/authorized_keys natürlich nicht einfach überschreiben, sondern hängt den neuen Schlüssel hintendran:

    cat identity.pub >>.ssh/authorized_keys
    rm identity.pub

Jetzt sollte alles so eingerichtet sein, daß man sich ohne Paßwort einloggen kann.

OpenSSH -> SSH Version 2

Jetzt wird's ein bißchen spannender, aber im Prinzip wiederholen sich Teile der Konfiguration für reine OpenSSH bzw. SSH2 Konstellationen, mit einem Konvertierungsschritt dazwischen.

Auf dem Rechner, von dem aus man sich auf einem anderen Rechner ohne Paßwort einloggen will, ruft man folgendes Kommando auf:

    ssh-keygen -t dsa

Nach Aufruf des Kommandos wird ein Schlüsselpaar erzeugt. Jetzt fragt das Kommando, in welche Datei man die Schlüssel schreiben will - hier kann man einfach den vorgegebenen default übernehmen. Danach wird eine Passphrase für die Schlüssel abgefragt; gibt man hier nichts ein, so wird der Private Key unverschlüsselt abgelegt - das sollte man nur tun, wenn man sich den obigen Abschnitt über Sicherheit genau durchgelesen hat und sich sicher ist, daß die Datei nicht auf einem Fileserver abgelegt wird.

Der Public Key, der im OpenSSH-Format vorliegt, wird nun in's SSH2-Format umgewandelt:

    ssh-keygen -e -f $HOME/.ssh/id_dsa.pub >$HOME/id_dsa_1024_a.pub

Nun übertragen wir den Public Key auf den Server:

    scp $HOME/id_dsa_1024_a.pub user@server:

wobei für server natürlich der Name des entsprechenden Servers und für user der Account auf dem Server einzusetzen sind. Noch muß man sich natürlich mit seinem Paßwort authentifizieren, auch wenn scp bereits den neuen Schlüssel zu verwenden versucht und deshalb ggf. nach der Passphrase fragt. Anschließend kann der konvertierte Schlüssel auf dem lokalen Rechner wieder gelöscht werden:

    rm $HOME/id_dsa_1024_a.pub

Jetzt loggt man sich auf dem Server ein, um die Public Key Authentication einzurichten:

    ssh user@server

und ein letztes Mal authentifizieren wir uns mit unserem Paßwort - noch kann die Public Key Authentication ja nicht funktionieren, auch wenn ssh dies bereits versucht und evtl. nach der Passphrase fragt.

Der Public Key wurde als id_dsa_1024_a.pub hochgeladen und muß nun im Verzeichnis .ssh2 abgespeichert werden:

    mkdir .ssh2
    chmod 700 .ssh2
    mv id_dsa_1024_a.pub .ssh2

Diesen Public Key muß man nun nur noch für Public Key Authentication freigeben:

    echo "Key id_dsa_1024_a.pub" >>.ssh2/authorization

Jetzt sollte alles so eingerichtet sein, daß man sich ohne Paßwort einloggen kann.

Will man sich von mehreren Accounts bzw. Rechnern aus auf dem Server einloggen. dürfen natürlich nicht alle Public Keys gleich heissen. Sinnvollerweise benennt man daher die hochgeladenen Schlüssel nach lokalem Account und/oder lokalem Rechner. Damit ergeben sich für die auf dem Server auszuführenden Kommandos folgende Änderungen:

    mkdir .ssh2
    chmod 700 .ssh2
    mv id_dsa_1024_a.pub .ssh2/ Diese E-Mail Adresse ist gegen Spam Bots geschützt, du musst Javascript aktivieren, damit du sie sehen kannst
    echo "Key Diese E-Mail Adresse ist gegen Spam Bots geschützt, du musst Javascript aktivieren, damit du sie sehen kannst " >>.ssh2/authorization

wobei auch hier für client natürlich der Name des lokalen Rechners und für account der Account auf dem lokalen Rechner einzusetzen sind. Natürlich kann man sich auch eine beliebige andere Namensgebung ausdenken.