SSH Public Key Authentifizierung

Contents

Lesedauer: 8 Minuten

SSH Public Key Authentifizierung ist eine Methode, sich bei einem SSH-Server mit einem Schlüsselpaar statt mit einem Passwort anzumelden. Der private Schlüssel bleibt auf dem Client, der öffentliche Schlüssel wird auf dem Server hinterlegt; nur der passende private Schlüssel kann die Anmeldung bestätigen.

Vorteile sind eine höhere Sicherheit, da kein Passwort übertragen wird, wodurch Brute-Force-Angriffe deutlich erschwert werden. Zudem wird das Risiko eines Passwortdiebstahl erheblich reduziert. Komfortabler, weil man sich kein komplexes SSH-Passwort merken muss. Ideal für Automatisierung und passwortfreie Logins, zum Beispiel bei Skripten.

SSH-Schlüsselerzeugung

Ein SSH-Schlüsselpaar besteht stets aus einem privaten und einem öffentlichen Schlüssel. Der private Schlüssel verbleibt ausschließlich auf dem Client und dient zur Authentifizierung gegenüber dem Server; er muss vertraulich behandelt und gegen unbefugten Zugriff geschützt werden. Der öffentliche Schlüssel wird auf dem Zielsystem (Server) in der Datei ~/.ssh/authorized_keys des jeweiligen Benutzers hinterlegt und kann gefahrlos verteilt werden. Der Server prüft bei einer Anmeldung, ob der Client den Besitz eines privaten Schlüssels nachweisen kann, der zu einem der hinterlegten öffentlichen Schlüssel passt. Hierzu sendet der Server eine Challenge, die vom Client mit dem privaten Schlüssel signiert wird.

Die Erstellung und Verwaltung von SSH-Schlüsseln erfolgt grundsätzlich auf dem Client. Für eine saubere und langfristig wartbare Struktur empfiehlt es sich, von Beginn an ein konsistentes Namensschema sowie eine klare Trennung der Schlüssel nach Geräten und Einsatzzwecken zu etablieren. Beispiel: <ziel>_<user>_<client>_<inter|auto>_<algorithmus>

Für jeden Client sollte ein eigenes Schlüsselpaar erzeugt werden. Dies ermöglicht eine gezielte Sperrung einzelner Geräte im Falle eines Verlusts oder einer Kompromittierung, ohne andere Zugänge zu beeinträchtigen. Die Verwendung identischer Schlüssel auf mehreren Systemen ist technisch möglich, wird jedoch aus Sicherheitsgründen nicht empfohlen.

Private Schlüssel sollten stets mit einer Passphrase geschützt werden. Diese dient als zusätzliche Schutzschicht, falls der Schlüssel kompromittiert wird. Ohne die korrekte Passphrase kann ein Angreifer den Schlüssel nicht verwenden, selbst wenn er Zugriff auf die Datei erhält. Für automatisierte Anwendungsfälle, bei denen keine interaktive Eingabe möglich ist, sollten stattdessen separate Schlüssel ohne Passphrase eingesetzt und deren Nutzung serverseitig strikt eingeschränkt werden.

Die Schlüsselerzeugung erfolgt typischerweise mittels ssh-keygen unter Verwendung moderner Verfahren wie Ed25519. Neben dem Dateinamen des Schlüssels sollte insbesondere der Kommentar (-C) bewusst gewählt werden, da dieser Bestandteil des Public Keys ist und später auf dem Server zur Identifikation dient. Der Dateiname hingegen ist rein lokal relevant und dient der Übersicht auf dem Client.

$ ssh-keygen -t ed25519 -f ~/.ssh/testserver_pronto_macbookpro_inter_ed25519 -C "pronto@192.168.8.140 (Test-Server) from MacBookPro M1"

Nach der Ausführung von ssh-keygen wird ein Schlüsselpaar erzeugt und auf dem System gespeichert. Die Ausgabe informiert zunächst über die Speicherorte des privaten und öffentlichen Schlüssels. Anschließend wird ein Fingerprint angezeigt, der als eindeutige, verkürzte Prüfsumme des öffentlichen Schlüssels dient und zur Identifikation verwendet werden kann. Zusätzlich wird eine sogenannte Randomart-Darstellung ausgegeben, eine visuelle Repräsentation dieses Fingerprints, die insbesondere bei manuellen Vergleichen hilfreich sein kann.

$ ls -l ~/.ssh
total 88
-rw-r--r--@ 1 pronto  staff    133 29 März 12:09 config
-rw-------@ 1 pronto  staff  12145 22 März 15:16 known_hosts
-rw-------@ 1 pronto  staff    509 29 März 14:27 testserver_pronto_macbookpro_inter_ed25519
-rw-r--r--@ 1 pronto  staff    135 29 März 14:27 testserver_pronto_macbookpro_inter_ed25519.pub

Übertragung des öffentlichen Schlüssels

Nach der Erzeugung des Schlüsselpaares muss der öffentliche Schlüssel auf dem Zielsystem hinterlegt werden. Hierzu wird der Inhalt der .pub-Datei in die Datei ~/.ssh/authorized_keys des entsprechenden Benutzers auf dem Server eingefügt. Existiert das Verzeichnis oder die Datei noch nicht, müssen diese zuvor angelegt werden.

Die einfachste Methode zur Übertragung ist die Nutzung von ssh-copy-id, sofern dieses Werkzeug verfügbar ist. Dabei wird der öffentliche Schlüssel automatisch an die korrekte Stelle auf dem Server kopiert und die notwendigen Dateirechte werden gesetzt:

$ ssh-copy-id -i ~/.ssh/testserver_pronto_macbookpro_inter_ed25519.pub pronto@192.168.8.140

Nach erfolgreicher Übertragung kann die Anmeldung mit dem privaten Schlüssel erfolgen. Wurde bei der Schlüsselerzeugung eine Passphrase festgelegt, wird diese lokal auf dem Client abgefragt, um den privaten Schlüssel zu entsperren. Der Server prüft anschließend, ob ein passender öffentlicher Schlüssel hinterlegt ist und erlaubt den Zugriff ohne Passwortabfrage, sofern die Authentifizierung erfolgreich ist:

$ ssh -i ~/.ssh/testserver_pronto_macbookpro_inter_ed25519 pronto@192.168.8.140
Enter passphrase for key '/Users/pronto/.ssh/testserver_pronto_macbookpro_inter_ed25519':

Der mittels ssh-copy-id auf den Server übertragene öffentliche Schlüssel wird in der Datei ~/.ssh/authorized_keys des jeweiligen Benutzers abgelegt und kann dort eingesehen werden. Diese Datei kann mehrere öffentliche Schlüssel enthalten, beispielsweise für unterschiedliche Clients. Jeder Schlüssel wird dabei in einer eigenen Zeile gespeichert.

In diesem Zusammenhang wird die Bedeutung des bei der Schlüsselerzeugung vergebenen Kommentars deutlich: Da der SSH-Server den Kommentar technisch nicht auswertet, dient er ausschließlich der administrativen Zuordnung. Insbesondere bei mehreren hinterlegten Schlüsseln ermöglicht er eine schnelle Identifikation des Ursprungs und Einsatzzwecks eines Schlüssels:

pronto@testserver:~$ cat ~/.ssh/authorized_keys
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIDUiFMShFxKtqGggTPiOXw2ROYEI3TYx3ty9oDoHa4yJ pronto@192.168.8.140 (Test-Server) from MacBookPro M1

Wird ein öffentlicher Schlüssel aus der Datei authorized_keys entfernt, wird der zugehörige Zugang unmittelbar gesperrt, ohne dass andere Schlüssel oder Benutzerkonten beeinflusst werden.

SSH-Konfigurationsdatei

Mit zunehmender Anzahl von Zielsystemen und Schlüsseln wird die direkte Angabe von Benutzer, Host und Schlüsseldatei schnell unhandlich. Zur Vereinfachung der Nutzung und zur Vermeidung von Fehlkonfigurationen kann die SSH-Konfigurationsdatei ~/.ssh/config verwendet werden. In dieser lassen sich Verbindungsparameter zentral definieren und über frei wählbare Aliasnamen ansprechen.

Ein typischer Eintrag definiert den Zielhost, den zu verwendenden Benutzer sowie den zugehörigen privaten Schlüssel:

Host testserver
	Hostname 192.168.8.140
	User pronto
	IdentityFile ~/.ssh/testserver_pronto_macbookpro_inter_ed25519
	IdentitiesOnly yes

Die Option IdentitiesOnly yes stellt sicher, dass ausschließlich der angegebene Schlüssel verwendet wird. Ohne diese Einstellung würde der SSH-Client versuchen, zusätzlich weitere lokal verfügbare Schlüssel anzubieten, was insbesondere bei mehreren vorhandenen Identitäten zu Verzögerungen oder Authentifizierungsfehlern führen kann.

Die Verbindung kann anschließend über den definierten Alias aufgebaut werden, ohne dass weitere Parameter angegeben werden müssen:

$ ssh testserver
Enter passphrase for key '/Users/pronto/.ssh/testserver_pronto_macbookpro_inter_ed25519':

Server-Konfiguration

Damit die Anmeldung mittels SSH-Schlüsseln möglich ist, müssen auf dem Server entsprechende Einstellungen im SSH-Daemon (sshd) aktiviert sein. Die Konfigurationsdatei befindet sich üblicherweise unter /etc/ssh/sshd_config.

Zentral sind dafür die folgenden beiden Parameter relevant:

PubkeyAuthentication
AuthorizedKeysFile

$ sudo sshd -T | grep -Ei 'pubkeyauthentication|authorizedkeysfile'
pubkeyauthentication yes
authorizedkeysfile .ssh/authorized_keys .ssh/authorized_keys2

Backup

Da der Zugriff auf ein System vollständig vom Besitz des privaten Schlüssels abhängt, ist ein zuverlässiges Backup essenziell. Geht der private Schlüssel verloren, ist ein Zugriff auf bestehende Systeme nicht mehr möglich und der Schlüssel muss neu erzeugt sowie auf allen Zielsystemen erneut hinterlegt werden.

Für Backup-Zwecke ist ausschließlich der private Schlüssel relevant. Der öffentliche Schlüssel kann bei Bedarf jederzeit aus dem privaten Schlüssel rekonstruiert werden und muss daher nicht zwingend gesichert werden. Wichtig ist, dass das Backup den vollständigen Inhalt des privaten Schlüssels umfasst:

Private Schlüssel sollten ausschließlich in sicheren, verschlüsselten Speichermedien abgelegt werden, beispielsweise in einem Passwortmanager. Dabei kann der Schlüssel entweder als Datei hinterlegt oder als Text gespeichert werden. Zusätzlich sollte sichergestellt werden, dass die zum Schlüssel gehörige Passphrase ebenfalls verfügbar ist, da der Schlüssel ohne diese nicht verwendet werden kann.

Aus Sicherheitsgründen ist darauf zu achten, dass private Schlüssel niemals unverschlüsselt oder ungeschützt gespeichert oder übertragen werden. Der Zugriff auf das Backup muss streng kontrolliert werden, da ein kompromittierter privater Schlüssel einem vollständigen Systemzugriff gleichkommt.

Bei der Wiederherstellung eines privaten Schlüssels ist unbedingt auf korrekte Dateiberechtigungen zu achten, da der SSH-Client unsichere Schlüsseldateien aus Sicherheitsgründen ablehnt. Der private Schlüssel darf ausschließlich für den jeweiligen Benutzer lesbar sein und muss daher mit restriktiven Rechten versehen werden (600). Ebenso sollte das Verzeichnis ~/.ssh nur für den Benutzer zugänglich sein (700).

29. März 2026

Updated on 29. März 2026

Was this article helpful?

Yes No

About The Author

Pronto

"We are connecting more than computers..."