SSH-Schlüssel statt Passwort: sauber einrichten

Ein Server, der SSH-Passwörter aus dem Internet annimmt, ist eine Haustür, an der jeder rütteln darf, so oft er will. Ein Schlüsselpaar tauscht diese Tür gegen ein Schloss, in das nur dein Schlüssel passt. Der einzige Haken: Verlieren darfst du ihn nicht.

Kurzantwort

Wie kannst du einen SSH-Schlüssel erstellen und dich damit ohne Passwort anmelden, egal ob unter Windows, macOS oder Linux? Mit ssh-keygen -t ed25519, geschützt durch eine Passphrase [1][2][3]. Auf den Server kommt nur die öffentliche Hälfte, die .pub-Datei, und zwar in ~/.ssh/authorized_keys, zum Beispiel mit ssh-copy-id [4][9]. Teste die Anmeldung mit dem Schlüssel in einem zweiten Fenster. Erst wenn sie klappt, setzt du PasswordAuthentication no und KbdInteractiveAuthentication no, prüfst die Konfiguration mit sshd -t und startest den SSH-Dienst neu [4][5][14]. Danach sicherst du den Schlüssel oder, besser, hinterlegst einen zweiten. Alle Befehle folgen den OpenSSH-Handbüchern, Microsoft Learn, GitHub Docs und der Ubuntu-Server-Dokumentation, Stand 25. Okt. 2026. Auf einem echten Server haben wir sie für diesen Guide nicht ausgeführt.

So funktioniert’s

1. Zwei Hälften eines Schlüssels. ssh-keygen erzeugt einen privaten Schlüssel, etwa ~/.ssh/id_ed25519, und einen öffentlichen mit demselben Namen plus .pub. Die private Datei sollte niemand außer dir lesen können; die öffentliche muss nicht geheim bleiben [3]. Der Server führt die öffentlichen Schlüssel, die er akzeptiert, in ~/.ssh/authorized_keys, einen pro Zeile [4]. Das ssh-Handbuch fasst es so zusammen: Der Server kennt den öffentlichen Schlüssel, und nur du kennst den privaten [6]. Die Idee dahinter erklärt unser Lexikoneintrag zum Public-Key-Verfahren.
2. Warum Ed25519. Laut OpenSSH-Handbuch ist Ed25519 der Standardtyp von ssh-keygen [3]. Auch Microsofts OpenSSH für Windows nimmt Ed25519, wenn du keinen Algorithmus angibst [1]. GitHubs Anleitung setzt ebenfalls darauf und weicht nur bei älteren Systemen ohne Ed25519-Unterstützung auf RSA mit 4.096 Bit aus [2]. Ubuntus Server-Dokumentation zieht Ed25519 dem RSA-Verfahren vor, weil die Schlüssel kürzer sind und weniger Rechenleistung brauchen [14].
3. Die Passphrase. Sie verschlüsselt den privaten Teil der Schlüsseldatei; laut Handbuch nutzt ssh-keygen dafür standardmäßig das Verfahren aes256-ctr [3]. Ohne Passphrase kann sich jeder als du anmelden, der die Datei kopiert. Microsoft rät von einer leeren Passphrase ab, GitHub empfiehlt eine [1][2]. Mit ssh-keygen -p änderst du sie später. Die Option -a erhöht die Zahl der Runden bei der Schlüsselableitung (Standard 16) und bremst damit Rateversuche an einer gestohlenen Datei [3].
4. Der Agent. Damit du die Passphrase nicht bei jeder Verbindung tippst, hält ssh-agent den entsperrten Schlüssel im Speicher, und ssh-add übergibt ihn. ssh-add -l listet die geladenen Schlüssel, -t setzt eine Lebensdauer, und -D entfernt alle Schlüssel aus dem Agenten [8].
5. Der Fingerabdruck des Servers. Bei der ersten Verbindung zeigt ssh den Fingerabdruck des Hostschlüssels und speichert den Schlüssel danach in ~/.ssh/known_hosts. Ändert er sich später, warnt ssh und schaltet die Passwort-Anmeldung ab, damit ein gefälschter Server dein Passwort nicht abgreift [6]. Vergleich den Fingerabdruck mit einem, den du auf anderem Weg bekommst, etwa indem du über die Web-Konsole deines Anbieters auf dem Server ssh-keygen -l -f /etc/ssh/ssh_host_ed25519_key.pub ausführst [3][4][6].
6. Was der Server prüft. sshd ignoriert authorized_keys, wenn die Datei, der Ordner ~/.ssh oder dein Home-Verzeichnis für andere Benutzer beschreibbar ist. Das Handbuch empfiehlt für ~/.ssh Lesen, Schreiben und Ausführen nur für dich und für authorized_keys Lesen und Schreiben nur für dich [4]. Diese Prüfung steuert die Option StrictModes [5].

Schritt 1: Schlüssel erzeugen

Der Befehl ist in der PowerShell unter Windows, im Terminal unter macOS und in einer Linux-Shell derselbe:

ssh-keygen -t ed25519 -C "laptop-2026"

Mit Enter übernimmst du den vorgeschlagenen Speicherort, dann tippst du zweimal eine Passphrase [2]. Gibt es schon einen Schlüssel mit diesem Namen, empfiehlt GitHub einen eigenen Dateinamen, statt den alten zu überschreiben [2]. Die Option -C setzt einen Kommentar [3]. In GitHubs Beispiel steht dort eine E-Mail-Adresse [2]; wir nehmen lieber den Gerätenamen, damit du später in authorized_keys siehst, welche Zeile zu welchem Gerät gehört. ssh-keygen -l -f ~/.ssh/id_ed25519.pub zeigt den Fingerabdruck deines Schlüssels [3].

Unter Windows brauchst du den OpenSSH-Client. Laut Microsoft enthalten die aktuellen Builds von Windows 10 und Windows 11 einen eingebauten SSH-Client [11]. Fehlt ssh-keygen, suchst du im Startmenü nach „Optionale Features“, wählst „Feature hinzufügen“, suchst „OpenSSH-Client“ und installierst ihn. Als Mindestversion nennt Microsoft Windows 10 Build 1809 [10]. Die Schlüssel landen in C:\Users\<name>\.ssh\ [1].

Hardware-Sicherheitsschlüssel sind eine Option, kein Muss. Mit einem eingesteckten Sicherheitsschlüssel (das Handbuch nennt ihn FIDO-Authenticator) erzeugt ssh-keygen -t ed25519-sk einen Schlüssel, dessen privater Teil auf dem Gerät bleibt. Die Datei auf deiner Platte enthält nur einen Verweis, den key handle, und das Gerät muss bei jeder Anmeldung angeschlossen sein und meist berührt werden [2][3]. Meldet es „invalid format“ oder „feature not supported“, empfiehlt GitHub stattdessen -t ecdsa-sk [2]. Zwei Optionen lohnen sich: -O resident speichert den Verweis auf dem Gerät selbst, und -O verify-required verlangt bei jeder Signatur eine Nutzerprüfung [3]. Welche Versionen des Windows-Clients und deines Servers diese Schlüsseltypen unterstützen, haben wir nicht geprüft; teste das, bevor du dich darauf verlässt. Die FIDO2-Anmeldung erklärt unser Lexikoneintrag zu Passkeys.

Schritt 2: Schlüssel in den Agenten laden

Windows. Der Dienst ssh-agent ist ab Werk deaktiviert. Führe diese zwei Zeilen in der PowerShell als Administrator aus [1]:

Get-Service ssh-agent | Set-Service -StartupType Automatic
Start-Service ssh-agent

Danach fügst du den Schlüssel in einem normalen PowerShell-Fenster mit ssh-add $env:USERPROFILE\.ssh\id_ed25519 hinzu [1][2]. GitHubs Anleitung stellt den Starttyp auf „Manual“ statt „Automatic“ [2]. Microsoft empfiehlt außerdem, den privaten Schlüssel an einem sicheren Ort zu sichern; mehr dazu in Schritt 6 [1].

macOS. Starte den Agenten mit eval "$(ssh-agent -s)". In ~/.ssh/config legst du einen Host-Block an, in GitHubs Beispiel für github.com, mit den Zeilen AddKeysToAgent yes, UseKeychain yes und IdentityFile ~/.ssh/id_ed25519. Dann führst du ssh-add --apple-use-keychain ~/.ssh/id_ed25519 aus, und die Passphrase liegt im macOS-Schlüsselbund [2].

Linux. Starte den Agenten mit eval "$(ssh-agent -s)" und füge den Schlüssel mit ssh-add ~/.ssh/id_ed25519 hinzu [2].

Schritt 3: öffentlichen Schlüssel auf den Server bringen

Mit ssh-copy-id. Unter Linux und überall, wo das Werkzeug installiert ist, reicht ein Befehl:

ssh-copy-id -i ~/.ssh/id_ed25519.pub alex@server.example.com

ssh-copy-id meldet sich einmal mit deinem Passwort an, hängt den Schlüssel an ~/.ssh/authorized_keys auf dem Server an und legt Datei und Ordner bei Bedarf an. Vorher prüft es, ob der Schlüssel schon eingetragen ist, und überspringt ihn dann. -n zeigt nur, was passieren würde, -p setzt einen anderen Port [9]. Ubuntus Dokumentation nutzt dasselbe Werkzeug [14].

Von Hand, zum Beispiel von Windows aus. Kopier den öffentlichen Schlüssel in der PowerShell mit cat ~/.ssh/id_ed25519.pub | clip in die Zwischenablage [12]. Melde dich mit deinem Passwort am Server an und füge den Schlüssel mit einem Editor als neue Zeile in ~/.ssh/authorized_keys ein: ein Schlüssel pro Zeile, ohne Zeilenumbruch mitten im Schlüssel [4][12]. Gibt es den Ordner ~/.ssh noch nicht, legst du ihn an und gibst nur dir selbst Zugriff, wie oben beschrieben [4]. Danach stellst du sicher, dass nur du in die Datei schreiben kannst. Ubuntus Dokumentation nutzt dafür chmod go-w .ssh/authorized_keys, ausgeführt in deinem Home-Verzeichnis [14].

Im Anbieter-Panel. Lässt dich dein VPS-Anbieter beim Anlegen eines Servers einen SSH-Schlüssel eintragen, fügst du dort den Inhalt der .pub-Datei ein.

Bei GitHub. Öffne die Einstellungen, dann „SSH and GPG keys“, wähle „New SSH key“, als Typ „Authentication Key“, füge den öffentlichen Schlüssel ein und bestätige mit „Add SSH key“ [12]. Danach führst du ssh -T git@github.com aus, vergleichst den Fingerabdruck mit den Werten, die GitHub veröffentlicht, und erwartest die Meldung „Hi USERNAME! You've successfully authenticated, but GitHub does not provide shell access.“ [13]

Auf einem Windows-Server. Für normale Benutzer gehört der Schlüssel in C:\Users\username\.ssh\authorized_keys. Für Mitglieder der Gruppe Administratoren gehört er stattdessen in C:\ProgramData\ssh\administrators_authorized_keys, und auf diese Datei dürfen nur Administratoren und SYSTEM zugreifen. Die genauen Befehle samt Zugriffsrechten zeigt Microsoft Learn [1].

Schritt 4: testen, bevor du die Tür abschließt

Lass deine aktuelle Sitzung offen. Verbinde dich in einem zweiten Fenster so, dass der Client keine Passwörter versucht [6][7]:

ssh -o PasswordAuthentication=no -o KbdInteractiveAuthentication=no alex@server.example.com

Kommst du rein und wirst höchstens nach der Passphrase deines Schlüssels gefragt, funktioniert der Schlüssel. Wenn nicht, zeigt ssh -v jeden Schritt der Verbindung [6], und unter Ubuntu zeigt sudo journalctl -fu ssh.service die Sicht des Servers [14]. Die üblichen Verdächtigen sind zu offene Dateirechte [4], ein Schlüssel mit Zeilenumbruch [12] und auf Windows-Servern die eigene Datei für Administratoren [1].

Schritt 5: Passwort-Anmeldung abschalten

Unter Ubuntu haben Konfigurationsschnipsel in /etc/ssh/sshd_config.d/ Vorrang vor der Hauptdatei, weil OpenSSH bei den meisten Optionen den ersten gelesenen Wert nimmt [14]. Das Handbuch ergänzt, dass eingebundene Dateien in lexikalischer Reihenfolge gelesen werden [5]. Eine Datei, deren Name früh einsortiert wird, gewinnt also, zum Beispiel /etc/ssh/sshd_config.d/00-keys-only.conf mit diesen zwei Zeilen:

PasswordAuthentication no
KbdInteractiveAuthentication no

Du brauchst beide: Bei aktivem PAM rät das Handbuch, entweder PasswordAuthentication oder KbdInteractiveAuthentication abzuschalten, und beide abzuschalten deckt beide Wege ab [5]. Root darf sich ab Werk ohnehin nicht mit Passwort anmelden, weil PermitRootLogin standardmäßig auf prohibit-password steht [5]; prüf den Wert trotzdem in der Ausgabe von sshd -T. Unser Docker-VPS-Guide geht einen Schritt weiter und setzt ihn auf no. Jetzt prüfst du und wendest die Änderung an:

sudo sshd -t
sudo sshd -T | grep -iE "passwordauthentication|kbdinteractiveauthentication|permitrootlogin"
sudo systemctl restart ssh.service

sshd -t prüft nur Konfiguration und Schlüssel; sshd -T gibt zusätzlich die Konfiguration aus, die tatsächlich gilt [4]. Bei beiden Passwort-Werten muss no stehen. Der Neustart-Befehl stammt aus Ubuntus Dokumentation; auf anderen Distributionen folgst du deren Doku [14]. Lass die alte Sitzung offen. Dann testest du aus einem dritten Fenster: ssh -o PubkeyAuthentication=no alex@server.example.com muss jetzt abgewiesen werden, und die Schlüssel-Anmeldung aus Schritt 4 muss weiter klappen [7].

Schritt 6: Schlüssel sichern und den Verlust einplanen

Microsoft sagt es deutlich: Ein privater Schlüssel entspricht einem Passwort und braucht denselben Schutz. Geht er verloren, musst du ein neues Schlüsselpaar erzeugen und den öffentlichen Schlüssel auf jedem System austauschen, das du nutzt [1]. Microsoft empfiehlt, den privaten Schlüssel an einem sicheren Ort zu sichern [1]. Unsere Einschätzung: Robuster ist ein zweiter Schlüssel. Erzeuge ihn auf einem zweiten Gerät oder auf einem Hardware-Sicherheitsschlüssel und trag beide öffentlichen Schlüssel in authorized_keys und bei GitHub ein. Dann ist ein verlorener Laptop ärgerlich, aber du sperrst dich nicht aus. Kommt ein Gerät abhanden, löschst du seine Zeile in authorized_keys und seinen Eintrag bei GitHub. Bewahre jede Kopie eines privaten Schlüssels verschlüsselt auf, etwa in deinem Passwortmanager, und füge in Formulare immer nur die .pub-Datei ein [12].

Praxisbeispiel (Namen sind Platzhalter)

Der Aufbau ist erfunden und zeigt einen Plan, keinen Test. Alex hat einen Laptop mit Windows 11 und einen Linux-Desktop und mietet einen VPS, der unter server.example.com erreichbar ist.

• Beide Geräte bekommen mit ssh-keygen -t ed25519 einen eigenen Schlüssel, mit den Kommentaren laptop-2026 und desktop-2026 und zwei verschiedenen Passphrasen [3].
• Auf dem Laptop startet der Dienst ssh-agent automatisch und hält den Schlüssel [1].
• Vom Desktop aus trägt ssh-copy-id den ersten Schlüssel ein [9]. Der Schlüssel des Laptops kommt per Zwischenablage und Editor als zweite Zeile dazu [12]. authorized_keys hat jetzt genau zwei Zeilen, eine pro Gerät [4].
• Beide Geräte melden sich mit dem Testbefehl aus Schritt 4 an.
• Auf dem Server kommt der Schnipsel aus Schritt 5 dazu, sshd -t läuft ohne Fehler durch, und sshd -T zeigt bei beiden Passwort-Werten no; dann startet der Dienst neu. Eine Passwort-Anmeldung aus einem dritten Fenster wird abgewiesen.
• Bei GitHub stehen beide öffentlichen Schlüssel als Authentifizierungsschlüssel, und ssh -T git@github.com begrüßt Alex mit Namen [12][13].

Prüfliste

• Schau in deinem Ordner .ssh nach vorhandenen Schlüsseln, bevor du einen neuen erzeugst, damit du keinen überschreibst.
• Erzeuge einen Ed25519-Schlüssel mit Passphrase und einem Kommentar, der das Gerät nennt.
• Lade den Schlüssel in ssh-agent, damit du die Passphrase nur einmal pro Sitzung tippst.
• Kopiere nur die .pub-Datei auf den Server, zu GitHub oder ins Anbieter-Panel.
• Vergleiche bei der ersten Verbindung den Fingerabdruck des Servers, statt blind yes zu tippen.
• Teste die Schlüssel-Anmeldung in einem zweiten Fenster, mit abgeschalteten Passwort-Methoden auf der Client-Seite.
• Schalte PasswordAuthentication und KbdInteractiveAuthentication erst ab, wenn dieser Test klappt.
• Prüfe die wirksame Konfiguration mit sshd -T, bevor du den Dienst neu startest.
• Lass eine Sitzung offen, bis die neue Anmeldung funktioniert.
• Hinterlege einen zweiten Schlüssel und schreib auf, wie du einen verlorenen entfernst.

Passt dazu: Docker auf dem VPS: Firewall und Absicherung; Minecraft-Server auf einem VPS; Palworld, Valheim & Co. auf einem VPS; WireGuard oder Tailscale fürs Homelab; Passkey (FIDO2-Anmeldung); Public-Key-Verfahren.