SSH Keys richtig verwalten und nutzen

Funktionsweise von SSH-Keys

Ein SSH-Key besteht aus einem Paar Dateien: einem Private Key, der auf Ihrem Gerät verbleibt, und einem Public Key, den Sie auf jeden Server kopieren, auf dem Sie sich anmelden möchten. Bei einer Verbindung nutzt der Server den Public Key, um eine Challenge zu senden, die nur der passende Private Key beantworten kann. Der Private Key verlässt Ihr Gerät nie. Daher werden keine Geheimnisse über das Netzwerk übertragen und ein kompromittierter Server enthält keine nützlichen Daten zum Stehlen. Aus diesem Grund sind Keys Passwörtern überlegen. Eine korrekte Verwaltung von SSH-Keys basiert auf vier Gewohnheiten: ein Key pro Gerät, die von sshd geforderten Dateiberechtigungen, eine ~/.ssh/config Datei zur Vermeidung von Optionen und das Wissen, wie man einen Key entfernt, sobald ein Laptop verloren geht.

Diese Anleitung behandelt jede Gewohnheit unter Ubuntu 24.04. Fast alle Informationen gelten jedoch für jeden Linux-Server und jede aktuelle OpenSSH-Version.

Ein Begriff vor dem Start, um Fehler zu vermeiden: Der Public Key ist nicht geheim. Sie können ihn in ein Ticket einfügen, per E-Mail senden oder veröffentlichen; niemand kann sich damit anmelden. Der Private Key ist das Geheimnis. Jeder, der diese Datei kopiert und die Passphrase (falls vorhanden) kennt, gilt für Ihre Server als Sie.

Einen Schlüssel erstellen: ed25519 ist der richtige Standard

Führen Sie auf Ihrem eigenen Computer (nicht auf dem Server) folgenden Befehl aus:

ssh-keygen -t ed25519 -C "laptop"

-t ed25519 legt den Schlüsseltyp fest. Ed25519 ist der moderne Standard: Die Schlüssel sind kurz, schnell und werden von jeder OpenSSH-Version seit 2014 unterstützt. Verwenden Sie nur dann ssh-keygen -t rsa -b 4096 als Fallback, wenn Sie mit einem alten Gerät kommunizieren müssen, das ed25519 nicht unterstützt. -C "laptop" setzt einen Kommentar. Der Kommentar hat keine kryptografische Funktion, dient aber dazu, diesen Schlüssel in zwei Jahren in der authorized_keys-Datei eines Servers wiederzuerkennen. Benennen Sie daher das Gerät, auf dem der Schlüssel liegt, als Kommentar.

ssh-keygen fragt nach dem Speicherort des Schlüssels. Akzeptieren Sie den Standardwert ~/.ssh/id_ed25519. Danach wird eine Passphrase abgefragt. Legen Sie eine Passphrase fest; der Abschnitt unten erklärt, warum dies im Alltag keinen Mehraufwand bedeutet. Sie erhalten zwei Dateien: ~/.ssh/id_ed25519 ist der private Schlüssel und ~/.ssh/id_ed25519.pub ist der öffentliche Schlüssel. Betrachten Sie die öffentliche Hälfte:

cat ~/.ssh/id_ed25519.pub

ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIF3k2s0vQx7GdKQhX1yBz... laptop

Dies ist eine einzelne Zeile: der Schlüsseltyp, das Schlüsselmaterial und Ihr Kommentar. Diese Zeile wird auf Ihren Servern gespeichert.

Ein Schlüssel pro Gerät, nicht einer pro Server

Die erste Frage ist meist: Benötige ich für jeden Server einen neuen Schlüssel? Nein. Erstellen Sie für jedes Gerät, an dem Sie tippen, einen eigenen Schlüssel. Hinterlegen Sie diesen einen öffentlichen Schlüssel auf jedem Server, den das Gerät erreichen muss. Der Schlüssel identifiziert das Gerät. Die authorized_keys-Datei auf jedem Server ist die Liste der zugelassenen Geräte.

Dieses Modell ist skalierbar, während Alternativen vorhersehbare Probleme verursachen. Ein Schlüssel pro Server bedeutet, dass ein Laptop mit zwanzig Servern zwanzig private Schlüssel speichert; man verliert schnell den Überblick. Ein einziger Schlüssel für alle Geräte ist noch problematisch: Wird der Laptop gestohlen, können Sie den Zugriff des Laptops nicht entziehen, ohne auch den Desktop auszuschließen. Da beide Geräte denselben privaten Schlüssel nutzen, müssen Sie den Schlüssel überall ersetzen und gleichzeitig auf allen Geräten neu verteilen.

Bei einem Schlüssel pro Gerät kostet ein verlorener Laptop nur eine Zeile pro Server: Löschen Sie die Zeile des Laptops aus der authorized_keys, und alle anderen Geräte funktionieren weiterhin. Der Kommentar, den Sie mit -C setzen, ermöglicht das schnelle Finden dieser Zeile.

Das Prinzip hinter diesem Modell: Ein privater Schlüssel wird auf einem Gerät erstellt und endet mit diesem Gerät. Kopieren Sie niemals einen privaten Schlüssel auf eine zweite Maschine und laden Sie niemals einen Schlüssel auf einen Server hoch. Wenn ein neues Gerät Zugriff benötigt, generieren Sie einen neuen Schlüssel direkt auf diesem Gerät.

Den Public Key auf dem Server hinterlegen

Der einfache Weg ist ssh-copy-id, welches mit OpenSSH ausgeliefert wird:

ssh-copy-id matt@10.0.0.10

Das Tool meldet sich mit der aktuell funktionierenden Methode an (meistens mit einem Passwort), fügt Ihren Public Key zu ~/.ssh/authorized_keys auf dem Server hinzu und erstellt das Verzeichnis sowie die Datei mit den korrekten Berechtigungen, falls diese fehlen. Testen Sie dies, indem Sie eine neue SSH-Sitzung öffnen: Der Server sollte den Zugriff ohne Abfrage des Kontopassworts erlauben. Falls Ihr Key eine Passphrase hat, fragt eventuell Ihr lokales System danach; diese Abfrage ist lokal und ist nicht das Passwort des Servers.

Wenn der Passwort-Login bereits deaktiviert ist, kann ssh-copy-id sich nicht anmelden, sodass Sie die Zeile manuell hinzufügen müssen. Melden Sie sich über eine noch funktionierende Sitzung oder die Web-Konsole Ihres Anbieters an und führen Sie dies auf dem Server aus:

mkdir -p ~/.ssh && chmod 700 ~/.ssh
echo "ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIF3k2s0vQx7GdKQhX1yBz... laptop" >> ~/.ssh/authorized_keys
chmod 600 ~/.ssh/authorized_keys

Fügen Sie Ihren echten Public Key innerhalb der Anführungszeichen ein, also die vollständige einzelne Zeile aus id_ed25519.pub. authorized_keys speichert einen Public Key pro Zeile; dies ist die gesamte Zugriffsdatenbank: Ein Gerät hinzuzufügen bedeutet, eine Zeile anzuhängen, und ein Gerät zu entziehen bedeutet, eine Zeile zu löschen. Auf einem neuen Server gehört dieser Schritt in die ersten 10 Minuten auf einem neuen VPS, unmittelbar bevor Sie den Passwort-Login deaktivieren.

Berechtigungen, die den Key-Login verhindern

Dies ist die häufigste Ursache für fehlgeschlagene Key-Logins. Der Fehler tritt auf Client-Seite ohne Fehlermeldung auf. Auf Ubuntu 24.04 läuft sshd standardmäßig mit StrictModes yes. Das bedeutet, dass sshd eine authorized_keys Datei ablehnt, die von anderen Benutzern bearbeitet werden kann. Wenn die Datei, das ~/.ssh Verzeichnis oder Ihr Home-Verzeichnis für andere Benutzer beschreibbar ist, ignoriert sshd Ihren Key. Der Dienst fordert dann stattdessen ein Passwort an, ohne eine Fehlermeldung am Client auszugeben. (Das OpenSSH von Ubuntu toleriert genau einen Sonderfall: eine Datei, die für die eigene private Gruppe beschreibbar ist, der kein anderer Benutzer angehört. Verlassen Sie sich nicht darauf; nutzen Sie die unten stehenden Modi.) Der Grund wird nur im Log des Servers angezeigt:

sudo grep 'Authentication refused' /var/log/auth.log

Auf einem Minimal-Image ohne rsyslog gibt es kein auth.log; die entsprechende Zeile befindet sich im Journal: sudo journalctl -u ssh | grep 'Authentication refused'.

Authentication refused: bad ownership or modes for file /home/matt/.ssh/authorized_keys

Die Lösung besteht aus zwei Änderungen der Berechtigungen und einer Überprüfung des Besitzers. Führen Sie diese Befehle auf dem Server als der betroffene Benutzer aus:

chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
chown -R matt:matt ~/.ssh

Die Faustregel lautet: 700 für das .ssh Verzeichnis und 600 für alle darin enthaltenen Dateien. Dieselben Werte gelten für Ihren eigenen Computer, da auch der Client die Berechtigungen prüft. Ein privater Key, der für andere Benutzer lesbar ist, führt dazu, dass ssh den Key direkt ablehnt. In diesem Fall wird der Fehler explizit ausgegeben:

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@         WARNING: UNPROTECTED PRIVATE KEY FILE!          @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
Permissions 0644 for '/home/matt/.ssh/id_ed25519' are too open.

chmod 600 ~/.ssh/id_ed25519 behebt das Problem.

~/.ssh/config: Optionen vermeiden

Eine ~/.ssh/config Datei auf Ihrem Computer weist jedem Server einen Kurznamen zu und speichert die Optionen, die Sie sonst manuell eingeben müssen. Erstellen Sie die Datei mit 600 Berechtigungen und fügen Sie für jeden Server einen Host Block hinzu:

Host web1
    HostName 10.0.0.10
    User matt
    IdentityFile ~/.ssh/id_ed25519
    IdentitiesOnly yes

Host db1
    HostName 10.0.0.11
    User matt
    Port 2222
    IdentityFile ~/.ssh/id_ed25519
    IdentitiesOnly yes

Nun ersetzt ssh web1 ssh -p 22 matt@10.0.0.10. Derselbe Kurzname funktioniert auch in scp, rsync und git, da alle diese Programme die Datei lesen. HostName ist die tatsächliche Adresse, User erspart die Eingabe des Benutzernamens und IdentityFile legt fest, welcher Key angeboten werden soll.

IdentitiesOnly yes ist wichtig, da es einen häufigen Fehler behebt. Wenn Ihr Agent mehrere Keys hält, bietet der Client diese nacheinander an. Der Server zählt jedes Angebot als fehlgeschlagenen Versuch. Wenn zu viele Keys geladen sind, tritt Received disconnect: Too many authentication failures auf, bevor der korrekte Key versucht wurde. IdentitiesOnly yes bewirkt, dass der Client nur den in IdentityFile definierten Key anbietet, wodurch dieser Fehler verhindert wird.

Passphrases und ssh-agent

Eine Passphrase verschlüsselt die private Key-Datei auf der Festplatte. Ohne Passphrase kann jeder, der die Datei kopiert, diese sofort verwenden. Mit einer Passphrase ist die gestohlene Datei nutzlos, bis die Passphrase erraten wird. Für einen Key auf einem Laptop bietet dies genau den Schutz, der benötigt wird, da Laptops gestohlen werden können und Backups von Laptops oft Datenlecks verursachen.

Der Grund, warum eine Passphrase in der Praxis keine Performance kostet, ist ssh-agent. Der Agent hält Ihren entschlüsselten Key im Speicher. Sie geben die Passphrase nur einmal pro Login-Session ein, und alle folgenden Verbindungen erfolgen sofort. Die meisten Desktop-Linux-Distributionen und macOS führen bereits einen Agent für Sie aus. Laden Sie Ihren Key mit folgendem Befehl in den Agent:

ssh-add ~/.ssh/id_ed25519

ssh-add -l listet die Keys auf, die der Agent aktuell hält. Ein Hinweis: Agent Forwarding (ssh -A) ermöglicht es dem Remote-Server, Ihren Agent zur weiteren Authentifizierung zu nutzen, während Sie verbunden sind. Aktivieren Sie diese Funktion daher nur gegenüber Servern, denen Sie voll vertrauen, und lassen Sie sie standardmäßig deaktiviert.

Rotation und Widerruf: Das Übungsszenario für verlorene Laptops

Das Widerrufen eines einfachen SSH-Keys bedeutet lediglich, die entsprechende Zeile aus authorized_keys auf jedem Server zu entfernen, auf dem dieser hinterlegt ist. Es gibt keine Certificate Authority, die benachrichtigt werden muss, und kein Ablaufdatum, das abgewartet werden muss. Sobald die Zeile entfernt wurde, schlagen neue Logins mit diesem Key fehl.

Führen Sie diese Übung jetzt durch, solange kein Notfall vorliegt. Wählen Sie einen Server aus, öffnen Sie ~/.ssh/authorized_keys und suchen Sie den Key anhand seines Kommentars. Löschen Sie die Zeile mit einem Editor oder filtern Sie sie über den Kommentar heraus:

grep -v ' laptop$' ~/.ssh/authorized_keys > ~/.ssh/authorized_keys.tmp
mv ~/.ssh/authorized_keys.tmp ~/.ssh/authorized_keys

Bestätigen Sie anschließend von dem Gerät, dessen Zugriff Sie gerade widerrufen haben, dass der Login fehlschlägt. Prüfen Sie von einem anderen Gerät aus, dass der Login weiterhin funktioniert. Beachten Sie ein Detail: Das Entfernen eines Keys schließt keine bereits bestehenden Sitzungen, da der Key nur beim Login geprüft wird. Wenn Sie ein gestohlenes Gerät widerrufen, prüfen Sie zusätzlich who auf dem Server und beenden Sie alle Sitzungen, die Sie nicht zuordnen können.

Rotation ist derselbe Vorgang in einer anderen Reihenfolge: Generieren Sie einen neuen Key auf dem Gerät, installieren Sie ihn mit ssh-copy-id, bestätigen Sie den Login mit dem neuen Key und löschen Sie dann die alte Zeile. Führen Sie dies durch, wenn ein Gerät den Besitzer wechselt, wenn ein Key möglicherweise kompromittiert wurde oder wenn ein Teammitglied das Team verlässt. Die manuelle Durchführung auf zwei Servern ist machbar; bei zwanzig Servern ist dies eine Aufgabe für die Automatisierung. Das Verwalten mehrerer Linux-Server zeigt, wie man denselben authorized_keys-Zustand auf eine gesamte Flotte überträgt.

Was Sie nicht tun sollten

• Verwenden Sie keinen einzelnen Private Key für alle Ihre Geräte. Wenn ein Gerät gestohlen wird, können Sie den Key nicht einzeln widerrufen, ohne ihn überall zu ersetzen.

• Committen Sie keinen Private Key in ein git repository, auch nicht in ein privates. Automatisierte Scanner überwachen öffentliche repositories und versuchen, geleakte Keys innerhalb von Minuten nach einem push zu nutzen. Wenn ein repository später öffentlich gemacht wird, wird die gesamte Historie geleakt.

• Laden Sie den Private Key Ihres Laptops nicht auf einen Server hoch, damit dieser Server auf einen anderen Server zugreifen kann. Generieren Sie einen separaten Key direkt auf dem Server und autorisieren Sie diesen Key nur dort, wo er benötigt wird.

• Kopieren Sie keinen Private Key in Chats, E-Mails oder Tickets. Der Public Key, die .pub Datei, ist der einzige Teil, der geteilt werden darf.

Sobald der Login mit Ihrem Key zuverlässig funktioniert, sollten Sie die Passwort-Authentifizierung deaktivieren. Dadurch können Brute-Force-Angriffe auf Ihren Server vollständig verhindert werden. Die passende Konfiguration hierfür finden Sie in SSH hardening on a VPS.

FAQ

Wie funktionieren SSH-Keys ohne Passwortübertragung?

Der Server speichert Ihren öffentlichen Schlüssel in ~/.ssh/authorized_keys. Beim Login sendet der Server eine Challenge. Ihr Client signiert diese Challenge mit dem privaten Schlüssel. Der Server verifiziert die Signatur mit dem öffentlichen Schlüssel. Der private Schlüssel verlässt Ihr Gerät nie. Daher kann nichts während der Übertragung abgefangen werden und es gibt keine wiederverwendbaren Daten auf dem Server zu stehlen. Ein kompromittierter Server legt nur öffentliche Schlüssel offen, mit denen keine Anmeldungen an anderen Systemen möglich sind.

Sollte ich denselben SSH-Key für alle meine Server verwenden?

Die Verwendung eines Keys für viele Server ist korrekt, sofern dieser Key auf nur einem Gerät gespeichert bleibt. Die Regel lautet: ein Key pro Gerät, nicht ein Key pro Server. Der öffentliche Schlüssel Ihres Laptops gehört auf jeden Server, auf den der Laptop zugreifen muss. Ihr Desktop benötigt einen eigenen Schlüssel. Dies vereinfacht den Widerruf (Revocation), da der Verlust eines Geräts nur das Entfernen einer identifizierbaren Zeile auf jedem Server erfordert und die anderen Geräte weiterhin funktionieren.

Welche Berechtigungen müssen das .ssh-Verzeichnis und die authorized_keys haben?

Setzen Sie 700 für ~/.ssh und 600 für authorized_keys sowie für jeden privaten Schlüssel. Der Besitzer muss das jeweilige Benutzerkonto sein. sshd läuft standardmäßig mit StrictModes yes. Wenn eine Datei oder ein Home-Verzeichnis für andere Benutzer beschreibbar ist, ignoriert sshd Ihren Schlüssel stillschweigend. Die einzige Spur ist Authentication refused: bad ownership or modes im auth-Log oder Journal des Servers.

Wie entferne ich einen SSH-Key von einem Server?

Löschen Sie die entsprechende Zeile aus ~/.ssh/authorized_keys des autorisierten Benutzerkontos. Identifizieren Sie die richtige Zeile anhand des Kommentars nach dem Schlüsselmaterial. Neue Anmeldungen mit diesem Key schlagen sofort fehl. Bereits offene Sitzungen bleiben jedoch bestehen. Beenden Sie daher auch alle aktiven Sitzungen dieses Geräts, falls es gestohlen wurde. Wiederholen Sie diesen Vorgang auf jedem Server, auf dem der Key kopiert wurde.

Benötige ich eine Passphrase für meinen SSH-Key?

Für einen Key auf einem Laptop oder Desktop: ja. Die Passphrase verschlüsselt die Key-Datei. Eine gestohlene oder geleakte Kopie ist allein dadurch nutzlos. ssh-agent bedeutet, dass Sie die Passphrase nur einmal pro Sitzung eingeben müssen und nicht bei jeder Verbindung. Keys, die für unbeaufsichtigte Automatisierung auf einem Server verwendet werden, haben meist keine Passphrase, da keine Person zur Eingabe anwesend ist. Schützen Sie diese Keys, indem Sie die Berechtigungen des Zielkontos einschränken.