ssh key erstellen
Webentwickler und Serveradmins verwenden gerne die cBUZZ LinuX Server mit root Zugriff. Heute behandeln wir die Frage: Wie erstelle ich einen ssh key für meinen cBUZZ Server?
Mit Hostname, Servername und dem Passwort kommst du mit dem SSH-Befehl in die Kommandozeile des Servers.
ssh [email protected] # PW eingeben ...
~# cat /etc/hosts
Wie bewege ich mich auf meinem Server? Was ist notwendig für ein stabiles System? Wie war das nochmal mit der Sicherheit? Wie komme ich am einfachsten und schnellsten auf den Server?
Viele Webentwickler haben mit einem Webserver und Datenbanken ja keine Probleme, alles andere müssen sie sich in der Console auf dem Server jetzt erst einmal ansehen.
Wie richte ich mir einen ssh key ein?
Du hast zwei Möglichkeiten einen ssh key auf deinem PC zu erstellen: Mit ssh key Passwort oder ohne ssh key Passwort. Wenn der User auch root Rechte am Server hat (sudo), verwende bitte nur ssh keys mit Passwort. Dieses Passwort kann ja sicher und für dich einfach zu merken sein. Es ist dann wie ein PIN Code deiner Bankomatkarte. Für User mit eingeschränkten Rechten (zum Beispiel für automatische Backup Jobs) kannst du auch ssh keys ohne einem Passwort erstellen.
Um dich zum Beispiel für einen rsync Backup Job nicht immer mit meinem Passwort auf dem Server anmelden zu müssen, bietet das ssh-Protokoll die Authentifizierung über einen öffentlichen Schlüssel ( ssh Public-Key Authentifizierung ). Dafür werden ein Private Key auf dem Client und ein Public Key auf dem Server hinterlegt, mit denen eine Authentifizierung ohne Passwort möglich ist.
me@home: ~$ ssh-keygen -t rsa -b 4096
Mit diesem Befehl wird ein Schlüsselpaar erzeugt. Dabei gibst du den Typ “RSA” und die Verschlüsselungstiefe in bit mit 4096 an.
Generating public/private rsa key pairEnter file in which to save the key (/home/me/.ssh/id_rsa)
Wenn die location und der Dateiname so passt, dann kannst du hier einfach “Enter” drücken. Ansonsten einfach den absoluten Pfad angeben, wo die ssh keys gespeichert werden sollen.
Enter passphrase (empty for no passphrase):
Falls du - typischerweise für einen sudo User mit root Rechten - die Sicherheit des private Keys erhöhen erhöhen willst, trage da ein Passwort ein. Du wirst anschließend aufgefordert, das Passwort nochmal einzugeben. Dieses Passwort hat nichts mit dem Passwort des Users am Server zu tun. Es ist vielmehr eine eigenständige, sichere aber für dich doch einfach zu merkende Passwortphrase, ähnlich eines PIN Codes.
Your identification has been saved in /home/me/.ssh/id_rsaYour public key has been saved in /home/me/.ssh/id_rsa.pub
+---[RSA 4096]----+The key's randomart image is:
|. . o.o... |
| E =.o. |
|o. .o= .. |
|.o. o= o . o..|
| .o .o S . +.B.|
| . . o o +.+.=|
| . . *.+.|
| ..++.+|
| o+o*+.|
+----[SHA256]-----+
Und fertig ist das Schlüsselpaar. 
Jetzt muss der öffentliche Schlüssel auf den Server kopiert werden.
me@home:~$ ssh-copy-id -i /home/me/.ssh/id_rsa [email protected]
mit -i gibst du die Identifikationsdatei an und schließt mit dem Benutzer@Host ab. Dann noch schnell das Passwort des Users am Server eingeben und schon sollte der public key auf dem Server sein. Um den Private-Key noch sicherer zu machen, wandeln wir den Private-Key in ein anderes Format um (PCKS#8).
Erstmal bennene ich die Private-Key-Datei und wandle sie anschließend in das neue Format um.
me@home: ~/.ssh$ mv id_rsa id_rsa.bakme@home: ~/.ssh$ openssl pkcs8 -topk8 -v2 des3 \-in id_rsa.old -out id_rsa.bak
Dieses Format ist noch sicherer gegen Brute-Force Attacken und vor allem abwärtskompatibel, da PCKS#8 Bestandteil von openSSL und das wiederum von openSSH ist.
Nun kannst du dich mit
me@home:~$ ssh [email protected]
auf deinem cBUZZ Server anmelden, ohne ein Passwort zu benutzen für Backupjobs oder mit deiner leicht zu merkenden Passwortphrase, die du bei der ssh key Erstellung auf deinem PC angegeben hast. War die Anmeldung erfolgreich, lösche bitte noch das Backup des Private-Keys.
me@home: ~/.ssh$ rm id_rsa.bak
Somit ist das Handwerkliche schon mal erledigt. Allerdings haben sich bei mir beim copy & paste weitere Fragen zu dem „Warum mache ich das so“ ergeben, auf die ich jetzt noch näher eingehen werde.
RSA vs. DSA
Erstmal, was ist RSA überhaupt? Hört sich schlau und wichtig an, aber was ist das?
Die Kurzform besteht eigentlich nur aus einer Auflistung von Namen. Rivest, Shamir und Adleman. Die drei versuchten am MIT die Theorie von Diffie und Hellmann zu widerlegen, die eine Theorie zur Public-Key-Verschlüsselung aufgestellt hatten. Letztendlich kam ein Public-Key-Verschlüsselungsverfahren, welches scheinbar sicher war. Also ein Verschlüsselungsverfahren, das auch zur digitalen Signatur genutzt werden kann. Dazu gibt es einen privaten Schlüssel, der auf dem eigenen System liegen bleibt, und einen öffentlichen Schlüssel, der frei weitergegeben werden kann. Mit diesen beiden Schlüsseln können dann Signaturen erstellt, verschlüsselt und entschlüsselt und letztendlich auch dahingehend verifiziert werden, dass man auch der ist, der man vorgibt zu sein.
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 von vielen nicht mehr empfohlen, da diese nur auf eine Schlüssellänge von 1024 bit begrenzt ist. RSA keys sind da nicht so eingeschränkt. Ein Versuch mit 16384 bit war ohne Probleme möglich. Hat zwar etwas länger gedauert, aber es ging.
Welche ssh Schlüssellänge ist heutzutage aktuell?
Wie oben schon kurz angedeutet, dauert die Erzeugung des keys länger, je größer die Schlüssellänge in Bit gewählt wird und ist damit auch rechenleistungsabhängig. Das Ver- und Entschlüsseln dauert dementsprechend auch länger. Die Standardlänge im SSH-Client ist auf 2048 bits gesetzt, wobei mittlerweile eine Schlüssellänge von 4096 bits oder 8192 bits empfohlen wird. Ein 4096 bits langer Schlüssel wird nicht so schnell geknackt wie einer mit einer Länge von 2048 oder sogar 1024. Wobei ein 1024 bit RSA Schlüssel genauso stark ist wie ein 1024 bit DSA Schlüssel.
Ich selber habe meine Schlüssel mit 8192 bit erstellt, damit ich diesen Schlüssel auch etwas länger nutzen kann, ohne mir Sorgen um die Sicherheit meines Schlüssels machen zu müssen.
Brauche ich ein Passwort für meinen Private-Key?
Für sudo User auf einem Server mit root Rechten ein klares JA. Eine weitere Barriere, um an meinen privaten Schlüssel zu kommen, ist mir wichtig.
Wenn jemand sich aus irgendeinem Grund Zugang zu meinem Rechner verschafft hat, kann er ohne Passwort auch relativ schnell auf meinen cBUZZ Server. Um das zu verhindern, gebe ich bei jeder Anmeldung gerne meine sichere und von mir doch leicht zu merkende Passwortphrase wie einen PIN Code ein.
Zusätzlich gibt es noch kleine Helferlein wie “keepass” & Co., die einem das Eingeben des Passworts abnehmen, indem man vorher sein Masterpasswort eingibt.
In der Kurzanleitung habe ich ja schon den Private-Key in das PCKS#8 Format umgewandelt, da für Brute-Force Attacken anfälliger. Das Passwort wird nämlich nur MD5 gehasht, mit einem Salt versehen und anschließend wird der Key damit verschlüsselt. Das gehashte Passwort ist jedoch relativ leicht aus der Datei zu extrahieren und damit auch anfälliger für Brute-Force Attacken.
Fingerprint, Randomart? Warum?
Naja, das mit dem Fingerprint konnte ich mir schon halb denken. Es soll eine Eindeutigkeit von etwas darstellen.
Der Fingerprint basiert auf dem Host-Key und soll die Identifikation von Hosts erleichtern . Außerdem wird er als Indikator für MITM-Angriffe genutzt. Bei der ersten Anmeldung muss man ja bestätigen, dass man sich wirklich mit dem Server verbinden will.
Bei diesem Schritt wird der Fingerprint des Servers angezeigt und man könnte über eine andere sichere Verbindung prüfen, ob es sich wirklich um den Fingerprint des Servers handelt. Bestätigt man die Aktion mit “yes”, wird der Host in der Datei “known_hosts” gespeichert.
Bei den folgenden Anmeldungen auf dem Server wird der Fingerprint des Hosts mit dem in der Datei gespeicherten abgeglichen. Stimmen diese nicht überein, wird eine Warnung erzeugt und die Anmeldung wird abgebrochen. Meistens kommt der Fehler aber nicht von einer MITM-Attacke. Oft wurde der ssh-Server oder auch das System neu aufgesetzt. Der Eintrag muss dann einfach aus der known_hosts Datei entfernt werden, was ihr mit
me@home: ~$ ssh-keygen -R Benutzer@Host
durchführt. Beim nächsten Anmeldeversuch wird dann wieder gefragt, ob man wirklich mit dem Server verbunden werden möchte.
Das Randomart soll jetzt die “manu-visuelle” Identifikation des Servers vereinfachen, indem ein Bild aus dem Fingerprint bzw. aus dem Public-Key generiert wird. Da erkennt man auf “einen Blick ”, ob es der richtige Server ist, auf den ich mich verbinden will. Damit euch die Grafik bei Verbinden auf den Server angezeigt wird, müsst ihr eure ssh_config wie folgt anpassen.
me@home: ~$ nano /etc/ssh/ssh_config
dann einfach die Zeile
#VisualHostKey no
einkommentieren und auf yes setzen.
VisualHostKey yes
Und schon seht ihr die Grafik und könnt euren Server auch identifizieren. Das soll es auch schon gewesen sein, was das Authentifizieren per Public-Key angeht. Wir haben nun das Schlüsselpaar erstellt, auf den Server kopiert und noch kleine Anpassungen vorgenommen.
Damit kommt man schnell und sicher auf seinen Server, ohne jedes mal das sperrigen Passwort des Server-Users eingeben zu müssen.