Was sind SSH-Schlüsselpaare und wie verwende ich sie?

SSH ist ein Protokoll für den Zugriff auf entfernte Systeme. Was das bedeutet wollt ihr wissen?
Mit SSH könnt ihr euch auf einem entfernten Unix-Server einloggen und dann die selben Dinge tun die ihr tun könntet wenn ihr selbst dort wärt.
SSH ist quasi ein „Kabel“, das auf der einen Seite mit dem Unix-Server verbunden ist und auf der anderen Seite mit eurem Bildschirm und eurer Tastatur.

Um euch auf einem entfernten System einzuloggen, müssen zwei Bedingungen erfüllt sein: 1) dort läuft ein Dienst, der den entfernten Login erlaubt, meist ist das „sshd“; 2) ihr habt auf dem entfernten Server einen Useraccount.

Sind diese Bedingungen erfüllt, braucht ihr nur noch einen SSH-Client.
Dieser ist auf Linux-System oft schon vorinstalliert, und heißt schlicht und einfach „ssh“; ihr müsst ihn nur in der Konsole aufrufen.
Für Windows gibt es auch einige Clients, beispielsweise den PuTTY

Meistens werdet ihr, wenn ihr auf dem entfernten Server einen Account habt zu eurem Benutzernamen ein Passwort bekommen haben.
Selbstverständlich könnt ihr euch dann immer über euren Benutzernamen und das Passwort einloggen.

Doch das Benutzen eines Passworts hat auch Nachteile:

1. Ihr müsst es jedesmal eingeben - das kostet Zeit und es nervt.
2. Der Systemadministrator muss es euch irgendwie geheim zukommen lassen, es darf auf keinen Fall jemand mitlesen!
3. Ihr könntet das Passwort vergessen. Auch wenn euch der Systemadministrator dann ein neues ausstellen würde, birgt das Gefahren (siehe Punkt 2).
4. Die Passwortstärke ist relativ gering - ein durchschnittlicher Mensch merkt sich nur wenige Zeichen.

PKI steht für Public-Key-Infrastructure, und ist der Name für ein geniales Konzept aus der Kryptographie. Ein Synonym dafür ist „Asynchrone Verschlüsselung“

Um zu erklären was PKI und asynchrone Verschlüsselung ist, möchte ich dem die „synchrone Verschlüsselung“ gegenüberstellen.
Diese funktioniert nach dem bekannten Prinzip: Jemand hat einen Schlüssel (z.B. ein Passwort) und steckt es in ein Schloss (z.B. für einen Login). Dieses Prinzip ist in dem Sinne anfällig, als dass die Verteilung des Schlüssels geheim erfolgen muss und der Schlüssel geheim gehalten werden muss. Ist dies nicht der Fall, ist das Geheimnis verraten und das System kompromittiert! Ein möglicher Angriffspunkt ist hier das Öffnen des Schlosses (z.B. der Vorgang des Logins), da hier die eigentlich geheime Daten übertragen werden müssen.

Asynchrone Verschlüsselung funktioniert nach einem anderen Prinzip: Jeder Beteiligte hat nicht einen Schlüssel, sondern ein Schlüsselpaar: den geheimen und den öffentlichen Schlüssel.
Stellt euch den öffentlichen Schlüssel wie ein Vorhängeschloss vor: Ihr könnt ihn verschicken so viel ihr wollt. Den Angreifern nutzt euer Vorhängeschloss gar nichts, sollen sie etwa ihrer eigenen Daten für dich verschlüsseln?
Euer geheimer Schlüssel ist dann der Schlüssel der zu dem Vorhängeschloss passt.

In dieser Analogie würde der Login so ablaufen: ihr verschickt euer Vorhängeschloss an den Admin, er hängt es an euren Spind (euer Account). Nur ihr könnt ihn jetzt mit dem Schlüssel dazu aufmachen. Wobei die Analogie hinkt ist folgendes: die Interaktion zwischen eurem Vorhängeschloss und dem Schlüssel dazu ist Sicher, denn jeder kann Informationen mit dem öffentlichen Schlüssel verschlüsseln aber sie zu entschlüsseln ist fast unmöglich (außer mit eure geheimen Schlüssel).

ACHTUNG, WICHTIG: Während es egal ist was ihr mit eurem öffentlichen Schlüssel tut, dürft ihr den geheimen Schlüssel niemals aus euren Händen geben! Übertragt ihn nicht über das Netzwerk (schon gar nicht das Internet), lasst ihn nie auf USB-Sticks drauf, am besten behaltet ihn überhaupt nur auf eurer Festplatte!

PKI kann auch bei SSH eingesetzt werden, es hat einige Vorteile:

1. Keine Passworteingabe
2. Einfache und sichere Verteilung: verschickt euren öffentlichen Key und macht euch keine Sorgen dass er mitgeschnitten wird
3. Da der Schlüssel nicht gemerkt wird, sondern auf der Festplatte bleibt, kann man viel stärkere Schlüssel erstellen. Zur Zeit des Verfassens dieses Artikels sind Schlüssel mit 2048 oder 4096 Bit üblich.

Tatsächlich ist es so, dass einige Systemadministratoren aus diesen Gründen den Login über Passwörter abgeschaltet haben und der Login nur mehr über PKI funktioniert.

Damit ihr die Vorteile von PKI bei SSH nützen könnt, müsst ihr euch erst einmal ein Schlüsselpaar generieren.

Auf Windows ist hierfür euer SSH-Client verantwortlich, eine kurze Anleitung für PuTTY findet ihr zum Beispiel hier.

Auf einem Unix/Linux-System erledigt das das Programm ssh-keygen. Um ein Schlüsselpaar zu generieren, müsst ihr es wie folgt aufrufen:

ssh-keygen -t rsa -C 'fat-lobyte@heimpc'

Der Schalter -t rsa gibt an, ssh-keygen soll einen Schlüssel für den RSA Algorithmus erzeugen, im Gegensatz zu einem Schlüssel für den DSA Algorithmus ¹⁾.
Der Schalter -C 'fat-lobyte@heimpc' gibt an, dass im Schlüssel als Kommentar fat-lobyte@example.com stehen soll. Üblicherweise gibt man dort seine E-Mail Adresse an oder den Benutzernamen, ein '@'-Zeichen und den Hostnamen auf dem der Schlüssel liegt.

ssh-keygen fragt euch nun einige Dinge, meist reicht es aber aus einfach die Entertaste zu drücken:

$ ssh-keygen -t rsa -C fat-lobyte@heimpc
Generating public/private rsa key pair.
Enter file in which to save the key (/home/fat-lobyte/.ssh/id_rsa): 
Enter passphrase (empty for no passphrase): 
Enter same passphrase again: 
Your identification has been saved in /home/fat-lobyte/.ssh/id_rsa.
Your public key has been saved in /home/fat-lobyte/.ssh/id_rsa.pub.
The key fingerprint is:
c7:94:81:2f:f5:69:f0:11:40:04:11:82:4d:cb:4d:b3 fat-lobyte@example.com
The key's randomart image is:
+--[ RSA 2048]----+
|     +o *B=...   |
|    ...=.ooo.    |
|      o Eoo+ o   |
|        .o. =    |
|        S.o.     |
|         .       |
|                 |
|                 |
|                 |
+-----------------+

Die erste Frage ist, wo ihr den Schlüssel ablegen wollt. Standardmäßig ist das die Datei ~/.ssh/id_rsa. Es ist eine gute Idee diesen Ort einfach zu belassen, drückt bei der ersten Frage also einfach nur die Entertaste.

Die Zweite Frage ist die Frage nach dem Passwort für den Schlüssel, sofern ihr einen Setzen wollt. Ein Passwort solltet ihr setzen, wenn ihr vorhabt den Schlüssel irgendwie herumzutragen (z.B. auf einem USB-Stick) ²⁾. Ich persönlich setze meist kein Passwort.
Gebt nun entweder ein Passwort ein oder nichts, wenn ihr keins setzen wollt und drückt dann die Entertaste. Wiederholt das Passwort (oder nichts) und drückt erneut die Entertaste, um das Passwort (oder dessen nicht vorhanden sein) zu bestätigen.

Und schon seid ihr fertig! Ihr bekommt auf der Konsole den Ort eurer Schlüsseldateien nochmal ausgegeben, den Fingerprint und ein hübsches „Randomart“-Bild.

Gratulation, ihr habt somit euer erstes SSH-Schlüsselpaar erstellt!

Euer Schlüsselpaar besteht aus zwei Dateien, einerseits dem geheimen Schlüssel (~/.ssh/id_rsa) und dem öffentlichen Schlüssel (~/.ssh/id_rsa.pub). Gebt den geheimen Schlüssel nie aus der Hand oder übertragt ihn über das Netzwerk! Das ist auch nicht notwendig, denn nur der öffentliche Schlüssel wird verteilt.

Überprüft nun die Berechtigungen für das Schlüsselverzeichnis. Nur ihr dürft darauf Lese- und Schreibzugriff haben:

$ ls -ld ~/.ssh/
drwx------ 2 fat-lobyte fat-lobyte 4096 2010-07-11 14:35 .ssh/
fat-lobyte@vb-ubuntu:~$ ls -l ~/.ssh/
insgesamt 12
-rw------- 1 fat-lobyte fat-lobyte  404 2010-07-08 15:35 authorized_keys
-rw------- 1 fat-lobyte fat-lobyte 1675 2010-07-11 14:35 id_rsa
-rw------- 1 fat-lobyte fat-lobyte  402 2010-07-11 14:35 id_rsa.pub

Ist dies nicht der Fall, entzieht der Gruppe und allen Anderen mit chmod die Rechte:

chmod -R go-rwx ~/.ssh

Habt ihr eine SSH-Schlüsselpaar erstellt, könnt ihr es nun verwenden um euch auf entfernten Maschinen einzuloggen.

Die Datei ~/.ssh/id_rsa.pub enthält den öffentlichen Schlüssel, der zum einloggen benötigt wird (Achtet auf die Dateiendung .pub! Das ist euer öffentlicher Schlüssel, die Datei ohne Dateiendung ist euer geheimer Schlüssel!)

Dieser Schlüssel muss nun irgendwie auf der entfernten Maschine landen. Dies könnt ihr unter anderem mit dem Programm scp bewerkstelligen:

scp ~/.ssh/id_rsa.pub fat-lobyte@example.com

Dafür werdet ihr noch euer Passwort benötigen.

Kopiert dann auf der entfernten Maschine den Schlüssel in eine Datei namens ~/.ssh/authorized_keys:

fat-lobyte@heimpc$ ssh fat-lobyte@example.com
fat-lobyte@example.com's password: 
fat-lobyte@example.com$ cat id_rsa.pub >> ~/.ssh/authorized_keys

Auch hier werdet ihr euer Passwort eingeben müssen.

Die Datei „~/.ssh/authorized_keys“ kann ein oder mehrere öffentliche Schlüssel enthalten, für die der Login für diesen User erlaubt ist.

Alternativ zu diesen Schritten kann man die Arbeit auch einfach ssh-copy-id erledigen lassen. Dieses tut intern aber genau das was wir gerade getan haben.

fat-lobyte@heimpc$ ssh-copy-id fat-lobyte@example.com

Hier werdet ihr hoffentlich zum letzten mal nach dem Passwort gefragt.

Auch auf der entfernten Maschine sollten die Befugnisse für das SSH-Verzeichnis richtig gesetzt werden:

fat-lobyte@example.com$ chmod -R go-rwx ~/.ssh

Versucht euch noch einmal auf dem entfernten Server einzuloggen. Wenn ihr dieses mal nicht nach dem Passwort gefragt werdet, hat alles funktioniert. Gratulation!

Wenn ihr wieder nach dem Passwort gefragt werdet, hat wohl etwas nicht ganz funktioniert. Hier einige Punkte die ihr überprüfen solltet:

• Habt ihr den richtigen Schlüssel upgeloadet? Nicht vergessen, der öffentliche Schlüssel ist ~/.ssh/id_rsa.pub
• Habt ihr ihn in die richtige Datei kopiert? Die Datei muss ~/.ssh/authorized_keys heißen.
• Stimmen die Berechtigungen? Manche ssh-agent's ³⁾ weigern sich den Login ohne Passwort zuzulassen, wenn das ~/.ssh zu viele Berechtigungen hat. chmod -R go-rwx ~/.ssh ausführen
• Leider erlauben manche Serveradministratoren den Login mit einem SSH-Schlüsselpaar nicht. Das könnt ihr überprüfen, indem ihr in der Datei /etc/ssh/sshd_config nachseht (diese Datei ist für einen Benutzer nicht schreibbar, aber oft lesbar). Die Option RSAAuthentication (für SSH-Protkoll 1) oder PubkeyAuthentication (für SSH-Protokoll 2) muss auf yes gesetzt sein:

  fat-lobyte@example.com$ grep '\(RSAAuthentication\|PubkeyAuthentication\)' /etc/ssh/sshd_config
  RSAAuthentication yes
  PubkeyAuthentication yes

Hat dir diese Antwort geholfen? Wenn nicht oder wenn du Verbesserungs- bzw. Erweiterungsvorschläge hast, dann schreib das bitte einfach auf die Diskussionsseite.