SSH Key erstellen

Was sind SSH-Keys?

Ein SSH-Key ist ein Schlüsselpaar, mit dem du dich an einem Server anmeldest, ohne ein Passwort zu tippen. Der Server prüft dabei nicht, ob du ein Geheimnis kennst, sondern ob du eines besitzt. Genau darin liegt der Unterschied: Ein Passwort wandert bei jeder Anmeldung zum Server und lässt sich raten. Ein privater Schlüssel verlässt deinen Rechner nie.

Was das praktisch bedeutet, sieht jeder, der einen Server offen im Internet stehen hat. Im Log stehen fortlaufend Anmeldeversuche mit geratenen Benutzernamen und Passwörtern. Gegen einen hinterlegten Schlüssel richten diese Versuche nichts aus, weil es nichts zu raten gibt. Schaltest du danach die Passwort-Anmeldung ganz ab, hören die Versuche zwar nicht auf, laufen aber ins Leere. Der Schalter dafür heißt PasswordAuthentication no und steht in /etc/ssh/sshd_config.

Definition und Funktionsweise

SSH-Keys arbeiten mit asymmetrischer Kryptografie. Es gehören immer zwei Dateien zusammen: der private Schlüssel, der auf deinem Rechner bleibt, und der öffentliche, den du auf dem Server hinterlegst. Was mit dem einen signiert wurde, lässt sich nur mit dem anderen prüfen.

Die Anmeldung ist schnell erzählt. Dein Client nennt dem Server, welchen öffentlichen Schlüssel er benutzen will. Findet der Server ihn in der Datei ~/.ssh/authorized_keys des Zielbenutzers, stellt er eine Aufgabe, die nur mit dem passenden privaten Schlüssel zu lösen ist. Der Client signiert, der Server prüft die Signatur. Der private Schlüssel selbst geht dabei nie über die Leitung.

Auf die Reihenfolge kommt es an: Der öffentliche Schlüssel liegt vorher auf dem Server, nicht erst beim Verbindungsaufbau. Dieses Hinterlegen ist der einzige Schritt, der Handarbeit verlangt, und zugleich der, den ssh-copy-id weiter unten abnimmt.

Anwendungsgebiete von SSH-Keys

SSH-Keys tauchen überall dort auf, wo jemand regelmäßig auf entfernte Rechner zugreift. Administratoren melden sich damit an Servern an. Entwickler schieben Code zu GitHub, GitLab oder Codeberg, ohne bei jedem git push etwas einzutippen. Für automatisierte Abläufe gibt es gar keine Alternative: Ein Backup-Skript, das um drei Uhr nachts läuft, kann kein Passwort eingeben, ein Deploy aus einer CI-Pipeline ebenso wenig.

Bei manchen Diensten ist die Frage ohnehin entschieden. GitHub nimmt seit dem 15. März 2022 keine DSA-Schlüssel (ssh-dss) mehr an, und RSA-Schlüssel, die nach diesem Datum erzeugt wurden, müssen mit einer SHA-2-Signatur arbeiten (GitHub-Dokumentation).

Unterschied zwischen öffentlichen und privaten Keys

Die Trennung der beiden Hälften ist der ganze Trick. Der öffentliche Schlüssel ist kein Geheimnis. Er darf in einem Ticket stehen oder per Mail verschickt werden, denn aus ihm lässt sich der private nicht zurückrechnen. Der private Schlüssel dagegen ist das Zugangsrecht selbst: Wer die Datei hat, kommt auf jeden Server, auf dem das Gegenstück liegt.

„Öffentlich“ heißt trotzdem nicht „für alle lesbar“. Die Datei ~/.ssh/authorized_keys gehört dem jeweiligen Benutzer, und sshd verweigert den Schlüssel, sobald sie, das Verzeichnis ~/.ssh oder das Home-Verzeichnis für andere schreibbar sind. Diese Prüfung heißt StrictModes und steht ab Werk auf yes (sshd_config(5)).

In dieselbe Datei passen beliebig viele öffentliche Schlüssel, einer je Zeile. So bekommen mehrere Personen oder mehrere Geräte Zugang zum selben Konto, und einer davon lässt sich entziehen, ohne die anderen anzufassen.

Welcher Schlüsseltyp: Ed25519, RSA, ECDSA

Ältere Anleitungen stellen vier Typen nebeneinander, als wäre die Wahl Geschmackssache. Sie ist es nicht mehr. Von den vieren sind heute zwei eine ernsthafte Option, einer überflüssig und einer verschwunden.

Ed25519 ist die Voreinstellung. Rufst du ssh-keygen ohne -t auf, entsteht seit OpenSSH 9.5 vom 4. Oktober 2023 ein Ed25519-Schlüssel (OpenSSH-Release-Notes). Die Schlüssellänge liegt fest, -b hat hier keine Wirkung. Der öffentliche Schlüssel passt in eine kurze Zeile, was das Einfügen in authorized_keys spürbar erleichtert. Unterstützt wird der Typ seit OpenSSH 6.5 vom Januar 2014.

RSA ist der Ausweg für alte Gegenstellen. Ohne -b erzeugt ssh-keygen 3072 Bit, das Minimum liegt bei 1024 Bit (ssh-keygen(1)). Problematisch ist nicht der Schlüssel, sondern das Signaturverfahren: OpenSSH 8.8 vom 26. September 2021 hat RSA-Signaturen mit SHA-1 abgeschaltet, weil SHA-1 als gebrochen gilt. Bestehende RSA-Schlüssel laufen weiter, sofern beide Seiten RSA/SHA-256 oder RSA/SHA-512 beherrschen.

ECDSA funktioniert, bringt gegenüber Ed25519 aber keinen Vorteil und hängt an den NIST-Kurven. Neu damit anzufangen, lohnt nicht.

DSA ist weg. OpenSSH hatte DSA-Schlüssel bereits 2015 standardmäßig abgeschaltet, mit Version 9.9 vom 19. September 2024 aus dem Standard-Build genommen und mit Version 10.0 vom 9. April 2025 vollständig entfernt. Debian 13 „Trixie“ liefert OpenSSH 10.0 aus (openssh-client 1:10.0p1). Dort existiert DSA also nicht einmal mehr als Option. Wer irgendwo -t dsa liest, liest eine Anleitung, die älter ist, als ihr Datum vermuten lässt.

Voraussetzungen zur Erstellung eines SSH-Keys

Viel ist nicht nötig. Auf Linux und macOS ist alles schon installiert, unter Windows seit einigen Jahren ebenfalls. Die einzige Angabe, die wirklich etwas entscheidet, ist die OpenSSH-Version auf beiden Seiten der Verbindung.

Software und Tools

Auf Linux und macOS gehört OpenSSH zur Grundausstattung, ssh-keygen liegt im Pfad. Unter Windows ist ein OpenSSH-Client seit Windows 10 Build 1809 dabei; er liegt in C:\Windows\System32\OpenSSH und lässt sich in PowerShell genauso aufrufen wie ein Terminal unter Linux (Microsoft-Dokumentation). Damit ist die Werkzeugfrage für die meisten erledigt.

Zwei Alternativen unter Windows bleiben trotzdem verbreitet:

• PuTTY mit dem Hilfsprogramm PuTTYgen, aktuell Version 0.85 vom 16. August 2026 (Download-Seite). PuTTY speichert Schlüssel im eigenen Format mit der Endung .ppk. Für einen OpenSSH-Server muss der Schlüssel deshalb aus PuTTYgen heraus in das OpenSSH-Format exportiert werden.

• Git Bash, das mit Git für Windows kommt und eine vollständige OpenSSH-Umgebung mitbringt.

Wer den eingebauten Client hat, braucht keines von beiden. Ein zusätzliches Werkzeug löst hier kein Problem, das nicht ohnehin gelöst wäre.

Welche OpenSSH-Version läuft bei dir?

Die Version bestimmt, welche Schlüsseltypen überhaupt zur Verfügung stehen und welchen Typ ssh-keygen ohne weitere Angabe erzeugt. Ein Befehl beantwortet das:

ssh -V

Debian 12 „Bookworm“ liefert OpenSSH 9.2, Debian 13 „Trixie“ OpenSSH 10.0. Der Unterschied ist keine Kosmetik: Unter 9.2 erzeugt ssh-keygen ohne -t noch einen RSA-Schlüssel, unter 10.0 einen Ed25519-Schlüssel. DSA gibt es dort gar nicht mehr. Ed25519 selbst kennt OpenSSH seit 2014. An der Gegenstelle scheitert es also nur bei wirklich alten Systemen, und für die bleibt RSA.

Schreibrechte im eigenen Home-Verzeichnis genügen. Wer ssh-keygen aufruft, braucht weder Root noch ein zusätzliches Paket.

Schritt-für-Schritt-Anleitung zur Erstellung eines SSH-Keys

Ein Befehl, zwei Rückfragen, fertig. Der Rest dieses Abschnitts erklärt, was dabei gefragt wird und warum die Antworten später wichtig werden.

Generierung des Schlüsselpaares

Das Programm heißt ssh-keygen und gehört zu OpenSSH. Für einen neuen Schlüssel reicht eine Zeile im Terminal:

ssh-keygen -t ed25519 -C "deine_email@example.com"

-t wählt den Typ. -C hängt einen Kommentar an den öffentlichen Schlüssel, üblicherweise eine Mailadresse oder benutzer@rechner. Der Kommentar steht später hinter jeder Zeile in authorized_keys und ist die einzige Hilfe, wenn du in zwei Jahren entscheiden musst, welcher Eintrag noch gebraucht wird. Seit OpenSSH 9.5 könntest du -t ed25519 auch weglassen. Ausgeschrieben ist im Terminal-Verlauf nachvollziehbar, was tatsächlich passiert ist.

Nur wenn die Gegenstelle kein Ed25519 versteht, ist RSA die Alternative. Dann kommt -b hinzu:

ssh-keygen -t rsa -b 4096 -C "deine_email@example.com"

-b setzt die Schlüssellänge in Bit. Ohne Angabe wären es 3072; 4096 ist die Länge, die GitHub für ältere Systeme nennt. Bei Ed25519 bleibt -b wirkungslos, dort steht die Länge fest.

Nach dem Aufruf fragt das Programm nach einem Speicherort. Voreingestellt ist ~/.ssh/, der Dateiname ergibt sich aus dem Typ: id_ed25519 und id_ed25519.pub, bei RSA id_rsa und id_rsa.pub. Enter übernimmt den Vorschlag. Liegt dort schon ein Schlüssel desselben Typs, fragt ssh-keygen nach, und ein unbedachtes „y“ überschreibt ihn. Das Gegenstück auf allen Servern ist damit wertlos, ohne Warnung und ohne Weg zurück.

Auswahl des Speicherorts und der Passphrase

Dann kommt die Frage nach einer Passphrase, zweimal. Sie verschlüsselt die private Schlüsseldatei auf der Festplatte. Ohne sie ist der Schlüssel eine Datei, die sich kopieren lässt: aus jedem Backup, aus jedem Sync-Ordner, von jedem, der Lesezugriff auf dein Home-Verzeichnis bekommt.

Enter ohne Eingabe erzeugt einen Schlüssel ohne Passphrase. Das ist kein Fehler, sondern eine Entscheidung. Für ein Backup-Skript, das nachts allein läuft, gibt es keine andere Möglichkeit. Solche Schlüssel gehören dafür in authorized_keys mit restrict und command= eingeschränkt, damit sie nur ihren einen Zweck erfüllen. Für den Schlüssel, mit dem du selbst arbeitest, ist die Passphrase Pflicht. Mit ssh-agent tippst du sie einmal je Sitzung statt bei jeder Verbindung.

Am Ende liegen zwei Dateien im Verzeichnis: der private Schlüssel id_ed25519 ohne Endung und der öffentliche id_ed25519.pub. Die .pub-Datei ist die, die weitergegeben wird. Die andere verlässt den Rechner nie, auch nicht „nur kurz“ per Mail an dich selbst.

Überprüfung der Schlüsselerstellung

Ob der Schlüssel entstanden ist, zeigt ein Blick in die öffentliche Datei:

cat ~/.ssh/id_ed25519.pub

Die Ausgabe ist eine einzige Zeile aus drei Teilen: Typ, Schlüssel, Kommentar. Beginnt sie mit ssh-ed25519, stimmt der Typ. Genau diese Zeile kommt später auf den Server, vollständig und ohne eingefügten Zeilenumbruch.

Den Fingerabdruck nennt ssh-keygen -l -f ~/.ssh/id_ed25519.pub. Das ist der Wert, mit dem du später vergleichst, welcher Schlüssel auf einem Server tatsächlich hinterlegt ist.

Verwendung und Verwaltung von SSH-Keys

Der Schlüssel allein bewirkt nichts. Er muss auf den Server, und ab dem zweiten Server braucht es Ordnung in ~/.ssh/.

Hinzufügen des öffentlichen Schlüssels zu Servern

Der öffentliche Schlüssel muss in die Datei ~/.ssh/authorized_keys des Kontos, mit dem du dich anmelden willst. Von Hand geht das in vier Schritten. Der kürzere Weg mit ssh-copy-id steht weiter unten und macht am Ende genau dasselbe. Wer einmal gesehen hat, was dabei passiert, kann anschließend beruhigt abkürzen.

• Zugang prüfen: Du musst überhaupt auf den Server kommen, per Passwort oder über einen bereits hinterlegten Schlüssel. Ohne bestehenden Zugang hilft nur die Konsole des Anbieters.

• Öffentlichen Schlüssel anzeigen:

cat ~/.ssh/id_ed25519.pub

Kopiere die gesamte Zeile.

• Auf dem Server anmelden:

ssh benutzername@server_ip_adresse

• Schlüssel eintragen: Hänge die Zeile an ~/.ssh/authorized_keys an. Zwei Größerzeichen, nicht eines: ein einzelnes > überschreibt die Datei und wirft alle bereits eingetragenen Schlüssel weg.

echo "dein_öffentlicher_schlüssel" >> ~/.ssh/authorized_keys

Alternativ öffnest du die Datei mit nano oder vim und fügst die Zeile von Hand ein.

• Rechte setzen: sshd prüft die Rechte und ignoriert den Schlüssel, wenn sie zu weit stehen. Das ist die häufigste Ursache dafür, dass ein frisch eingetragener Schlüssel „einfach nicht funktioniert“: Der Client fragt wieder nach dem Passwort, und im Serverlog unter /var/log/auth.log steht ein Hinweis auf bad ownership or modes. Das Verzeichnis gehört auf 700, die Datei auf 600:

chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys

Jetzt der Test — und zwar bevor du dich darauf verlässt. Öffne eine zweite Sitzung, ohne die erste zu schließen. Scheitert die Anmeldung, bist du noch drin und kannst nachbessern.

ssh -v benutzername@server zeigt in der Ausgabe, welchen Schlüssel der Client anbietet und ob der Server ihn annimmt. Die Zeile Authentications that can continue: publickey und ein anschließendes Authenticated to … using „publickey“ sind der Beleg. Erst danach lohnt es sich, über PasswordAuthentication no nachzudenken.

Öffentlichen Schlüssel auf den Server kopieren

All das ist nicht nötig. ssh-copy-id erledigt dieselben Schritte in einem Aufruf:

ssh-copy-id benutzername@serveradresse

Das Programm meldet sich mit dem an, was gerade funktioniert, legt ~/.ssh und authorized_keys an, falls sie fehlen, und hängt den Schlüssel an. Vorher prüft es, welche deiner Schlüssel dort schon eingetragen sind, und überträgt nur die fehlenden (ssh-copy-id(1)).

Ohne -i nimmt es die jüngste Datei, auf die ~/.ssh/id*.pub passt. Bei mehreren Schlüsseln ist das Raten. Gib den gewünschten deshalb an:

ssh-copy-id -i ~/.ssh/id_ed25519.pub benutzername@serveradresse

Verwaltung mehrerer SSH-Keys

Ab dem zweiten Server lohnt sich die Datei ~/.ssh/config. Sie spart Tipparbeit und legt fest, welcher Schlüssel zu welchem Host gehört. Ohne diese Zuordnung bietet der Client der Reihe nach alles an, was er hat, und der Server zählt jeden angebotenen Schlüssel als Fehlversuch. Nach MaxAuthTries, voreingestellt sechs, trennt er die Verbindung (sshd_config(5)). Wer viele Schlüssel im Agenten hat, kommt dann auf Servern nicht mehr an, auf denen er eigentlich eingetragen ist.

• Sprechende Dateinamen: id_ed25519_backup sagt mehr als id_ed25519_2. Der Name ist das Einzige, woran später noch zu erkennen ist, wofür der Schlüssel gedacht war.

• Ein Eintrag je Host: Neben IdentityFile gehören abweichender Benutzername und Port hinein, statt sie jedes Mal auf der Kommandozeile mitzuschleppen.

Host server1
    HostName server1.example.com
    User benutzername
    IdentityFile ~/.ssh/id_ed25519_projekt1
    IdentitiesOnly yes
    Port 2222
Host server2
    HostName server2.example.com
    User benutzername
    IdentityFile ~/.ssh/id_ed25519_projekt2
    IdentitiesOnly yes
    Port 4321

Damit genügt ssh server1. Die Zeile IdentitiesOnly yes ist dabei kein Beiwerk: Ohne sie bietet der Client trotz IdentityFile erst alles an, was der Agent kennt, und läuft in dasselbe MaxAuthTries-Limit wie vorher.

Der zweite Teil der Pflege ist das Aufräumen. Ein Schlüssel, der nicht mehr gebraucht wird, muss aus authorized_keys heraus, nicht bloß lokal gelöscht werden. Lokal löschen nimmt dir den Zugang. Der Eintrag auf dem Server bleibt und gilt weiter für jeden, der die Datei doch noch irgendwo liegen hat.

Sicherheitstipps für den Umgang mit SSH-Keys

Der Schlüssel ist erzeugt und liegt auf dem Server. Was bleibt, sind vier Stellen, an denen in der Praxis tatsächlich etwas schiefgeht.

Verwendung starker Passphrasen

Eine Passphrase ist kein Passwort für einen Dienst, sondern der Schutz einer Datei, die ein Angreifer in Ruhe offline durchprobieren kann. Deshalb zählt hier Länge mehr als Zeichenvielfalt. Vier bis sechs zufällige Wörter, wie sie ein Passwortmanager oder eine Diceware-Liste liefert, sind leichter zu merken und schwerer zu knacken als „M3inH0nd!st$üß“. Solche Zeichenersetzungen stehen seit Jahren in jeder Wörterbuchattacke.

Gegen das Durchprobieren hilft zusätzlich das Dateiformat. Seit OpenSSH 7.8 vom 24. August 2018 schreibt ssh-keygen private Schlüssel im eigenen OpenSSH-Format statt im PEM-Format von OpenSSL, ausdrücklich wegen des besseren Schutzes gegen Offline-Rateangriffe. Die Zahl der Ableitungsrunden setzt -a, voreingestellt sind 16 (ssh-keygen(1)). Ein höherer Wert macht jeden einzelnen Rateversuch teurer:

ssh-keygen -t ed25519 -a 100 -C "deine_email@example.com"

Die Passphrase gehört in den Passwortmanager. Nicht auf einen Zettel neben den Rechner und erst recht nicht in eine Datei neben den Schlüssel.

Regelmäßige Schlüsselrotation

Für feste Rotationsintervalle gibt es in der OpenSSH-Dokumentation keine Empfehlung. Die oft genannten sechs bis zwölf Monate sind eine Konvention, kein belegter Wert, und ein Schlüssel wird durch Alter allein nicht schwächer. Sicher sagen lässt sich dagegen, wann er sofort ersetzt gehört:

• Das Gerät mit dem privaten Schlüssel ist verloren, gestohlen oder kompromittiert.

• Der Schlüssel lag ohne Passphrase in einem Backup, das jemand anders in der Hand hatte.

• Jemand verlässt das Team, das Projekt oder die Firma.

Der Ablauf ist in allen drei Fällen derselbe: neuen Schlüssel erzeugen, hinterlegen, testen, und erst danach die alte Zeile aus authorized_keys löschen. Diese Reihenfolge ist nicht verhandelbar. Wer zuerst löscht und dann feststellt, dass der neue Schlüssel nicht greift, steht vor einem Server, auf den er nicht mehr kommt.

Welche Zeile welche ist, verrät der Fingerabdruck. ssh-keygen -lf ~/.ssh/authorized_keys listet ihn für jeden Eintrag der Datei, samt Kommentar. Der Abgleich mit ssh-keygen -lf ~/.ssh/id_ed25519.pub zeigt, welche Zeile deine eigene ist.

Einschränkung des Zugriffs

Der private Schlüssel gehört dir allein: chmod 600 ~/.ssh/id_ed25519. OpenSSH prüft das bei jedem Verbindungsaufbau und verweigert die Datei mit der Warnung „UNPROTECTED PRIVATE KEY FILE“, sobald andere sie lesen können. Auf der Serverseite prüft sshd dasselbe für ~/.ssh und authorized_keys; StrictModes yes ist die Voreinstellung und lässt Schlüssel aus Verzeichnissen, die für andere schreibbar sind, nicht zu.

Der wirksamere Hebel steht in der Zeile selbst. Vor jedem Schlüssel in authorized_keys dürfen Optionen stehen. restrict schaltet Port-Weiterleitung, Agent-Weiterleitung, X11 und Terminal auf einen Schlag ab, command=„…“ bindet den Schlüssel an genau einen Befehl, from=„…“ an eine Herkunftsadresse. Für einen Automatisierungsschlüssel ist das die eigentliche Absicherung. Die Passphrase kann er ja gerade nicht haben.

Aktuell halten hilft ebenfalls, kostet aber nichts als Aufmerksamkeit: Sicherheitsupdates für OpenSSH kommen über die normale Paketverwaltung. Welche Befehle dabei Root-Rechte brauchen und wie du sie richtig absetzt, steht in Sudo auf Debian installieren und nutzen.

Backup deiner SSH-Keys

Ein privater Schlüssel ohne Backup ist ein Zugang, den ein Festplattendefekt beendet. Ein privater Schlüssel im falschen Backup ist ein Zugang für andere. Beides lässt sich zusammen lösen: sichern, aber nur mit gesetzter Passphrase, und nur dorthin, wo auch sonst Geheimnisse liegen — ein verschlüsselter Datenträger oder der Passwortmanager, nicht der Sync-Ordner, der nebenbei auf drei Geräten liegt.

Die bessere Alternative ist oft der zweite Schlüssel. Zwei Schlüssel auf zwei Geräten, beide in authorized_keys eingetragen: Dann kostet ein verlorenes Gerät nur einen gelöschten Eintrag statt des Zugangs. Für den öffentlichen Teil braucht es ohnehin kein Backup, er lässt sich jederzeit aus dem privaten zurückgewinnen:

ssh-keygen -y -f ~/.ssh/id_ed25519 > ~/.ssh/id_ed25519.pub

Fazit

Der kurze Weg besteht aus vier Schritten: ssh-keygen -t ed25519, Passphrase setzen, ssh-copy-id, in einer zweiten Sitzung testen. Alles Übrige in diesem Artikel sind Antworten auf die Fragen, die dabei auftauchen: welcher Typ, welche Rechte, wie das mit mehreren Servern zusammengeht.

Drei Dinge lohnen sich zu merken. Ed25519 ist seit OpenSSH 9.5 die Voreinstellung und DSA seit 10.0 vollständig entfernt; eine Anleitung, die mit -t dsa oder mit RSA als erster Wahl anfängt, ist älter, als ihr Datum vermuten lässt. Die Rechte auf ~/.ssh sind die häufigste Ursache für einen Schlüssel, der scheinbar nicht funktioniert. Und die alte Sitzung bleibt offen, bis die neue nachweislich steht.

Steht der Zugang, ist der nächste Schritt meist, den Server enger zu machen: Genutzte Ports in Linux anzeigen zeigt, was überhaupt nach außen lauscht, und Iptables nach Neustart wiederherstellen sorgt dafür, dass die Firewall einen Neustart übersteht.

Zum Weiterlesen an der Quelle: die Handbuchseite ssh-keygen(1), die OpenSSH-Release-Notes für die Frage, was wann entfernt wurde, die GitHub-Dokumentation für den Weg zum eigenen Repository und eine Kurzanleitung bei heise.de.