SSH Login über Schlüsseldatei
Im Standard erfolgt die Authentifizierung beim SSH Login auf ein Gerät mit Benutzername und Passwort. Es gibt aber auch die Möglichkeit, dies weiter abzusichern, indem wir die Anmeldung über eine Schlüsseldatei (Keyfile) einrichten. Man spricht hier auch vom "key-based SSH login".
Bei diesem Verfahren erstellen wir auf jedem unserer Geräte, die Zugriff auf den Server haben sollen, eine Schlüsseldatei. Dem Server teilen wir mit, welche Schlüssel Zugriff auf den Server haben dürfen. Damit ist der Login zukünftig nur mit dieser Datei möglich und es wird kein Benutzername und Passwort mehr abgefragt. Diese Schlüsseldatei ist damit wie ein Haustürschlüssel anzusehen, er gewährt vollen Zugriff und sollte niemals das Gerät verlassen. Die Schlüsseldatei lässt sich noch zusätzlich mit einem Passwort sichern, sodass man dieses erst eingeben muss, bevor der Schlüssel genutzt werden kann.
Voraussetzungen
Es wird davon ausgegangen, dass der Server bereits gemäß dem Beitrag Debian Server / vServer grundlegend absichern eingerichtet wurde. Es wurde also bereits ein separater Benutzer angelegt, über den der Login erfolgt und es wird nicht mehr root dafür genutzt.
Schlüsseldatei erstellen
Zunächst erstellen wir eine Schlüsseldatei auf dem Gerät, mit dem wir uns auf dem Server einloggen wollen. Wir öffnen dafür ein Terminal (macOS/Linux) oder eine Powershell (Windows) und geben folgenden Befehl ein:
ssh-keygen -b 4096
Es folgt eine Abfrage nach dem Speicherort der Datei. Hier kann der Standard beibehalten und einfach mit Enter bestätigt werden. Die Datei wird im Home-Verzeichnis des Benutzers im Unterordner .ssh gespeichert und id_rsa genannt.
Anschließend wird nach einem Passwort gefragt. Wenn man hier nichts angibt, wird eine Schlüsseldatei ohne Passwort erstellt. Ohne Passwort bedeutet: Jeder, der an diese Datei kommt, kann sich auf dem Server einloggen. Wie wahrscheinlich es ist dass die Datei das eigene Gerät verlässt, muss jeder für sich selbst einschätzen.
Das Passwort muss zweimal eingegeben und mit Enter bestätigt werden. Es ist normal, dass bei der Eingabe des Passworts ggf. nichts angezeigt wird, auch keine "****".
Wenn man jetzt ein ls -l auf das angegebene Verzeichnis ausführt, in dem die Dateien gespeichert wurden, sieht man zwei neue Dateien:
ls -l $HOME/.ssh
Die Datei id_rsa ist der private Schlüssel, dieser darf das Gerät niemals verlassen und der Inhalt darf nicht weitergegeben werden!
Die Datei id_rsa.pub erhält den öffentlichen Schlüssel. Dieser Inhalt muss auf den Server kopiert werden, damit dieser zukünftig den Schlüssel akzeptiert.
Öffentlichen Schlüssel auf Server kopieren
Der öffentliche Schlüssel muss jetzt auf den Server, damit unser neuer Schlüssel auch akzeptiert wird. Dafür gibt es zwei Methoden. Unter Windows mit der Powershell funktioniert nur Methode 2.
Methode 1
Im Terminal von macOS und Linux funktioniert der Befehl ssh-copy-id. Dieser führt ein paar Schritte hintereinander aus, die man sonst manuell machen müsste (wie in Methode 2 beschrieben). Der Befehl loggt sich auf dem Server per Benutzername/Passwort ein und kopiert den öffentlichen Schlüssel in die authorized_keys-Datei auf dem Server. Sollte die Datei nicht existieren, wird sie angelegt. Alles was man dafür ausführen muss ist:
ssh-copy-id benutzername@serveripDanach wird angezeigt, welcher öffentliche Schlüssel übertragen wird. Da wir sonst noch keine anderen Schlüssel angelegt haben, sollte das passen.
/usr/bin/ssh-copy-id: INFO: Source of key(s) to be installed: "/home/viertelwissen/.ssh/id_rsa.pub"
Wenn man sich zum ersten Mal verbindet, erhält man auch nochmal den Hinweis, dass der Serverkey nicht bekannt ist, den man einfach mit "yes" bestätigt:
The authenticity of host 'IP-ADRESSE (IP-ADRESSE)' can't be established.
ECDSA key fingerprint is SHA256:rPSYH5cMQ7ZtbzqGsJmXmb8lT4DKCk053jaiDwHBdHw.
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Anschließend wird man zur Eingabe des Passworts des Benutzers auf dem Server aufgefordert (nicht das Passwort der Schlüsseldatei!). Ist das erledigt wird der Schlüssel auf den Server übertragen.
Methode 2
Sollte ssh-copy-id nicht zur Verfügung stehen oder aber der Login per Benutzername/Passwort auf dem Server bereits deaktiviert sein, muss der öffentliche Schlüssel manuell auf dem Server eingetragen werden.
Dazu lassen wir uns zunächst den öffentlichen Schlüssel im Terminal oder auf der Powershell ausgeben, um ihn leicht kopieren zu können:
cat /home/username/.ssh/id_rsa.pub
Der komplette Teil, der dabei ausgegeben wurde, muss kopiert werden. Der Befehl zum Kopieren kann sich je nach Terminal/System unterscheiden, da muss man ggf. einfach ausprobieren:
- Markieren, Rechtsklick auf markierte Stelle (Windows Powershell)
- COMMAND + C (Mac)
- STRG + C oder STRG + SHIFT + C (Linux)
Jetzt loggen wir uns auf dem Server ein: ssh benutzername@serverip
Nach dem Login befinden wir uns in dem Verzeichnis unseres Benutzers, was wir mit dem Befehl pwd auch nochmal kontrollieren können. Mit ls -la lassen wir uns alle vorhandenen Dateien und Ordner anzeigen, auch die Versteckten.
Wird hier ein Ordner mit dem Namen .ssh angezeigt ist alles in Ordnung. Falls nicht, legen wir diesen an mit:
mkdir $HOME/.ssh
Wir müssen jetzt die Datei authorized_keys anpassen, die sich im Ordner .ssh befinden muss. Dazu öffnen wir diese mit dem Editor nano:
nano $HOME/.ssh/authorized_keysWenn die Datei bereits existiert, wird sie zum Bearbeiten geöffnet, wenn nicht, wird sie angelegt. Hier fügen wir jetzt unseren öffentlichen Schlüssel ein. Dieser besteht nur aus einer langen Zeile und darf nicht umgebrochen werden. Falls schon Einträge vorhanden sind, muss der neue Schlüssel in eine neue Zeile.
Wir bestätigen die Änderung mit STRG+O (Mac: CONTROL+O) und ENTER. Anschließend sollte uns mit ls -la $HOME/.ssh die Datei authorized_keys angezeigt werden.
Damit ist der Vorgang, der sonst von ssh-copy-id übernommen wird, abgeschlossen.
Login mit Schlüsseldatei
Für den Login mit der Schlüsseldatei reicht der normale SSH-Befehl, wie er auch zuvor genutzt wurde:
ssh benutzername@ipadresse
Der SSH-Dienst probiert erst alle verfügbaren Schlüssel durch und erst wenn keiner funktioniert, wechselt er auf das Benutzername/Passwort-Verfahren. Es kann auch explizit ein Schlüssel angegeben werden, der genutzt werden soll, in dem Fall sieht der Befehl so aus:
ssh -i $HOME/.ssh/id_rsa benutzername@serverip
Beim Login muss jetzt das Passwort der Schlüsseldatei angegeben werden, sofern eins vergeben wurde.
Wenn man prüfen möchte, ob wirklich die Schlüsseldatei genutzt wurde, kann man den SSH-Befehl mit -v ergänzen. Damit wird beim Verbindungsaufbau jeder einzelne Schritt geloggt.
ssh -v benutzername@ipadresse
oder
ssh -v -i $HOME/.ssh/id_rsa benutzername@ipadresse
Wenn ihr in der Ausgabe den in der Grafik markierten Abschnitt findet, ist der Login über die Schlüsseldatei erfolgt.
Zusätzliche Backup-Schlüsseldatei
Im Beitrag zur besseren Absicherung des SSH-Servers werden wir empfehlen, die Authentifizierung über Benutzername/Passwort vollständig zu deaktivieren und nur noch den Login per Schlüsseldatei zu erlauben. Dazu wäre es ratsam, einen Backup-Schlüssel zu erstellen und zu authorisieren und diesen zum Beispiel in einem Passwortmanager wie Bitwarden sicher abzulegen. Andernfalls würdet ihr den Zugriff auf euren Server verlieren, sollte das berechtigte Gerät verloren gehen oder kaputt gehen.
Einen weiteren Schlüssel mit einem anderen Dateinamen legt ihr so an:
ssh-keygen -b 4096 -f $HOME/.ssh/backupkey
Der neue Schlüssel liegt dann wie der andere im Unterverzeichnis .ssh des Benutzers, nur heißt er backupkey statt id_rsa.
Abschluss
Nachdem ihr euch jetzt über eine Schlüsseldatei auf dem Server einloggen könnt, empfehlen wir im Nachgang die zusätzliche Absicherung des SSH-Servers.
Bei Anmerkungen oder Fragen kommt gerne auf unseren Discord.
