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:

1

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:

1

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:

1

ssh-copy-id benutzername@serverip

Danach wird angezeigt, welcher öffentliche Schlüssel übertragen wird. Da wir sonst noch keine anderen Schlüssel angelegt haben, sollte das passen.

1

/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:

1
2
3

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:

1

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:

1

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:

1

nano $HOME/.ssh/authorized_keys

Wenn 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:

1

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:

1

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.

1

ssh -v benutzername@ipadresse

oder

1

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:

1

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.