Ein gestohlenes Passwort ist 2026 die häufigste Eintrittstür in fremde Server. SSH-Keys schließen diese Tür: Statt einer Zeichenkette, die man erraten, abfangen oder per Phishing abgreifen kann, authentifizierst du dich mit einem kryptografischen Schlüsselpaar, das niemals über die Leitung wandert. In diesem Tutorial lernst du, einen SSH-Key zu erstellen, ihn auf Server und in GitHub einzubinden und deinen Zugang so zu härten, dass Passwort-Logins komplett verschwinden.

Wir setzen auf Ed25519, den 2026 empfohlenen Standard, zeigen alle Befehle für Linux, macOS und Windows 11 und gehen bis zu FIDO2-Hardware-Keys und post-quanten-sicherem Schlüsselaustausch in OpenSSH 10. Am Ende steht ein komplettes, lauffähiges Projekt: ein abgesicherter SSH-Zugang von Null auf, in unter 30 Minuten. Alle Befehle sind getestet, jede Konfiguration kommentiert.

Warum du 2026 einen SSH-Key erstellen solltest

SSH (Secure Shell) nutzt asymmetrische Kryptografie. Du erzeugst ein Paar aus privatem und öffentlichem Schlüssel. Der private Schlüssel bleibt auf deinem Rechner und verlässt ihn nie. Den öffentlichen Schlüssel legst du auf jedem Server ab, auf den du zugreifen willst. Beim Login beweist dein Client, dass er den passenden privaten Schlüssel besitzt, ohne ihn jemals zu übertragen. Genau dieses Prinzip kennst du aus den digitalen Signaturen: Wer den privaten Schlüssel hält, kann signieren, und jeder mit dem öffentlichen Schlüssel kann die Signatur prüfen.

Der Sicherheitsgewinn ist messbar. Ein automatisierter Brute-Force-Angriff testet Tausende Passwörter pro Minute gegen offene SSH-Ports. Gegen einen Ed25519-Schlüssel ist dieser Angriff sinnlos: Der Schlüsselraum ist so groß, dass Raten unmöglich wird. Sobald du Passwort-Logins abschaltest, fallen die typischen Wörterbuch- und Credential-Stuffing-Angriffe einfach ins Leere. Bots, die deinen Port scannen, bekommen schlicht keinen Hebel mehr.

Hinzu kommt der Komfort. Hast du einen SSH-Key erstellt und in den ssh-agent geladen, loggst du dich ohne Passworteingabe ein. Du verbindest dich mit Servern, ziehst Code von GitHub und automatisierst Deployments, ohne ständig Zeichenketten einzutippen. Sicherheit und Bequemlichkeit ziehen hier ausnahmsweise am selben Strang. Wer einmal sauber eingerichtet hat, will nicht zurück.

Ein dritter Punkt betrifft die Zukunft. Klassische Schlüsselaustauschverfahren geraten durch Quantencomputer unter Druck. OpenSSH hat darauf bereits reagiert und kombiniert klassische Verfahren mit post-quanten-sicheren KEMs. Wer heute einen SSH-Key erstellt und seinen Server korrekt konfiguriert, profitiert ohne Mehraufwand von diesem Schutz. Mehr dazu im Abschnitt zu OpenSSH 10 weiter unten und in unserem Überblick zur Post-Quanten-Kryptografie.

Voraussetzungen: Diese Versionen brauchst du

SSH-Keys erzeugst du mit dem Werkzeug ssh-keygen, das Teil von OpenSSH ist. Auf praktisch jedem aktuellen Betriebssystem ist es vorinstalliert. Prüfe vor dem Start kurz deine Version, denn neuere Funktionen wie FIDO2-Keys und der post-quanten-sichere Schlüsselaustausch brauchen eine hinreichend aktuelle OpenSSH-Version.

KomponenteEmpfohlene Version (2026)PrüfbefehlHinweis
OpenSSH10.0 oder neuerssh -VAktuell verbreitete Version, bringt Hybrid-PQ-Austausch
Linux (Ubuntu/Debian)OpenSSH aus Paketquelleapt list --installed | grep opensshStandardmäßig installiert
macOSintegriertes OpenSSHssh -VÜber Homebrew aktualisierbar
Windows 11OpenSSH Client (Feature)ssh -VVorinstalliert seit Windows 10 1809
FIDO2-Sticked25519-sk-fähigHerstellerangabeNur für Hardware-Keys nötig

Prüfe deine OpenSSH-Version mit einem einzigen Befehl. Die Ausgabe nennt dir Client-Version und die genutzte Krypto-Bibliothek.

$ ssh -V
OpenSSH_10.0p1, OpenSSL 3.5.0 1 Apr 2026

Ist deine Version älter als OpenSSH 8.2, fehlt dir die FIDO2-Unterstützung. Älter als 9.0, fehlt der hybride post-quanten-sichere Schlüsselaustausch. Für das reine Erstellen eines Ed25519-Schlüssels reicht jede Version ab OpenSSH 6.5 aus dem Jahr 2014, weil Ed25519 schon damals eingeführt wurde. Aktualisiere unter Linux mit deinem Paketmanager, unter macOS per Homebrew (brew upgrade openssh) und unter Windows über die optionalen Features oder winget.

Lege außerdem fest, wo deine Schlüssel liegen sollen. Standard ist das Verzeichnis ~/.ssh in deinem Benutzerordner. Existiert es noch nicht, erstellt ssh-keygen es automatisch. Wer mehrere Identitäten verwaltet, etwa privat und beruflich getrennt, sollte sich schon jetzt eine Namenskonvention für die Schlüsseldateien überlegen.

Ed25519 vs. RSA vs. ECDSA: Welcher Schlüsseltyp 2026?

Bevor du einen SSH-Key erstellst, entscheidest du dich für einen Schlüsseltyp. Es gibt drei relevante Optionen, und die Wahl ist 2026 einfacher als früher. Ed25519 ist für neue Schlüssel die erste Wahl. Die Kurve gehört zur Familie der elliptischen Kurven und bietet starke Sicherheit bei sehr kleinen Schlüsseln und hoher Geschwindigkeit.

SchlüsseltypEmpfohlene GrößeSicherheit 2026GeschwindigkeitEmpfehlung
Ed25519fix (256-Bit-Kurve)Sehr hochSehr schnellStandard für neue Keys
RSA4096 BitHochLangsamerNur für Altsysteme
ECDSA521 BitHochSchnellSelten nötig
RSA 20482048 BitGerade noch ausreichendLangsamerVermeiden
ed25519-skfix + HardwareSehr hoch, Phishing-SchutzSchnellHöchste Sicherheit

Wann Ed25519, wann RSA?

Nimm Ed25519, wenn nichts dagegen spricht, und das ist 2026 fast immer der Fall. Ed25519-Schlüssel sind kompakt, schnell und gelten als robust gegen die bekannten Implementierungsfehler, die ECDSA bei schlechter Zufallszahlenerzeugung plagen. Greife nur dann zu RSA mit 4096 Bit, wenn du ein altes Gerät oder eine veraltete Appliance bedienen musst, die Ed25519 nicht versteht. Solche Fälle werden jedes Jahr seltener.

ECDSA ist technisch in Ordnung, bietet gegenüber Ed25519 aber keinen Vorteil und hat eine heiklere Implementierungsgeschichte. Wenn du keinen zwingenden Grund für ECDSA hast, lass es weg. RSA mit nur 2048 Bit solltest du für neue Schlüssel meiden. Es ist nicht akut gebrochen, aber es gibt keinen Grund, am unteren Rand des Sicherheitsniveaus zu starten, wenn Ed25519 kostenlos mehr bietet.

Für maximale Sicherheit kombinierst du Ed25519 mit einem Hardware-Token, also einem ed25519-sk-Schlüssel. Dabei liegt der eigentliche private Schlüssel auf einem FIDO2-Stick und lässt sich nicht exportieren. Selbst wenn jemand deinen Rechner kompromittiert, kann er sich ohne den physischen Stick nicht anmelden. Diesen Weg behandeln wir weiter unten ausführlich.

SSH-Key erstellen unter Linux und macOS in 8 Schritten

Jetzt zum Kern: Wir erstellen einen SSH-Key Schritt für Schritt. Die folgenden acht Schritte gelten identisch für Linux und macOS, weil beide auf OpenSSH setzen. Windows folgt im nächsten Abschnitt mit minimalen Abweichungen.

  1. Terminal öffnen. Unter Linux per Tastenkürzel oder Anwendungsmenü, unter macOS über Spotlight und Eingabe von “Terminal”.
  2. SSH-Verzeichnis prüfen. Stelle sicher, dass ~/.ssh existiert. ssh-keygen legt es bei Bedarf selbst an.
  3. Schlüssel erzeugen. Führe den ssh-keygen-Befehl mit Ed25519 aus (siehe unten).
  4. Speicherort bestätigen. Drücke Enter für den Standardpfad oder gib einen eigenen Dateinamen ein.
  5. Passphrase setzen. Vergib eine starke Passphrase. Lass dieses Feld nicht leer.
  6. Schlüssel prüfen. Kontrolliere, dass die zwei Dateien angelegt wurden.
  7. In den ssh-agent laden. Damit musst du die Passphrase nur einmal pro Sitzung eingeben.
  8. Öffentlichen Schlüssel kopieren. Halte den Inhalt der .pub-Datei bereit für Server und Dienste.

Schritt 3: Der ssh-keygen-Befehl im Detail

Der zentrale Befehl ist kurz, aber jede Option hat einen Zweck. Wir nutzen Ed25519 und erhöhen die Zahl der KDF-Runden für die Verschlüsselung des privaten Schlüssels.

$ ssh-keygen -t ed25519 -a 64 -f ~/.ssh/id_ed25519 -C "[email protected]"
  • -t ed25519 wählt den Schlüsseltyp Ed25519.
  • -a 64 setzt 64 KDF-Runden. Höhere Werte verlangsamen Offline-Angriffe auf die Passphrase deiner privaten Schlüsseldatei.
  • -f ~/.ssh/id_ed25519 legt den Dateinamen fest.
  • -C "[email protected]" hängt einen Kommentar an, meist eine E-Mail oder ein Gerätename, zur leichteren Zuordnung.

Nach dem Aufruf fragt ssh-keygen nach einer Passphrase. Vergib unbedingt eine. Eine leere Passphrase bedeutet, dass jeder, der deine private Schlüsseldatei kopiert, sofort vollen Zugriff hat. Die Passphrase verschlüsselt die Datei lokal und ist deine letzte Verteidigungslinie, falls dein Rechner kompromittiert oder das Backup gestohlen wird. So sieht ein vollständiger Durchlauf aus:

Generating public/private ed25519 key pair.
Enter passphrase (empty for no passphrase): ********
Enter same passphrase again: ********
Your identification has been saved in /home/sam/.ssh/id_ed25519
Your public key has been saved in /home/sam/.ssh/id_ed25519.pub
The key fingerprint is:
SHA256:7n2Kx...gQ4 [email protected]
The key's randomart image is:
+--[ED25519 256]--+
|        .o+=O*o   |
|       . o+.B.+   |
|        . .* = .  |
+----[SHA256]-----+

Schritt 6 bis 7: Dateien prüfen und in den Agent laden

Es entstehen zwei Dateien: id_ed25519 (privat, geheim halten) und id_ed25519.pub (öffentlich, teilbar). Prüfe sie und lade den privaten Schlüssel in den ssh-agent, damit du die Passphrase nur einmal pro Sitzung brauchst.

$ ls -l ~/.ssh/id_ed25519*
-rw------- 1 sam sam  464 11. Jun 09:14 /home/sam/.ssh/id_ed25519
-rw-r--r-- 1 sam sam  100 11. Jun 09:14 /home/sam/.ssh/id_ed25519.pub

$ eval "$(ssh-agent -s)"
Agent pid 4821
$ ssh-add ~/.ssh/id_ed25519
Enter passphrase for /home/sam/.ssh/id_ed25519: ********
Identity added: /home/sam/.ssh/id_ed25519 ([email protected])

Achte auf die Berechtigungen: Der private Schlüssel zeigt -rw------- (600), der öffentliche -rw-r--r-- (644). Stimmen die Rechte des privaten Schlüssels nicht, verweigert OpenSSH später die Nutzung. Mehr dazu im Troubleshooting. Damit hast du erfolgreich einen SSH-Key erstellt und einsatzbereit gemacht.

SSH-Key erstellen unter Windows 11

Unter Windows 11 ist der OpenSSH-Client seit Jahren vorinstalliert. Du kannst einen SSH-Key erstellen, ohne PuTTY oder Zusatzsoftware. Öffne PowerShell (kein Administrator nötig) und nutze denselben ssh-keygen-Befehl wie unter Linux. Die Schlüssel landen in C:\Users\DEINNAME\.ssh.

PS C:\Users\sam> ssh-keygen -t ed25519 -a 64 -C "[email protected]"
Generating public/private ed25519 key pair.
Enter file in which to save the key (C:\Users\sam/.ssh/id_ed25519):
Enter passphrase (empty for no passphrase): ********
Your identification has been saved in C:\Users\sam/.ssh/id_ed25519
Your public key has been saved in C:\Users\sam/.ssh/id_ed25519.pub

Den ssh-agent unter Windows startest du als Dienst. Standardmäßig ist er auf manuell gesetzt. Aktiviere ihn einmalig in einer PowerShell mit Administratorrechten und lade danach deinen Schlüssel wie gewohnt.

PS C:\> Get-Service ssh-agent | Set-Service -StartupType Automatic
PS C:\> Start-Service ssh-agent
PS C:\> ssh-add $env:USERPROFILE\.ssh\id_ed25519

Den öffentlichen Schlüssel kopierst du unter Windows am einfachsten in die Zwischenablage mit Get-Content $env:USERPROFILE\.ssh\id_ed25519.pub | Set-Clipboard. Danach fügst du ihn in GitHub, GitLab oder die authorized_keys deines Servers ein. Wer lieber eine grafische Oberfläche nutzt, kann weiterhin PuTTYgen verwenden, sollte aber darauf achten, den Schlüssel im OpenSSH-Format zu exportieren, damit er mit dem integrierten Client kompatibel ist.

Ein häufiger Stolperstein unter Windows betrifft die Dateirechte. Anders als unter Linux setzt Windows keine Unix-Berechtigungen. Meldet OpenSSH unter Windows trotzdem zu offene Rechte, musst du in den Sicherheitseinstellungen der Datei alle Benutzer außer deinem eigenen Konto entfernen. Das passiert vor allem, wenn du Schlüssel von einem anderen Rechner kopiert hast.

Public Key auf den Server bringen: ssh-copy-id und authorized_keys

Ein Schlüsselpaar allein bringt dich noch auf keinen Server. Du musst den öffentlichen Schlüssel auf dem Zielsystem hinterlegen, und zwar in der Datei ~/.ssh/authorized_keys des Zielbenutzers. Diese Datei ist die Allowlist: Der Server akzeptiert nur Schlüssel, die hier eingetragen sind. Der schnellste und sicherste Weg dafür ist ssh-copy-id.

$ ssh-copy-id -i ~/.ssh/id_ed25519.pub [email protected]
/usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s)
[email protected]'s password: ********
Number of key(s) added: 1

Now try logging into the machine, with:   "ssh [email protected]"

Der Befehl meldet sich einmalig mit Passwort an (deshalb brauchst du dafür noch Passwort-Zugang) und hängt deinen öffentlichen Schlüssel an die authorized_keys an, ohne bestehende Einträge zu überschreiben. Danach kannst du dich per Schlüssel anmelden. Teste das sofort, bevor du im nächsten Schritt den Passwort-Login deaktivierst.

Steht ssh-copy-id nicht zur Verfügung, etwa unter Windows, fügst du den Schlüssel manuell hinzu. Achte dabei penibel auf die Berechtigungen, sonst ignoriert der Server die Datei aus Sicherheitsgründen.

$ ssh [email protected] "mkdir -p ~/.ssh && chmod 700 ~/.ssh"
$ cat ~/.ssh/id_ed25519.pub | ssh [email protected] "cat >> ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys"

Verbinde dich anschließend testweise. Beim ersten Mal speichert dein Client den Host-Schlüssel des Servers in ~/.ssh/known_hosts und fragt dich nach Bestätigung. Diese Prüfung schützt vor einem Man-in-the-Middle: Ändert sich der Host-Schlüssel später unerwartet, warnt dich OpenSSH. Bestätige eine solche Warnung niemals blind, sondern kläre erst, warum sich der Schlüssel geändert hat.

SSH-Key bei GitHub und GitLab hinterlegen

Die häufigste Nutzung von SSH-Keys außerhalb von Servern ist der Zugang zu Git-Plattformen. GitHub und GitLab nutzen SSH-Keys, damit du Code pushen und pullen kannst, ohne bei jedem Vorgang ein Token einzugeben. Wichtig: Du hinterlegst immer nur den öffentlichen Schlüssel, also den Inhalt der .pub-Datei. Der private Schlüssel bleibt auf deinem Rechner.

Zeige zuerst den öffentlichen Schlüssel an und kopiere die komplette Zeile, von ssh-ed25519 bis zum Kommentar am Ende.

$ cat ~/.ssh/id_ed25519.pub
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIH8k...3vQ [email protected]
  1. Bei GitHub: Settings, dann SSH and GPG keys, dann New SSH key. Titel vergeben, Schlüssel einfügen, speichern.
  2. Bei GitLab: Preferences, dann SSH Keys. Schlüssel einfügen, optional ein Ablaufdatum setzen, hinzufügen.
  3. Verbindung testen mit dem unten stehenden Befehl.
$ ssh -T [email protected]
Hi sam! You've successfully authenticated, but GitHub does not provide shell access.

$ ssh -T [email protected]
Welcome to GitLab, @sam!

Bekommst du stattdessen eine Abfrage nach einem Passwort oder eine Permission-denied-Meldung, stimmt etwas mit dem hinterlegten Schlüssel oder deiner lokalen Konfiguration nicht. Prüfe, ob du wirklich den öffentlichen und nicht versehentlich den privaten Schlüssel eingefügt hast, und ob der ssh-agent den passenden Schlüssel geladen hat. Die Authentifizierung gegenüber GitHub funktioniert nach demselben Prinzip wie das Vertrauensmodell hinter HTTPS und TLS: Beide setzen auf kryptografische Identitäten statt auf geteilte Geheimnisse.

ssh-agent und ~/.ssh/config richtig nutzen

Sobald du mehrere Schlüssel und Server verwaltest, wird die Datei ~/.ssh/config dein wichtigstes Werkzeug. Dort definierst du Host-Aliase, weist jedem Host den richtigen Schlüssel zu und vermeidest, dass dein Client wahllos alle Identitäten durchprobiert. Letzteres kann dazu führen, dass ein Server dich nach zu vielen Fehlversuchen sperrt.

# ~/.ssh/config

Host github.com
    HostName github.com
    User git
    IdentityFile ~/.ssh/id_ed25519
    IdentitiesOnly yes

Host produktion
    HostName server.beispiel.de
    User sam
    Port 22
    IdentityFile ~/.ssh/id_ed25519_prod
    IdentitiesOnly yes
    AddKeysToAgent yes

Mit dieser Konfiguration verbindest du dich einfach per ssh produktion, statt jedes Mal Benutzername, Host und Port einzutippen. IdentitiesOnly yes sorgt dafür, dass nur der angegebene Schlüssel verwendet wird. AddKeysToAgent yes lädt den Schlüssel beim ersten Gebrauch automatisch in den Agent. Das spart Tipparbeit und reduziert Fehler.

Mehrere Schlüssel sauber trennen

Viele Nutzer trennen private und berufliche Identitäten. Erstelle dafür einfach mehrere Schlüssel mit unterschiedlichen Dateinamen, etwa id_ed25519_privat und id_ed25519_arbeit, und ordne sie in der config verschiedenen Hosts zu. So pushst du mit dem richtigen Account, ohne nachzudenken. Prüfe mit ssh-add -l jederzeit, welche Schlüssel aktuell im Agent geladen sind.

$ ssh-add -l
256 SHA256:7n2Kx...gQ4 [email protected] (ED25519)
256 SHA256:9p4Lz...rT2 [email protected] (ED25519)

Server härten: Passwort-Login deaktivieren in sshd_config

Der wahre Sicherheitsgewinn entsteht erst, wenn du den Passwort-Login komplett abschaltest. Solange Passwörter erlaubt sind, bleibt dein Server ein Ziel für Brute-Force-Bots, egal wie gut dein Schlüssel ist. Bearbeite dafür die Datei /etc/ssh/sshd_config auf dem Server. Wichtig: Stelle vorher sicher, dass dein Schlüssel-Login funktioniert, sonst sperrst du dich aus.

# /etc/ssh/sshd_config

PasswordAuthentication no
PubkeyAuthentication yes
PermitRootLogin prohibit-password
ChallengeResponseAuthentication no
UsePAM yes

Nach der Änderung prüfst du die Konfiguration auf Syntaxfehler und lädst den Dienst neu. Der Test mit sshd -t ist Pflicht, denn ein Tippfehler kann verhindern, dass der SSH-Dienst überhaupt startet.

$ sudo sshd -t
$ sudo systemctl reload ssh
# Halte parallel eine bestehende Sitzung offen und teste in einem
# zweiten Terminal eine neue Verbindung, bevor du die erste schliesst.

Die goldene Regel beim Härten lautet: Schließe niemals deine aktive Sitzung, bevor du in einem zweiten Terminal eine neue Verbindung erfolgreich getestet hast. Sperrst du dich bei einem Cloud-Server aus, hilft oft nur noch die Notfall-Konsole des Anbieters. Setze PermitRootLogin prohibit-password statt eines kompletten Verbots, wenn du Root-Zugang per Schlüssel für Automatisierung brauchst. Sonst ist no die sicherere Wahl.

Ergänzend lohnt sich der Einsatz von fail2ban, das wiederholte Fehlversuche automatisch blockiert, sowie das Verschieben des SSH-Ports weg von 22. Letzteres bringt keine echte Sicherheit, reduziert aber das Grundrauschen automatisierter Scans im Log spürbar. Das Bundesamt für Sicherheit in der Informationstechnik gibt weitere Empfehlungen zur sicheren Serverkonfiguration heraus.

FIDO2-Hardware-Keys: ed25519-sk für Phishing-Schutz

Die sicherste Variante, einen SSH-Key zu erstellen, bindet den Schlüssel an einen physischen FIDO2-Stick. Bei einem ed25519-sk-Schlüssel (“sk” steht für security key) liegt das eigentliche Schlüsselgeheimnis im Hardware-Token und lässt sich nicht exportieren. Auf der Festplatte landet nur ein Handle, das ohne den Stick wertlos ist. Selbst Malware mit vollem Zugriff auf deinen Rechner kann den Schlüssel nicht stehlen.

$ ssh-keygen -t ed25519-sk -O resident -O verify-required -C "sam-yubikey"
Generating public/private ed25519-sk key pair.
You may need to touch your authenticator to authorize key generation.
Enter PIN for authenticator: ****
Enter passphrase (empty for no passphrase): ********

Die Option -O resident speichert den Schlüssel auf dem Token selbst, sodass du ihn auf einem neuen Rechner mit ssh-keygen -K wieder herunterladen kannst. -O verify-required erzwingt eine PIN oder einen Fingerabdruck bei jeder Nutzung. Bei jedem Login musst du den Stick zusätzlich berühren. Genau diese physische Bestätigung macht Phishing praktisch unmöglich: Ein Angreifer aus der Ferne kann deinen Finger nicht ersetzen.

Der öffentliche Schlüssel landet wie gewohnt in einer .pub-Datei und wird genauso in authorized_keys, GitHub oder GitLab hinterlegt. Für Administratoren kritischer Systeme und für alle, die Wert auf höchste Sicherheit legen, sind Hardware-Keys 2026 der Goldstandard. Wer das Konzept hardwaregebundener Geheimnisse aus dem Krypto-Bereich kennt, etwa von sicherem Schlüsselmaterial, findet sich hier schnell zurecht. Gute Geheimnisverwaltung beginnt ohnehin bei robustem Passwort-Hashing mit Argon2.

Post-Quanten-SSH: Hybrider Schlüsselaustausch in OpenSSH 10

Ein Aspekt, den viele Anleitungen übergehen: der Schutz vor zukünftigen Quantencomputern. Während dein Ed25519-Schlüssel die Authentifizierung übernimmt, sichert ein separater Schlüsselaustausch die eigentliche Verbindung. Genau dieser Austausch ist durch Quantencomputer gefährdet, weil aufgezeichneter Datenverkehr später entschlüsselt werden könnte. Das nennt man “harvest now, decrypt later”.

OpenSSH hat darauf reagiert und nutzt hybride Verfahren, die klassische Kryptografie mit einem post-quanten-sicheren KEM kombinieren. Aktuell sind das sntrup761x25519-sha512 und das neuere mlkem768x25519-sha256, das auf dem von der NIST standardisierten ML-KEM basiert. Hybrid heißt: Selbst wenn eines der beiden Verfahren bricht, bleibt die Verbindung sicher.

# In /etc/ssh/sshd_config oder ~/.ssh/config erzwingen:
KexAlgorithms mlkem768x25519-sha256,sntrup761x25519-sha512

# Aktiven Algorithmus einer Verbindung pruefen:
$ ssh -v [email protected] 2>&1 | grep "kex:"
debug1: kex: algorithm: mlkem768x25519-sha256

Mit aktueller OpenSSH-Version auf beiden Seiten passiert das automatisch, ohne dass du etwas tun musst. Willst du sichergehen, erzwingst du die Algorithmen wie oben gezeigt. Wichtig zu verstehen: Dein Ed25519-Schlüssel zur Authentifizierung ist davon getrennt und muss nicht ausgetauscht werden. Den größeren Kontext zu diesem Wandel beschreiben wir im Artikel zur Post-Quanten-Kryptografie.

6 häufige Fehler beim SSH-Key erstellen

Diese sechs Fehler tauchen in der Praxis immer wieder auf. Wer sie kennt, spart sich stundenlange Fehlersuche.

  • Leere Passphrase. Ein unverschlüsselter privater Schlüssel ist eine offene Tür, sobald die Datei in falsche Hände gerät. Setze immer eine Passphrase und nutze den ssh-agent für den Komfort.
  • Privaten Schlüssel hochladen. Niemals den privaten Schlüssel an einen Dienst oder Server schicken. Nur die .pub-Datei wird geteilt. Wer den privaten Schlüssel hochlädt, muss das Paar sofort wegwerfen.
  • Falsche Dateirechte. Ist der private Schlüssel für andere lesbar, verweigert OpenSSH die Nutzung. chmod 600 für den Schlüssel, chmod 700 für ~/.ssh.
  • Passwort-Login zu früh deaktivieren. Erst den Schlüssel-Login testen, dann Passwörter abschalten. Sonst drohst du dich auszusperren.
  • Host-Key-Warnungen ignorieren. Eine Warnung über einen geänderten Host-Schlüssel kann auf einen Angriff hindeuten. Erst klären, dann bestätigen.
  • RSA 2048 oder veraltetes ECDSA wählen. Für neue Schlüssel gibt es keinen Grund, unter Ed25519 zu bleiben.

Ein siebter, oft übersehener Fehler: keine Backups des privaten Schlüssels. Verlierst du ihn, kommst du nicht mehr auf deine Server, bis du den neuen öffentlichen Schlüssel überall nachträgst. Lege ein verschlüsseltes Backup an, etwa in einem Passwortmanager oder auf einem getrennten, verschlüsselten Medium. Wie gute Passwort- und Geheimnisverwaltung aussieht, zeigt unser Leitfaden zur Passwort-Sicherheit.

Troubleshooting: 8 typische SSH-Probleme lösen

Wenn die Verbindung nicht klappt, hilft fast immer der ausführliche Modus mit ssh -v (oder -vvv für maximale Details). Die folgende Tabelle fasst die acht häufigsten Probleme und ihre Lösungen zusammen.

Fehlermeldung / SymptomUrsacheLösung
Permission denied (publickey)Schlüssel nicht hinterlegt oder falscher Schlüsselssh-add -l prüfen, authorized_keys kontrollieren
WARNING: UNPROTECTED PRIVATE KEY FILEZu offene Dateirechtechmod 600 ~/.ssh/id_ed25519
Agent admitted failure to signSchlüssel nicht im Agentssh-add ~/.ssh/id_ed25519
Host key verification failedHost-Schlüssel geändertUrsache klären, Eintrag in known_hosts bereinigen
Too many authentication failuresClient probiert zu viele SchlüsselIdentitiesOnly yes in der config setzen
Connection refusedSSH-Dienst aus oder falscher PortPort und Dienststatus auf dem Server prüfen
Passwortabfrage trotz SchlüsselSchlüssel nicht akzeptiertssh -v nutzen, Pfad und Rechte prüfen
no mutual signature algorithmAlter RSA-Schlüssel, Server lehnt SHA-1 abNeuen Ed25519-Schlüssel erstellen

Bei “Host key verification failed” entfernst du den veralteten Eintrag gezielt, statt die ganze Datei zu löschen. Vergewissere dich aber zuerst, dass die Änderung legitim ist, etwa nach einer Neuinstallation des Servers.

$ ssh-keygen -R server.beispiel.de
# Host server.beispiel.de found: line 12
/home/sam/.ssh/known_hosts updated.

Hilft das nicht weiter, schau in das Server-Log. Unter den meisten Linux-Distributionen findest du SSH-Meldungen mit sudo journalctl -u ssh -n 50. Dort steht oft im Klartext, warum eine Anmeldung abgelehnt wurde, etwa wegen falscher Berechtigungen auf authorized_keys oder einem deaktivierten Konto.

Profi-Tipps: Key-Rotation, Agent-Forwarding und Zertifikate

Hast du die Grundlagen gemeistert, heben dich ein paar fortgeschrittene Praktiken auf das nächste Niveau. Erstens die Schlüssel-Rotation: Tausche wichtige Schlüssel regelmäßig aus, etwa jährlich, und entferne alte öffentliche Schlüssel aus allen authorized_keys. Setze bei GitLab ein Ablaufdatum, damit vergessene Schlüssel nicht ewig gültig bleiben.

Zweitens Agent-Forwarding: Mit ssh -A oder ForwardAgent yes kannst du deinen lokalen Agent auf einem entfernten Server nutzen, um von dort zu einem dritten System zu springen, ohne den Schlüssel auf den Zwischenserver zu kopieren. Vorsicht: Wer Root auf dem Zwischenserver hat, kann deinen Agent missbrauchen, solange die Verbindung steht. Nutze Forwarding nur für vertrauenswürdige Hosts und besser ProxyJump für die meisten Fälle.

# Sicherer als Agent-Forwarding: ProxyJump ueber einen Bastion-Host
$ ssh -J bastion.beispiel.de [email protected]

# Oder dauerhaft in ~/.ssh/config:
Host intern
    HostName intern.beispiel.de
    User sam
    ProxyJump bastion.beispiel.de

Drittens SSH-Zertifikate: In größeren Umgebungen skaliert das Verteilen einzelner öffentlicher Schlüssel schlecht. Mit einer eigenen Zertifizierungsstelle signierst du Schlüssel zentral. Server vertrauen dann der CA statt jedem Einzelschlüssel. Das vereinfacht das Onboarding und das Sperren ausgeschiedener Mitarbeiter erheblich. Für Heim- und kleine Serverumgebungen ist das überdimensioniert, in Unternehmen ab einer gewissen Größe aber sehr empfehlenswert.

Komplettes Projekt: Sicherer SSH-Zugang von Null

Fügen wir alles zu einem durchgehenden, lauffähigen Projekt zusammen. Ziel: ein frischer Cloud-Server, auf den du dich ausschließlich per Ed25519-Schlüssel anmeldest, ohne Passwort, ohne Root-Passwort-Login. Plane dafür rund 30 Minuten ein. Die folgende Reihenfolge ist bewusst so gewählt, dass du dich nicht aussperren kannst.

# 1. Lokal einen Ed25519-Schluessel erstellen
ssh-keygen -t ed25519 -a 64 -f ~/.ssh/id_ed25519_prod -C "prod-zugang"

# 2. In den Agent laden
ssh-add ~/.ssh/id_ed25519_prod

# 3. Public Key auf den Server bringen
ssh-copy-id -i ~/.ssh/id_ed25519_prod.pub [email protected]

# 4. Schluessel-Login testen (MUSS funktionieren)
ssh -i ~/.ssh/id_ed25519_prod [email protected] "echo Login OK"

# 5. Config-Eintrag anlegen
cat >> ~/.ssh/config <<'EOF'
Host produktion
    HostName server.beispiel.de
    User sam
    IdentityFile ~/.ssh/id_ed25519_prod
    IdentitiesOnly yes
    AddKeysToAgent yes
EOF

Jetzt härtest du den Server. Bleibe dabei in einer offenen SSH-Sitzung und teste jede Änderung in einem zweiten Terminal.

# Auf dem Server, in einer bestehenden Sitzung:

# 6. sshd_config absichern
sudo sed -i 's/^#\?PasswordAuthentication.*/PasswordAuthentication no/' /etc/ssh/sshd_config
sudo sed -i 's/^#\?PermitRootLogin.*/PermitRootLogin prohibit-password/' /etc/ssh/sshd_config

# 7. Syntax pruefen und neu laden
sudo sshd -t && sudo systemctl reload ssh

# 8. In einem ZWEITEN Terminal neuen Login testen
ssh produktion "echo Haertung erfolgreich"

Läuft Schritt 8 durch, ist dein Server abgesichert: Passwort-Logins sind aus, nur dein Ed25519-Schlüssel öffnet die Tür. Erst jetzt schließt du die ursprüngliche Sitzung. Optional ergänzt du fail2ban und erzwingst den post-quanten-sicheren Schlüsselaustausch, wie oben gezeigt. Damit hast du einen vollständigen, sicheren SSH-Zugang von Grund auf aufgebaut und dabei jeden kritischen Schritt verifiziert.

Dieses Muster lässt sich auf beliebig viele Server übertragen. Für die Automatisierung über viele Maschinen hinweg greifst du später zu Werkzeugen wie Ansible, die genau diese Schritte als wiederholbares Skript ausführen. Das Fundament aber, ein korrekt erzeugter und abgesicherter Schlüssel, bleibt immer dasselbe.

SSH-Keys für Dateiübertragung: scp, rsync und SFTP

Ein SSH-Key dient nicht nur zum Anmelden, sondern sichert auch jede Dateiübertragung über das SSH-Protokoll. Sobald dein Schlüssel-Login funktioniert, laufen scp, rsync und SFTP ohne Passwortabfrage. Das ist die Grundlage für automatisierte Backups und Deployments. Kopierst du eine Datei auf den Server, nutzt scp dieselbe Authentifizierung wie eine normale SSH-Sitzung.

# Einzelne Datei hochladen
$ scp ./backup.tar.gz [email protected]:/home/sam/

# Verzeichnis effizient synchronisieren (nur Aenderungen)
$ rsync -avz -e ssh ./website/ [email protected]:/var/www/

# Mit Host-Alias aus der config noch kuerzer
$ rsync -avz ./website/ produktion:/var/www/

Der Parameter -avz bei rsync steht für Archivmodus, ausführliche Ausgabe und Komprimierung. In Verbindung mit deinem Host-Alias aus der ~/.ssh/config werden Befehle sehr kurz und lesbar. Für wiederkehrende Backups packst du genau diese Zeilen in ein Skript und automatisierst sie per cron. Da kein Passwort nötig ist, läuft das vollständig unbeaufsichtigt, vorausgesetzt, dein Schlüssel hat entweder keine Passphrase (nur für dedizierte Backup-Schlüssel ratsam) oder liegt in einem persistenten Agent.

Auch Entwicklungswerkzeuge bauen auf SSH-Keys auf. Die Remote-Funktion gängiger Editoren wie VS Code verbindet sich per SSH und nutzt automatisch deine ~/.ssh/config. Hast du dort einen Host sauber definiert, erscheint er direkt in der Editor-Oberfläche. Ein einmal korrekt erstellter Schlüssel zahlt sich also in der gesamten Werkzeugkette aus, vom Terminal über Git bis zur Remote-Entwicklung.

SSH-Key sichern und auf neue Geräte übertragen

Irgendwann wechselst du den Rechner oder richtest ein zweites Gerät ein. Dann stellt sich die Frage, wie der Schlüssel sicher mitwandert. Grundsätzlich gilt: Der private Schlüssel darf niemals unverschlüsselt über unsichere Kanäle wandern, also nicht per E-Mail, Chat oder Cloud-Ordner ohne zusätzliche Verschlüsselung. Eine starke Passphrase auf der Schlüsseldatei ist hier deine wichtigste Absicherung.

Es gibt zwei saubere Wege. Der erste: Du erzeugst auf jedem Gerät einen eigenen Schlüssel und hinterlegst alle öffentlichen Schlüssel auf den Servern. Das ist die empfohlene Praxis, weil ein verlorenes Gerät dann nur seinen eigenen Schlüssel mitnimmt, den du gezielt sperren kannst. Der zweite Weg überträgt einen bestehenden Schlüssel auf ein verschlüsseltes Medium, etwa einen USB-Stick mit Festplattenverschlüsselung, oder über einen sicheren Kanal wie scp.

# Empfohlen: pro Geraet ein eigener Schluessel
$ ssh-keygen -t ed25519 -a 64 -f ~/.ssh/id_ed25519_laptop -C "laptop-2026"

# Den neuen Public Key zusaetzlich auf dem Server hinterlegen
$ ssh-copy-id -i ~/.ssh/id_ed25519_laptop.pub produktion

# Fingerprint eines Schluessels jederzeit pruefen
$ ssh-keygen -lf ~/.ssh/id_ed25519_laptop.pub
256 SHA256:Qa1Wb...xZ9 laptop-2026 (ED25519)

Verwaltest du Schlüssel auf einem FIDO2-Stick mit der Option -O resident, brauchst du gar keine Übertragung. Auf dem neuen Gerät lädst du die residenten Schlüssel einfach mit ssh-keygen -K vom Token herunter. Das ist einer der praktischsten Vorteile von Hardware-Keys: Der Stick ist dein tragbarer, nicht kopierbarer Schlüsselbund. Dokumentiere zusätzlich, welcher Fingerprint zu welchem Gerät gehört, damit du im Ernstfall genau den richtigen Schlüssel sperren kannst.

Häufig gestellte Fragen zum SSH-Key erstellen

Wie erstelle ich am schnellsten einen SSH-Key?

Öffne ein Terminal und führe ssh-keygen -t ed25519 -a 64 -C "[email protected]" aus. Bestätige den Speicherort mit Enter und vergib eine starke Passphrase. In unter einer Minute hast du ein einsatzbereites Ed25519-Schlüsselpaar erstellt.

Ed25519 oder RSA, was ist 2026 besser?

Für neue Schlüssel ist Ed25519 die klare Empfehlung. Es ist schneller, kompakter und mindestens so sicher wie RSA 4096. RSA brauchst du nur noch, wenn ein altes System Ed25519 nicht unterstützt. Dann nimm mindestens 4096 Bit.

Wo wird der private SSH-Schlüssel gespeichert?

Standardmäßig im Verzeichnis ~/.ssh deines Benutzers, unter Windows in C:\Users\DEINNAME\.ssh. Der private Schlüssel heißt id_ed25519, der öffentliche id_ed25519.pub. Der private Schlüssel darf diesen Ort nie verlassen.

Brauche ich für jeden Server einen eigenen Schlüssel?

Nicht zwingend. Du kannst einen Schlüssel für mehrere Server nutzen. Aus Sicherheitsgründen empfiehlt sich aber eine Trennung nach Kontext, etwa je ein Schlüssel für privat, Arbeit und kritische Produktion. So begrenzt du den Schaden, falls ein Schlüssel kompromittiert wird.

Was passiert, wenn ich meinen privaten Schlüssel verliere?

Ohne den privaten Schlüssel kommst du nicht mehr auf die zugehörigen Server. Du musst über einen alternativen Zugang einen neuen Schlüssel erstellen und dessen öffentlichen Teil überall nachtragen. Entferne den verlorenen öffentlichen Schlüssel sofort aus allen authorized_keys. Deshalb sind verschlüsselte Backups wichtig.

Ist ein SSH-Key sicher gegen Quantencomputer?

Die Authentifizierung per Ed25519 gilt vorerst als robust. Der Schlüsselaustausch der Verbindung wird in aktuellem OpenSSH zusätzlich durch hybride post-quanten-sichere Verfahren wie mlkem768x25519-sha256 geschützt. Wer aktuelle Versionen nutzt, ist gegen “harvest now, decrypt later” gewappnet.

Muss ich eine Passphrase setzen?

Ja, unbedingt. Eine Passphrase verschlüsselt deinen privaten Schlüssel auf der Festplatte. Ohne sie hat jeder, der die Datei kopiert, sofort vollen Zugriff. Mit dem ssh-agent musst du die Passphrase nur einmal pro Sitzung eingeben, der Komfort leidet also kaum.

Verwandte Artikel

Weiterführende offizielle Quellen: das OpenSSH-Projekt, die ssh-keygen-Handbuchseite, die GitHub-Dokumentation zu SSH-Keys, die GitLab-SSH-Dokumentation sowie RFC 8709 zur Ed25519-Nutzung in SSH.