SSH-Schlüssel anlegen und Hosts verwalten

Wie man mehrere SSH-Schlüssel anlegt und die jeweiligen Hosts bequem per Konfigurationsdatei verwaltet

Momentan überarbeite ich meine private Serverdokumentation und möchte sie Stück für Stück dann auch hier im Blog veröffentlichen. Zum einen, um das dank zahlreicher Quellen gelernte Wissen wieder weiterzugeben, zum anderen, um Anregungen und Verbesserungsvorschläge zu sammeln.

Heute geht’s nochmal um ein Meta-Thema, nämlich um die Frage, wie man SSH-Schlüssel anlegt und verwaltet.

Im Folgenden zeige ich, wie ich meine Schlüsselverwaltung handhabe. Zugegeben, ich bin kein Sicherheitsexperte und Kryptographie ist auch nicht mein Spezialgebiet, wie der Kenner anhand der genutzten Terminologie vermutlich unschwer erkennen kann. ;-) Umso mehr freue mich über Rückmeldungen und Verbesserungsvorschläge.

Der folgende Blogbeitrag richtet sich primär an Administratoren, die schon Erfahrungen mit SSH haben und spart bewusst einige Erklärungen aus bzw. gibt diese verkürzt wieder - er ist explizit keine vollständige Anleitung zur Installation von SSH auf dem eigenen Server!

Eine Frage des Typs

SSH-Schlüssel trifft man heutzutage in verschiedenen Varianten an:

• DSA-Schlüssel kommen (zumindest gefühlt) mittlerweile selten zum Einsatz
• RSA-Schlüssel sind der meiner Meinung nach am weitesten verbreitete Typ
• ECDSA-Schlüssel arbeiten mit elliptischen Kurven, werden aber von einigen Leuten gemieden
• Ed25519-Schlüssel sind eine noch recht neue Entwicklung

Die größtmögliche Kompatibilität bieten derzeit RSA-Schlüssel, als Schlüssellänge nutze ich 4096 Bit. Das funktioniert bislang mit jeder Gegenstelle problemlos und sollte nach heutigem Stand auch ausreichend sicher sein.

Ein wahres Wort

Sicherheit ist in diesem Fall natürlich relativ - um sich Zugriff auf einen SSH-Schlüssel zu verschaffen, benötigt ein Angreifer neben der eigentlichen Schlüsseldatei auch das geheime Passwort, um diese zu öffnen. Wichtig ist daher, nicht nur die Datei gut zu verwahren, sondern auch ein sicheres und ggf. regelmäßig geändertes Passwort zu verwenden, ausreichend lang, idealerweise mit Groß- und Kleinschreibung, Zahlen und Sonderzeichen.

Öffentliches und Privates gut getrennt

SSH-Schlüssel funktionieren ähnlich wie PGP-Schlüssel - es gibt einen privaten Schlüssel, der immer sicher verwahrt werden sollte und einen öffentlichen Schlüssel, der auf den jeweiligen Servern als Zugangskontrolle hinterlegt wird. Keinesfalls darf der private Schlüssel hochgeladen werden!

Darf’s a bisserl mehr sein?

Für den Fall der Fälle greife ich nicht nur auf einen SSH-Schlüssel zurück, sondern habe mir pro Gerät einen eigenen mit jeweils separatem Passwort erstellt. Andere nutzen pro Organisation bzw. Kunde oder pro Hoster einen separaten Schlüssel.

Der Hintergrund ist recht einfach: Verschafft sich ein Angreifer doch einmal Zugriff auf den geheimen Schlüssel samt Passwort, so wären sofort alle Systeme kompromittiert, ein Austausch mitunter mühselig. Ist der entwendete Schlüssel aber zuordenbar, weil unterwegs beispielsweise das Notebook geklaut worden ist, so lässt er sich schnell von allen Servern zurückziehen, ohne dass der am heimischen Desktop hinterlegte Schlüssel betroffen ist - man kann also weitestgehend nahtlos weiterarbeiten.

SSH-Client konfigurieren

Am Anfang empfiehlt es sich, den lokalen SSH-Client an die eigenen Wünsche anzupassen. Unter Mac OS X oder Linux setze ich dazu folgende Optionen in meiner ~/.ssh/config:

HashKnownHosts yes
VerifyHostKeyDNS ask
VisualHostKey yes

Die Einstellungen sorgen dafür, dass die Hostnamen der Zielserver nur mittels Hash gespeichert werden statt im Klartext (HashKnownHosts yes), dass der SSH-Client nach so genannten SSHFP-Einträgen im DNS suchen soll, um die Echtheit des Fingerprints zu verifizieren (VerifyHostKeyDNS ask) und dass der Fingerprint zudem in Form eines kleinen Bildes visualisiert werden soll (VisualHostKey yes).

Schlüssel erzeugen

Um nun einen RSA 4096-Schlüssel zu erzeugen, ruft man einfach folgenden Befehl auf:

ssh-keygen -t rsa -b 4096 -C rsa4096zuhause -f ~/.ssh/rsa4096zuhause

Das erzeugt im Homeverzeichnis unter .ssh/rsa4096zuhause einen Schlüssel vom Typ RSA mit der Schlüsselgröße 4096 und fügt rsa4096zuhause ins Kommentarfeld ein. SSH-Keygen fragt sodann noch das Passwort an, mit dem der Schlüssel gesichert wird und erstellt abschließend zwei Dateien:

• rsa4096zuhause ist der private Schlüssel, der keinesfalls weitergegeben werden darf
• rsa4096zuhause.pub ist der öffentliche Schlüssel, der am Server unter ~/.ssh/authorized_keys hinterlegt werden muss.

Tipp: Manche Provider erlauben auch, die eigenen Schlüssel in deren Webinterface zu hinterlegen, damit sie bei der Neuinstallation des Servers automatisch genutzt werden.

Auf dieselbe Art und Weise lassen sich Schlüssel für alle anderen Geräte erstellen, z.B. den Bürorechner, das Notebook und bei Bedarf auch fürs Smartphone - nur ein anderer Namen muss vergeben werden, damit die Schlüssel unterschieden werden können.

Schlüsselkompetenz

Um nun die Verbindung unter Benutzung des gerade erstellten Schlüssels herzustellen, ist folgende Kommandozeile nötig:

ssh benutzer@server.domain -i ~/.ssh/rsa4096zuhause

Bei der erstmaligen Benutzung fragt der so genannte SSH-Agent das vorhin vergeben Passwort ab. Wer das lästige Eintippen schon im Vorfeld erledigen will, kann den Schlüssel als so genannte Identität mit

ssh-add ~/.ssh/rsa4096zuhause

z.B. im Startskript des Rechners hinzufügen. Eine Liste aller derzeit aktiven bzw. entsperrten Identitäten gibt’s mit

ssh-add -L

Mittels ssh-add können Identitäten auch wieder gesperrt bzw. entfernt werden.

Kurzer Prozess

Bei verschiedenen Servern, Benutzernamen, Schlüsseln und Ports kann das Eintippen der Kommandozeile schon mal zur Qual werden. Abhilfe verschafft hier die schon eingangs genannte Datei ~/.ssh/config, in der sich all diese Parameter mit einem Alias versehen lassen. Das Ganze sieht beispielsweise so aus:

Host fileserver
HostName server1.meine.domain
User maxmuster
IdentityFile ~/.ssh/rsa4096zuhause
Port 222

Um auf den Server server1.meine.domain zuzugreifen, dabei den Benutzernamen maxmuster zu nutzen, sowie den abweichenden Port 222 (SSH-Standardport ist 22) und die Schlüsseldatei ~/.ssh/rsa4096zuhause zu verwenden, genügt fortan ein

ssh fileserver

Auch Kombinationen mit Parametern sind möglich, so würde beispielsweise

ssh johndoe@fileserver -L 8080:localhost:443

die Verbindung mit dem Benutzernamen johndoe aufbauen und zudem eine lokale Weiterleitung von Port 8080 auf Port 443 des Zielservers einrichten.

Ausblick: Hardware-Tokens

Eine noch sicherere Variante sind so genannten Hardware-Tokens, beispielsweise ein YubiKey, die den Schlüssel sicher verwahren - technisch bedingt kann er zwar auf dem Gerät erzeugt werden, der private Teil das Token jedoch niemals verlassen. Das Ganze funktioniert unter anderem mittels gpg-agent, der den auf dem YubiKey erzeugten GnuPG-Schlüssel für den SSH-Server aufbereitet - doch dazu später mehr in einem eigenen Blogposting…