Heute kam mir beim Lesen einer von Hakin9 auf Facebook geteilten Anleitung eine Idee: Ich werde ab sofort regelmäßig schlechte und unsichere Tutorials/Howtos und Tipps kommentieren und erklären wie man es besser macht. Wenn sogar ein "IT Security Magazin" wie Hakin9 schlechte Anleitungen teilt ohne auf die Probleme darin aufmerksam zu machen, gehe ich davon aus, dass ich für diese Serie mehr als genug Vorlagen finden werde.
Den Anfang in dieser Serie macht folgende Anleitung: https://linux.tips/tutorials/how-to-login-ssh-with-private-key (Stand: 13. Mai 2018).
Ein wichtiger Hinweis vorweg: Key Authentication ist natürlich bei weitem sicherer als eine Passwort-basierte Variante und sollte, besonders für SSH-Zugriffe über das Internet, immer die erste Wahl sein. Der Grund, warum ich mir genau diese Anleitung als Anfang herausgesucht habe, ist der, dass der Inhalt schon seit Ewigkeiten bekannt ist und es schon tausende Anleitungen dazu gibt. Somit ist die verlinkte Anleitung bestenfalls redundant und schlimmstenfalls ein schlechte Kopie (wenn man in angegebenen Referenzen reinschaut sieht man sofort, dass viel Inhalt Copy&Paste von hier war). Zusätzlich sind in der Anleitung einige Stellen veraltet, es fehlen wichtige Informationen und notwendige Sicherheitsmaßnahmen.
cd ~/.ssh
ssh-keygen -t rsa
Wie man in der Ausgabe in der Anleitung sehen kann, erzeugt der Aufruf ssh-keygen -t rsa einen RSA Schlüssel mit einer Länge von 2048bit. Das entspricht den heutigen minimal Längen die man noch sicher verwenden kann. Github empfiehlt zum Beispiel aktuell 4096bit. Darüber, ob ein Schlüssel bereits heute so lang sein muss, kann man sich streiten. Aber, solange man nicht auf einem embedded System ist, tut es nicht weh und somit sollte es zumindest die Empfehlung sein. Für eine Anleitung die im Mai 2018 veröffentlicht wird ist es auf jeden Fall zu kurz.
Ich persönlich erzeuge meine Schlüssel zur Zeit mit folgendem Befehl:
ssh-keygen -t ed25519
Damit erzeuge ich einen asym. Key-Paar mit der Länge von nur 256bit. Da ich allerdings an Stelle von RSA den Algorithmus ed25519 verwende, erreiche ich damit ein Sicherheitsniveau welches RSA mit ca. 3072bit entspricht! Neben der kleineren Schlüssellänge ist ed25519 auch in der Berechnung schneller als RSA mit einer vergleichbaren Sicherheit. Somit ist das auch eine Variante, die auf embedded Systemen mit begrenzen Ressourcen gut und sicher funktioniert.
In Step 1. geht der Autor zusätzlich auch noch auf die "optionale" Passphrase ein:
When asked for passphrase, leave it blank or enter your desired passphrase. Having a passphrase makes automation difficult for some of the processes.
Er rät somit mehr oder weniger von dem Setzen eine Passphrase ab. Er hat zwar recht mit seinem Hinweis das eine Passphrase eine automatisierte Verwendung des Schlüssel erschweren kann, allerdings erklärt er nicht was eine Passphrase bringt und was man beachten sollte, wenn man sie nicht setzt:
Wenn keine Passphrase gesetzt ist, liegt der private Schlüssel unverschlüsselt im Dateisystem. Jeder der Zugriff auf die Datei erlangte hat somit automatisch auch Zugriff auf den Inhalt. Auf einem Single-User-System ist das vielleicht nicht so kritisch, aber auf einem Multi-User-System oder auf Server-System sollte man mit SSH-Schlüsseln ohne Passphrase sehr vorsichtig umgehen.
Als Alternative zu Passphrase-losen Schlüsseln kann man oft auch auf SSH Agents (sehr einfach mit mittels Keychain nutzbar) zurückgreifen. Allerdings setzt auch das zumindest eine einmalige Eingabe der Passphrase nach dem Systemstart voraus. Wenn gar keine Benutzerinteraktion möglich ist, kenne ich leider auch keine andere Möglichkeit als einen Schlüssel ohne Passphrase zu verwenden.
Wenn es nicht anders geht als mit einem Schlüssel ohne Passphrase sollte man folgende Maßnahmen umsetzen um das damit verbundene Risiko zu reduzieren:
- Der Passphrase-lose Schlüssel sollte stark in seinen Berechtigungen eingeschränkt werden. Das lässt sich einfach über die Datei ~/.ssh/authorized_keys auf dem Zielsystem erreichen. Die verfügbaren Optionen sind im SSH Manual sshd(8) unter AUTHORIZED_KEYS_FILE_FORMAT aufgeführt. Besonders wichtig ist die Option command. Solange die nicht gesetzt ist, könnte man sich mit dem Schlüssel anmelden und die Datei authorized_keys editieren um die Restriktionen wieder aufzuheben.
- Man sollte für normalen/ nicht automatisierten SSH Zugriff immer einen Schlüssel mit Passphrase verwenden.
- Der automatisierte Zugriff auf dem Zielsystem sollte nur auf einen stark limitierten Benutzer erfolgen.
- Idealerweise sollte für den automatisierten Zugriff über SSH ein eigener Benutzer auf dem Zielsystem eingerichtet werden. In dem Fall kann der SSH Zugriff zentral über die sshd_config für den Benutzer beschränkt werden (robuster als per authorized_keys)
Die folgenden Abschnitte Step 2.-5. können getrost ignoriert werden. Sie lassen sich vollständig mit einem Aufruf von ssh-copy-id ersetzen:
ssh-copy-id -i [PATH-TO-ID.pub] user@target
Zu Step 3: Copy public key file from client to the server machine muss ich allerdings trotzdem noch etwa schreiben. Der Vorschlag in der Anleitung ist es, den pub. Key wie folgt per SCP auf das Zielsystem zu kopieren:
scp -P "ssh-port" ~/.ssh/id_dsa.pub username@serverip-address:~/.ssh
Das geht theoretisch zwar auch, man sollte aber niemals dem Vorschlag aus der Anleitung folgen und den Key direkt nach ~/.ssh zu kopieren. Der Autor geht davon aus, dass ~/.ssh leer ist. Wenn dort bereits ein Key-Paar liegt wird der pub. Key von SCP ohne Rückfrage überschrieben!
Nachdem getestet wurde ob der Zugriff mittels Key funktioniert, sollte als nächstes der Login mittels Password deaktiviert werden. Wie der Autor korrekterweise schreibt, macht dieser Schritt Bruteforce Angriffe nahezu unmöglich. Leider wird in der Anleitung nicht aufgeführt wie das funktioniert: Hierzu muss nur die Option PasswordAuthentication in der Datei /etc/ssh/sshd_config auf no gesetzt werden.
