SSH-Schlüssel verwalten: Grundlagen für Linux

Funktionsweise von SSH-Schlüsseln

Ein SSH-Schlüssel besteht aus zwei Dateien: einem privaten Schlüssel, der auf Ihrem Gerät bleibt, und einem öffentlichen Schlüssel, den Sie auf jeden Server kopieren, bei dem Sie sich anmelden möchten. Beim Verbindungsaufbau verwendet der Server den öffentlichen Schlüssel, um eine Anfrage zu senden, die nur der zugehörige private Schlüssel beantworten kann. Der private Schlüssel verlässt Ihr Gerät nie. Dadurch wird kein Geheimnis über das Netzwerk übertragen, und ein kompromittierter Server kann nichts Verwertbares stehlen. Deshalb sind Schlüssel sicherer als Passwörter. Eine gute Verwaltung von SSH-Schlüsseln basiert auf vier Gewohnheiten: ein Schlüssel pro Gerät, die von sshd geforderten Dateiberechtigungen, eine ~/.ssh/config-Datei, damit Sie Optionen nicht ständig eingeben müssen, und das Wissen, wie Sie einen Schlüssel an dem Tag entfernen, an dem ein Laptop verloren geht.

Dieser Leitfaden behandelt jede dieser Gewohnheiten unter Ubuntu 24.04. Fast alle Informationen gelten jedoch auch für jeden Linux-Server und jede aktuelle OpenSSH-Version.

Bevor wir beginnen, sollten wir einen Begriff klären, da dadurch echte Fehler vermieden werden. Der öffentliche Schlüssel ist nicht geheim. Sie können ihn in ein Ticket einfügen, per E-Mail versenden oder veröffentlichen. Niemand kann sich damit anmelden. Der private Schlüssel ist geheim. Wer diese Datei kopiert und gegebenenfalls ihre Passphrase kennt, kann sich gegenüber Ihren Servern wie Sie ausgeben.

Schlüssel erstellen: ed25519 ist die richtige Standardwahl

Führen Sie den Befehl auf Ihrem eigenen Computer aus, nicht auf dem Server:

ssh-keygen -t ed25519 -C "laptop"

-t ed25519 legt den Schlüsseltyp fest. Ed25519 ist die moderne Standardwahl: Die Schlüssel sind kurz, schnell und werden von jeder OpenSSH-Version seit 2014 unterstützt. Verwenden Sie ssh-keygen -t rsa -b 4096 nur, wenn Sie mit einem alten Gerät kommunizieren müssen, das ed25519 nicht versteht. -C "laptop" setzt einen Kommentar. Der Kommentar hat keine kryptografische Funktion. Er hilft Ihnen jedoch, diesen Schlüssel in zwei Jahren in der authorized_keys-Datei eines Servers zu erkennen. Geben Sie daher das Gerät an, auf dem der Schlüssel gespeichert ist.

ssh-keygen fragt nach dem Speicherort des Schlüssels. Übernehmen Sie den Standardwert ~/.ssh/id_ed25519. Anschließend werden Sie nach einer Passphrase gefragt. Legen Sie eine fest. Im folgenden Abschnitt zur Passphrase wird erklärt, warum sie im täglichen Betrieb keinen zusätzlichen Aufwand verursacht. Sie erhalten zwei Dateien: ~/.ssh/id_ed25519 ist der private Schlüssel und ~/.ssh/id_ed25519.pub der öffentliche Schlüssel. Sehen Sie sich den öffentlichen Teil an:

cat ~/.ssh/id_ed25519.pub

ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIF3k2s0vQx7GdKQhX1yBz... laptop

Er besteht aus einer Zeile: dem Schlüsseltyp, dem Schlüsselmaterial und Ihrem Kommentar. Diese Zeile wird auf Ihren Servern gespeichert.

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

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

Dieses Modell lässt sich skalieren. Die Alternativen führen auf vorhersehbare Weise zu Problemen. Bei einem Schlüssel pro Server enthält ein Laptop mit zwanzig Servern zwanzig private Schlüssel. Sie verlieren den Überblick, welcher Schlüssel zu welchem Server gehört. Noch problematischer ist ein Schlüssel, den Sie für alle Geräte gemeinsam verwenden: Wird der Laptop gestohlen, können Sie den Laptop nicht sperren, ohne gleichzeitig den Desktop zu sperren, weil beide denselben privaten Schlüssel verwenden. Sie müssen den Schlüssel daher überall ersetzen und gleichzeitig auf jedes Gerät verteilen.

Bei einem Schlüssel pro Gerät kostet Sie ein verlorener Laptop eine Zeile pro Server: Löschen Sie die Zeile des Laptops aus authorized_keys. Alle anderen Geräte funktionieren weiter. Der mit -C gesetzte Kommentar erleichtert das Auffinden dieser Zeile.

Die Grundregel dieses Modells lautet: Ein privater Schlüssel wird auf einem Gerät erstellt und ist an dieses Gerät gebunden. Kopieren Sie einen privaten Schlüssel niemals auf ein zweites Gerät und laden Sie ihn niemals auf einen Server hoch. Wenn ein neues Gerät Zugriff benötigt, generieren Sie darauf einen neuen Schlüssel.

Den öffentlichen Schlüssel auf dem Server hinterlegen

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

ssh-copy-id matt@10.0.0.10

Der Befehl meldet Sie mit der noch funktionierenden Authentifizierung an, in der Regel mit einem Passwort, hängt Ihren öffentlichen Schlüssel an ~/.ssh/authorized_keys auf dem Server an und erstellt das Verzeichnis sowie die Datei mit den korrekten Berechtigungen, falls sie fehlen. Testen Sie die Einrichtung, indem Sie eine neue SSH-Sitzung öffnen: Der Server sollte Sie ohne Abfrage des Kontopassworts anmelden. Wenn Ihr Schlüssel mit einer Passphrase geschützt ist, fragt Ihr eigener Rechner möglicherweise stattdessen danach. Diese Abfrage erfolgt lokal und betrifft nicht das Serverpasswort.

Wenn die Passwortanmeldung bereits deaktiviert ist, kann ssh-copy-id keine Verbindung herstellen. Dann fügen Sie die Zeile manuell hinzu. Melden Sie sich über eine noch funktionierende Sitzung oder die Webkonsole Ihres Providers an und führen Sie diesen Befehl 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 tatsächlichen öffentlichen Schlüssel innerhalb der Anführungszeichen ein. Verwenden Sie die vollständige einzelne Zeile aus id_ed25519.pub. authorized_keys enthält einen öffentlichen Schlüssel pro Zeile und ist die gesamte Zugriffsverwaltung: Ein Gerät wird hinzugefügt, indem eine Zeile angehängt wird. Der Zugriff eines Geräts wird entzogen, indem eine Zeile gelöscht wird. Auf einem neuen Server gehört dieser Schritt in die ersten 10 Minuten auf einem neuen VPS, direkt bevor Sie die Passwortanmeldung deaktivieren.

Berechtigungen, die die Anmeldung mit Schlüssel verhindern

Dies ist die häufigste Ursache dafür, dass die Anmeldung mit einem Schlüssel fehlschlägt. Auf der Client-Seite bleibt der Fehler dabei unbemerkt. sshd läuft unter Ubuntu 24.04 standardmäßig mit StrictModes yes. Daher verweigert es die Verwendung einer authorized_keys-Datei, die andere Benutzer bearbeiten könnten. Wenn die Datei, das ~/.ssh-Verzeichnis oder Ihr Home-Verzeichnis von einem anderen Benutzer als Ihnen beschrieben werden kann, ignoriert sshd Ihren Schlüssel und fordert stattdessen ein Passwort an. Auf dem Client wird keine Erklärung angezeigt. (Ubuntus OpenSSH toleriert genau einen eng begrenzten Sonderfall: Eine Datei darf für die private Gruppe des eigenen Benutzers gruppenschreibbar sein, sofern kein anderer Benutzer dieser Gruppe angehört. Verlassen Sie sich nicht darauf. Verwenden Sie die folgenden Berechtigungen.) Der Grund ist nur im Server-Log zu sehen:

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

Auf einem Minimal-Image ohne rsyslog gibt es kein auth.log. Dieselbe Zeile steht dann im Journal: sudo journalctl -u ssh | grep 'Authentication refused'.

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

Die Korrektur besteht aus zwei Änderungen an den Berechtigungen und einer Prüfung des Eigentümers. Führen Sie sie auf dem Server als betroffener Benutzer aus:

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

Die wichtige Regel lautet: 700 für das .ssh-Verzeichnis und 600 für alles darin. Dieselben Werte gelten auf Ihrem eigenen Computer, weil auch der Client die Berechtigungen prüft. Wenn andere Benutzer einen privaten Schlüssel lesen können, verweigert ssh die Verwendung des Schlüssels vollständig. In diesem Fall wird der Fehler deutlich angezeigt:

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@         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 nicht mehr eintippen

Eine Datei ~/.ssh/config auf Ihrem eigenen Computer weist jedem Server einen kurzen Namen zu und speichert die Optionen, die Sie sonst wiederholt eingeben müssten. Erstellen Sie sie mit den Berechtigungen 600 und fügen Sie pro 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

Damit ersetzt ssh web1 jetzt ssh -p 22 matt@10.0.0.10. Derselbe kurze Name funktioniert außerdem in scp, rsync und git, weil diese Programme alle diese Datei einlesen. HostName enthält die tatsächliche Adresse, User erspart Ihnen die Eingabe des Kontonamens, und IdentityFile legt fest, welcher Schlüssel angeboten wird.

IdentitiesOnly yes verdient eine eigene Erklärung, weil diese Option einen verwirrenden Fehler behebt. Wenn Ihr Agent mehrere Schlüssel enthält, bietet der Client sie nacheinander an. Der Server zählt jedes Angebot als fehlgeschlagenen Anmeldeversuch. Wenn genügend Schlüssel geladen sind, erhalten Sie Received disconnect: Too many authentication failures, bevor der richtige Schlüssel überhaupt ausprobiert wird. IdentitiesOnly yes veranlasst den Client, ausschließlich den in IdentityFile genannten Schlüssel anzubieten. Dadurch kann dieser Fehler nicht auftreten.

Passphrasen und ssh-agent

Eine Passphrase verschlüsselt die private Schlüsseldatei auf dem Datenträger. Ohne Passphrase kann jeder, der die Datei kopiert, sie sofort verwenden. Mit Passphrase ist die gestohlene Datei unbrauchbar, bis die Passphrase erraten wurde. Für einen Schlüssel auf einem Laptop ist das genau der gewünschte Schutz, weil Laptops gestohlen werden und Sicherungskopien von Laptops in falsche Hände geraten können.

Eine Passphrase verursacht in der Praxis keinen zusätzlichen Aufwand, weil ssh-agent. Der Agent hält Ihren entschlüsselten Schlüssel im Arbeitsspeicher. Dadurch geben Sie die Passphrase einmal pro Anmeldesitzung ein, und jede spätere Verbindung wird sofort hergestellt. Die meisten Linux-Distributionen für Desktop-Systeme und macOS führen bereits einen Agenten für Sie aus. Laden Sie Ihren Schlüssel mit folgendem Befehl in den Agenten:

ssh-add ~/.ssh/id_ed25519

ssh-add -l listet die Schlüssel auf, die der Agent aktuell hält. Beachten Sie: Die Agent-Weiterleitung (ssh -A) ermöglicht es dem Remote-Server, Ihren Agenten während Ihrer Verbindung für die Authentifizierung zu einem weiteren Server zu verwenden. Aktivieren Sie sie daher nur für Server, denen Sie vollständig vertrauen, und lassen Sie sie standardmäßig deaktiviert.

Schlüssel rotation und Widerruf: der Ablauf bei einem verlorenen Laptop

Das Widerrufen eines einfachen SSH-Schlüssels besteht lediglich darin, seine Zeile aus authorized_keys auf jedem Server zu entfernen, auf dem der Schlüssel hinterlegt ist. Es gibt keine Zertifizierungsstelle, die benachrichtigt werden muss, und kein Ablaufdatum, auf das Sie warten müssen. Sobald die Zeile entfernt ist, schlagen neue Anmeldungen mit diesem Schlüssel fehl.

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

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

Bestätigen Sie anschließend auf dem gerade widerrufenen Gerät, dass die Anmeldung jetzt fehlschlägt, und auf einem anderen Gerät, dass die Anmeldung weiterhin funktioniert. Beachten Sie ein Detail: Durch das Entfernen eines Schlüssels werden bereits geöffnete Sitzungen nicht beendet, weil der Schlüssel nur bei der Anmeldung geprüft wird. Wenn Sie den Schlüssel eines gestohlenen Geräts widerrufen, prüfen Sie auf dem Server außerdem who und beenden Sie jede Sitzung, die Sie nicht erkennen.

Bei der Rotation führen Sie dieselben Schritte in einer anderen Reihenfolge aus: Erzeugen Sie auf dem Gerät einen neuen Schlüssel, installieren Sie ihn mit ssh-copy-id, bestätigen Sie, dass die Anmeldung mit dem neuen Schlüssel funktioniert, und löschen Sie anschließend die alte Zeile. Führen Sie dies durch, wenn ein Gerät den Besitzer wechselt, ein Schlüssel möglicherweise offengelegt wurde oder jemand ein Team verlässt. Zwei Server können Sie problemlos manuell bearbeiten. Bei zwanzig Servern ist Automatisierung sinnvoll. Mehrere Linux-Server verwalten zeigt, wie Sie denselben authorized_keys-Zustand auf eine gesamte Serverflotte übertragen.

Was Sie vermeiden sollten

• Verwenden Sie nicht denselben privaten Schlüssel auf allen Ihren Geräten. Dadurch können Sie ein einzelnes gestohlenes Gerät nicht sperren, ohne den Schlüssel überall zu ersetzen.

• Speichern Sie keinen privaten Schlüssel in einem git-Repository, auch nicht in einem privaten. Automatisierte Scanner überwachen öffentliche Repositorys und versuchen, innerhalb weniger Minuten nach einem Push mit durchgesickerten Schlüsseln eine Anmeldung durchzuführen. Wird ein Repository später öffentlich, wird seine gesamte Historie offengelegt.

• Laden Sie den privaten Schlüssel Ihres Laptops nicht auf einen Server hoch, damit dieser Server einen anderen Server erreichen kann. Erzeugen Sie stattdessen einen separaten Schlüssel direkt auf dem Server und autorisieren Sie diesen Schlüssel genau an der benötigten Stelle.

• Fügen Sie keinen privaten Schlüssel in einen Chat, eine E-Mail oder ein Ticket ein. Der öffentliche Schlüssel, die Datei .pub, ist der einzige Teil, der weitergegeben wird.

Sobald Sie sich mit Ihrem Schlüssel zuverlässig anmelden können, deaktivieren Sie als Nächstes die Kennwortauthentifizierung. Dadurch können die ständigen Anmeldeversuche gegen Ihren Server nicht mehr erfolgreich sein. Die Drop-in-Konfiguration dafür finden Sie unter SSH-Härtung auf einem VPS.

FAQ

Wie funktionieren SSH-Schlüssel, ohne ein Passwort zu übertragen?

Der Server speichert Ihren öffentlichen Schlüssel in ~/.ssh/authorized_keys. Bei der Anmeldung sendet er eine Challenge. Ihr Client signiert die Challenge mit dem privaten Schlüssel. Der Server überprüft die Signatur mit dem öffentlichen Schlüssel. Der private Schlüssel verlässt Ihr Gerät nie. Es gibt daher nichts, was während der Übertragung abgefangen werden kann, und auf dem Server lässt sich nichts Verwendbares stehlen. Ein kompromittierter Server gibt nur öffentliche Schlüssel preis. Diese können nicht für eine Anmeldung an einem beliebigen Server verwendet werden.

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

Sie können einen Schlüssel auf vielen Servern verwenden, solange dieser Schlüssel auf einem einzigen Gerät verbleibt. Die Regel lautet: ein Schlüssel pro Gerät, nicht ein Schlüssel pro Server. Der öffentliche Schlüssel Ihres Laptops wird auf jedem Server hinterlegt, den der Laptop benötigt. Ihr Desktop verwendet einen eigenen Schlüssel. Dadurch bleibt der Widerruf einfach. Wenn ein Gerät verloren geht, entfernen Sie auf jedem Server eine eindeutig erkennbare Zeile. Die anderen Geräte funktionieren weiterhin.

Welche Berechtigungen sollten das Verzeichnis .ssh und authorized_keys haben?

Setzen Sie 700 für ~/.ssh sowie 600 für authorized_keys und für jeden privaten Schlüssel. Alle diese Dateien und Verzeichnisse müssen dem Konto gehören, das sie verwendet. sshd läuft standardmäßig mit StrictModes yes. Wenn eine andere Person als Sie in die Datei oder das Home-Verzeichnis schreiben kann, ignoriert sshd Ihren Schlüssel stillschweigend. Der einzige Hinweis ist Authentication refused: bad ownership or modes im Authentifizierungslog oder Journal des Servers.

Wie entferne ich einen SSH-Schlüssel von einem Server?

Löschen Sie die Zeile des Schlüssels aus ~/.ssh/authorized_keys im Konto, für das der Schlüssel autorisiert wurde. Ermitteln Sie die richtige Zeile anhand ihres Kommentars, also der Bezeichnung nach dem Schlüsselmaterial. Neue Anmeldungen mit diesem Schlüssel schlagen sofort fehl. Bereits geöffnete Sitzungen bleiben jedoch bestehen. Beenden Sie daher auch jede aktive Sitzung dieses Geräts, wenn das Gerät gestohlen wurde. Wiederholen Sie den Vorgang auf jedem Server, auf den der Schlüssel kopiert wurde.

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

Für einen Schlüssel auf einem Laptop oder Desktop: ja. Die Passphrase verschlüsselt die Schlüsseldatei. Eine gestohlene oder offengelegte Kopie ist dadurch allein nicht verwendbar. ssh-agent sorgt dafür, dass Sie die Passphrase einmal pro Sitzung statt bei jeder Verbindung eingeben. Schlüssel für unbeaufsichtigte Automatisierung auf einem Server haben normalerweise keine Passphrase, weil niemand anwesend ist, um sie einzugeben. Schützen Sie diese Schlüssel, indem Sie die Aktionen des Zielkontos einschränken.