Komfortabler Server-Login: So erstellst du einen ssh key

Zu Beginn gibt es hier eine schnelle Anleitung mit den wichtigsten Infos. Später gehe ich dann noch auf ein paar Details und Hintergründe ein. Die folgenden Commands müsst ihr bei euch lokal im Terminal / in der Konsole oder dem SSH-Client ausführen.

• -t steht für type. Hiermit wird der Algorithmus bestimmt, mit dem der Schlüssel erzeugt wird.
• -b gibt die Länge des Schlüssels in Bits an.
• -f legt den Dateinamen (und Pfad) fest, unter dem der Schlüssel abgelegt wird.

Beim Ausführen dieses Commands erscheint der Prompt:

Hier kann optional ein Passwort für den Private Key vergeben werden. Dieses wird dann immer abgefragt, wenn die Private Key Datei genutzt wird, um eine Verbindung aufzubauen. Das ist sicherer, sollte jemand zufällig oder böswillig Zugang zum System bekommen. Wer eine passwortfreie Authentifizierung erreichen möchte, muss das Passwort aber weglassen. Entscheidet ihr euch für ein Passwort müsst ihr es anschließend zur Bestätigung noch ein zweites Mal angeben.

Und schon ist der Key erstellt:

Mit diesem Command wird der Public Key des Schlüsselpaares auf den angegebenen Server kopiert. Dazu ist das Passwort des Benutzers (in meinem Beispiel p12345) für den Server notwendig.

Anschließend könnt ihr euch mit dem Schlüssel beim Server anmelden:

Habt ihr beim Erstellen des Schlüssels ein Passwort angegeben, wird dieses jetzt abgefragt, ohne erfolgt der Login jetzt passwortlos.

Der Befehl ist ganz schön lang. Um ihn nicht jedes Mal neu tippen zu müssen, kommt die Datei ~/.ssh/config ins Spiel. Sollte sie noch nicht existieren, muss sie angelegt werden. Anschließend kann hier der Host eingetragen werden.

Und schon kann man sich nur mit dem Namen des Hosts verbinden:

Der Login über eine Kommandozeile mag zunächst etwas abschreckend wirken. Mit etwas Gewöhnung könnt ihr so aber auf dem Server Dinge viel effizienter erledigen und habt viel mehr Möglichkeiten. Es lassen sich recht einfach kleine Skripte bauen und viele Content Management Systeme bieten Schnittstellen für die Kommandozeile an, z. B. die WP-CLI oder die TYPO3-CLI.
 

Eine Bespielanwendung: Benutzer aus einer Excel-Tabelle importieren. Ohne die CLI muss ich ein Plugin installieren, aktivieren, die Oberfläche suchen, die Datei hochladen, importieren und anschließend das Plugin wieder löschen. Über die CLI: Datei per scp auf den Server kopieren und mit wp user import-csv importieren – fertig!

Beim asymetrischen Public Key Verfahren werden immer zwei Schlüssel generiert: der Private Key und der Public Key. Der private Schlüssel ist geheim und entspricht in etwa dem Passwort – er sollte also den Computer, auf dem er generiert wurde, niemals verlassen und mit Sorgfalt behandelt werden. Der öffentliche Schlüssel wiederum ist – nun ja – öffentlich und kann frei weitergegeben werden. Der Clou ist jetzt, dass Signaturen, die mit dem privaten Schlüssel erstellt bzw. verschlüsselt wurden, nur mit dem passenden Gegenstück verifiziert werden können. Signaturen, die mit dem öffentlichen Schlüssel erzeugt wurden, können aber nicht durch diesen verifiziert werden. So kann letztendlich sichergestellt werden, dass man auch der ist, der man vorgibt zu sein. Solche asymmetrischen Verfahren sind übrigens auch der Standard bei SSL-Zertifikaten und damit die Basis für quasi alle Websites, die über HTTPS ausgeliefert werden – und das sind inzwischen fast alle.

Die Abkürzung  besteht eigentlich nur aus einer Auflistung von Namen: Rivest, Shamir und Adleman (RSA). Diese drei Mathematiker versuchten am MIT (Massachusetts Institute of Technology) die Theorie der Kryptologen Diffie und Hellmann zu widerlegen, die eine Theorie zur Public-Key-Verschlüsselung aufgestellt hatten. Letztendlich kam ein sicherer Verschlüsselungsalgorithmus dabei heraus, der anschließend zum Patent angemeldet wurde. RSA ist also ein Verschlüsselungsverfahren, das auch zur digitalen Signatur genutzt werden kann. Es bildet damit die Basis für die bereits beschriebene Public Key Authentifizierung.
 

Als Alternative zur RSA-Signatur gibt es noch die DSA-(Digital Signature Algorithm)Variante. Dieses Verfahren wurde von der NSA im Auftrag der US-Regierung entwickelt. Allerdings wird DSA nicht mehr empfohlen, da sie nur auf eine Schlüssellänge von 1024 Bit begrenzt ist. RSA Keys sind nicht so eingeschränkt.
 

Es gibt aber auch moderne Varianten von DSA, die auf elliptischen Kurven basieren: Elliptic Curve DSA (ECDSA oder Ed25519). Diese sind wesentlich sicherer und sogar kompakter. Inzwischen sind sie auch recht weit verbreitet, also durchaus eine Überlegung wert. RSA ist aber immer noch die beliebteste Variante.

Je größer die Schlüssellänge gewählt wird, desto länger dauert das Erzeugen und das Ver- und Entschlüsseln bei der Benutzung, aber auch die Sicherheit steigt mit der Schlüssellänge. Für einen Schlüssel mit der Länge 8 gibt es 256 Möglichkeiten. Bei doppelter Länge, also 16 Bits, sind es schon 65.536. Die Anzahl der Möglichkeiten wächst also exponentiell. (Das gleiche gilt übrigens auch für Passwörter.) Ein 4096 Bits langer Schlüssel wird daher bei Weitem nicht so schnell geknackt, wie einer mit einer Länge von 2048 oder sogar 1024.
 

Die Standardlänge im SSH-Client ist normalerweise auf 2048 Bits gesetzt, wobei mittlerweile eine Schlüssellänge von 4096 Bits empfohlen wird. Ein 1024 Bit RSA.Schlüssel ist dabei genauso stark  wie ein 1024 Bit DSA-Schlüssel.
 

Ich persönlich erstelle meine Schlüssel in der Regel mit 8192 Bit, damit ich diese auch etwas länger nutzen kann, ohne mir Sorgen um die Sicherheit meiner Schlüssel machen zu müssen.

Über SSH lassen sich viele Sachen schnell und effizient erledigen. Mit einem SSH-Key und der richtigen Konfiguration ist dann auch der Login sehr komfortabel. Der geringe Aufwand lohnt sich also auf jeden Fall. Ich habe für alle Projekte, die ich betreue einen Key eingerichtet und die Config eingetragen – ohne geht es für mich nicht mehr.