SSH-Schlüssel erklärt
Die SSH-Schlüsselauthentifizierung ist der Weg, sich ohne Passwort bei einem Server anzumelden: Statt ein Geheimnis einzugeben, das der Server prüfen kann, beweist Ihr Rechner den Besitz eines privaten Schlüssels, indem er eine Herausforderung signiert, die der Server sendet, und der Server prüft die Signatur anhand des öffentlichen Schlüssels, den er bereits archiviert hat. Der private Schlüssel überquert nie das Netzwerk, also gibt es nichts abzufangen, nichts zu phishen und nichts zu raten. Dieser Artikel erklärt, wie die beiden Hälften eines Schlüsselpaars funktionieren, welcher Schlüsseltyp im Jahr 2026 zu wählen ist, wie Fingerabdrücke bei der ersten Verbindung einen Mittelsmann stoppen, wie man authorized_keys und known_hosts sauber hält und genau was zu tun ist, wenn ein Schlüssel durchsickert. Um einen Schlüssel im Browser zu erzeugen, zu prüfen oder zu konvertieren, verwenden Sie die SSH-Key-Suite, und um die Passwörter zu prüfen, die Sie noch verwenden, die Passwort-Leak-Prüfung.
Was SSH-Schlüsselauthentifizierung ist
Jede Anmeldung ist eine Frage, die der Server stellt — sind Sie, wer Sie behaupten zu sein? — und ein Passwort beantwortet sie, indem es das Geheimnis selbst übergibt. Das ist die Schwäche der ganzen Anordnung: Das Geheimnis reist, es kann belauscht werden, es kann wiedergegeben werden, und es kann erraten werden, Versuch für Versuch, bis es fällt. Die SSH-Schlüsselauthentifizierung ändert die Antwort. Statt das Geheimnis zu senden, signiert Ihr Rechner eine zufällige Herausforderung des Servers mit einem privaten Schlüssel, der Ihren Rechner nie verlässt, und der Server prüft die Signatur anhand des öffentlichen Schlüssels, der in Ihrer authorized_keys-Datei gespeichert ist. Der Beweis ist jedes Mal frisch, weil die Herausforderung zufällig ist; das Geheimnis erscheint nie auf der Leitung, also lernt ein Lauscher nichts, was er wiederverwenden könnte, und es gibt kein Passwort zu raten, weil überhaupt kein Passwort im Spiel ist.
Die Idee ist älter als das moderne Internet — die Public-Key-Kryptografie stammt aus den 1970er-Jahren — aber SSH machte sie zum alltäglichen Weg, einen Server zu erreichen, und das Protokoll trägt sie seither. Wenn Sie ssh benutzer@server ausführen, vereinbaren Client und Server eine Sitzung, der Server stellt eine Herausforderung, die an Ihr Konto gebunden ist, und Ihr SSH-Agent signiert sie mit dem privaten Schlüssel, normalerweise nachdem Sie den Schlüssel einmal mit einer Passphrase entsperrt haben. Wenn die Signatur verifiziert wird, sind Sie drin. Nichts an dem Austausch hängt von einem gemeinsamen Geheimnis ab, das auch der Server kennt, und darum legt ein Einbruch in den Server Ihre Zugangsdaten nicht offen: Der Server besitzt nur öffentliche Schlüssel, und ein öffentlicher Schlüssel ist zum Anmelden nutzlos. Diese Asymmetrie — der Server kann verifizieren, aber nicht impersonieren — ist das gesamte Sicherheitsargument für Schlüssel, und sie ist auch der Grund, warum der Verlust der Kontrolle über die private Hälfte der eine Fehler ist, der zählt.
Der öffentliche Schlüssel und der private Schlüssel
Ein Schlüsselpaar besteht aus zwei Hälften mit entgegengesetzten Regeln, und die meisten SSH-Fehler entstehen dadurch, dass man sie gleich behandelt. Der öffentliche Schlüssel ist dazu da, überallhin kopiert zu werden: Fügen Sie ihn in authorized_keys auf jedem Server ein, den Sie nutzen, in Ihr Git-Hosting-Konto, in jeden Dienst, der SSH-Schlüssel akzeptiert. Er kann in einem öffentlichen Repository veröffentlicht, auf eine Folie gedruckt oder einem Administrator gemailt werden, weil er jedem nur erlaubt, eine Signatur zu prüfen. Die Kenntnis Ihres öffentlichen Schlüssels gibt einem Angreifer nichts zum Anmelden, so wie die Kenntnis Ihrer Hausnummer niemandem Ihren Haustürschlüssel gibt. Die öffentliche Hälfte ist ein Schloss, kein Schlüssel, und Schlösser sind dazu da, gesehen zu werden.
Der private Schlüssel ist der Schlüssel selbst, und seine Regel ist genau das Gegenteil: Er verlässt Ihren Rechner nie, nur Sie können ihn lesen, und er darf niemals in einen Chat, ein Ticket, eine E-Mail, einen Forenbeitrag oder ein geteiltes Dokument eingefügt werden — nicht einmal, um zu fragen, ob er sicher ist. Wer ihn besitzt, kann sich als Sie anmelden, auf jedem Server, der dem passenden öffentlichen Schlüssel vertraut, ohne Passwortabfrage und ohne zweiten Faktor im Weg, es sei denn, Sie haben einen konfiguriert. Auf der Platte lebt er in ~/.ssh, geschützt durch Dateiberechtigungen — chmod 600, nur der Eigentümer darf lesen und schreiben — und idealerweise durch eine Passphrase, die die Datei verschlüsselt, sodass eine gestohlene Kopie ohne die Worte, die sie entsperren, weiterhin nutzlos ist. Die Passphrase ist kein Teil des Schlüssels; sie ist ein Vorhängeschloss an der Schachtel, in der der Schlüssel liegt. Verlieren Sie die Schachtel, ist das Schloss das Einzige, das zwischen dem Dieb und Ihren Servern steht, und darum darf ein privater Schlüssel ohne Passphrase niemals einen Rechner verlassen, den Sie vollständig kontrollieren.
Ed25519 vs. ECDSA vs. RSA: welcher Typ im Jahr 2026 zu wählen ist
Im Jahr 2026 lautet die Standardantwort Ed25519, und sie ist auch die Standardeinstellung, die diese Seite erzeugt. Ed25519 ist ein 256-Bit-Schlüssel auf elliptischen Kurven: Er wird in einem Bruchteil einer Sekunde erzeugt, signiert schnell und erzeugt einen öffentlichen Schlüssel, der in eine einzige kurze Zeile passt. Er wird seit 2014 von OpenSSH und von jedem aktuellen Server und Client unterstützt, und seine Sicherheit beruht auf einer Kurve, die offen entworfen wurde, ohne verdächtige Konstanten. Es gibt keinen praktischen Grund, für einen neuen Schlüssel etwas anderes zu wählen, es sei denn, etwas in Ihrer Umgebung zwingt Sie dazu. Wenn Sie eine einzige Empfehlung aus diesem Artikel mitnehmen, dann diese: Erzeugen Sie Ed25519, setzen Sie eine Passphrase und machen Sie weiter.
Die anderen Typen existieren für die Ausnahmen. ECDSA auf den NIST-Kurven P-256 oder P-384 ist die richtige Wahl, wo Richtlinien NIST-Kurven verlangen — manche regulierten Umgebungen und ältere Hardware-Token schreiben sie vor — und sie ist eine gute Alternative, wenn ein Browser oder Gerät Ed25519 nicht erzeugen kann. RSA bleibt die universelle Alternative: RSA 2048 ist das Minimum, das sich lohnt, RSA 3072 oder 4096 die Wahl, wenn die Gegenseite überhaupt keine elliptischen Kurven kann, was heute vor allem sehr alte Systeme und einige eingebettete Geräte bedeutet. Alles unter RSA 2048 — RSA 1024, DSA, ssh-dss — ist Altlast und sollte ausgemustert werden: Die SSH-Key-Suite markiert es aus genau diesem Grund als schwach. Die Schlüsselgröße ist jedoch nicht alles: Ein 4096-Bit-RSA-Schlüssel, der auf einen Laptop kopiert wurde, den Sie nicht mehr besitzen, ist schlimmer als ein ordentlich aufbewahrter 256-Bit-Ed25519-Schlüssel, weil der Fehlermodus von SSH-Schlüsseln fast nie die Mathematik ist. Es ist die Datei.
Fingerabdrücke und die erste Verbindung
Beim ersten Verbindungsaufbau mit einem Server zeigt SSH Ihnen etwas, das wie eine zufällige Zeichenfolge aussieht, und fragt, ob Sie ihr vertrauen: 256 SHA256:M8zvXkwyrGfPUmaHSSdA1aFQkH8AVSRycOxaZHru7dQ. Diese Zeichenkette ist der Fingerabdruck des Hostschlüssels des Servers — ein Hash des öffentlichen Schlüssels des Servers — und sie ist das Einzige, das zwischen Ihnen und einem Mittelsmann steht. Wenn der Fingerabdruck mit dem übereinstimmt, den Ihr Administrator veröffentlicht hat, oder mit dem, den Sie über einen separaten Kanal verifiziert haben, dann ist die antwortende Maschine wirklich der Server, den Sie erreichen wollten. Wenn er nicht übereinstimmt, stoppen Sie: Jemand könnte die Verbindung abfangen, oder der Server könnte mit einem neuen Schlüssel neu aufgebaut worden sein, und in jedem Fall ist der sichere Schritt, vor dem Tippen von yes zu prüfen. Diese Aufforderung ist SSH bei seiner wichtigsten Aufgabe, und die Menschen, die in Schwierigkeiten geraten, sind diejenigen, die sich antrainieren, yes zu tippen, ohne sie zu lesen.
Sie können einen Fingerabdruck prüfen, bevor Sie sich je verbinden, mit ssh-keygen -lf, das eine Zeile pro Schlüssel ausgibt: die Bitgröße, den Fingerabdruck, den Kommentar und den Schlüsseltyp in Klammern, zum Beispiel 256 SHA256:… [email protected] (ED25519). Die SSH-Key-Suite druckt Fingerabdrücke in exakt diesem Format, sodass ein Wert, den Sie im Browser sehen, Zeichen für Zeichen mit dem verglichen werden kann, was der Server zeigt. Sobald Sie einen Hostschlüssel akzeptieren, speichert SSH ihn in ~/.ssh/known_hosts und warnt Sie laut — und verweigert die Verbindung —, wenn er sich je ändert. Diese Warnung ist keine Belästigung, die man mit einem Flag umgeht; es ist der Alarm, der losgeht. Die eine Routine-Ausnahme ist ein Server, der legitimerweise neu aufgebaut wurde; in diesem Fall hätte der Administrator den neuen Fingerabdruck im Voraus veröffentlichen sollen, und Sie entfernen den alten Eintrag mit ssh-keygen -R hostname, bevor Sie sich erneut verbinden.
authorized_keys-Hygiene und known_hosts
Jede Zeile in der authorized_keys-Datei eines Servers ist eine Tür, und Türen bleiben lange offen, nachdem die Person, die sie brauchte, gegangen ist. Der Laptop eines Auftragnehmers, ein Continuous-Integration-Job, ein Schlüssel, der auf einer inzwischen gelöschten Maschine erzeugt wurde, ein Kollege, der vor zwei Jahren das Team gewechselt hat — jede davon ist eine Zeile, die noch funktioniert, und jede davon ist eine Zugangsdaten, die Sie nicht mehr beobachten. Die Prüfung ist einfach und alle paar Monate wert: Kopieren Sie die Datei, fügen Sie sie in den Tab „Prüfen“ der SSH-Key-Suite ein und sehen Sie sich an, was zurückkommt. Duplikate — derselbe öffentliche Schlüssel zweimal — bedeuten, dass jemand einen Schlüssel erneut eingefügt hat, statt zu prüfen, und sollten auf eine Zeile zusammengeführt werden. Schwache Einträge — RSA unter 2048, DSA, ssh-dss — sollten entfernt und ersetzt werden. Und jede Zeile, deren Kommentar eine Person, eine Maschine oder einen Zweck nennt, den Sie nicht mehr erkennen, sollte als eine Tür behandelt werden, die zu schließen ist, bis ihr Eigentümer sie beanspruchen kann.
known_hosts verdient dieselbe Aufmerksamkeit von der anderen Seite. Es zeichnet den Hostschlüssel jedes Servers auf, mit dem Sie sich verbunden haben, und SSH prüft jede neue Verbindung daran. Manche Einträge sind gehasht — |1| gefolgt von Base64 — was den Hostnamen verbirgt, eine Datenschutzfunktion für Laptops, die verloren gehen oder inspiziert werden könnten; die SSH-Key-Suite meldet diese Einträge als gehasht, statt so zu tun, als seien sie lesbar, weil ein gehashter Eintrag nicht gegen einen veröffentlichten Fingerabdruck verifiziert werden kann, sondern nur als bereits akzeptiert vertraut wird. Die Datei selbst ist auch ein Beweis: Ein known_hosts voller Server, die Sie nicht mehr nutzen, ist eine Karte, wo Ihre Zugangsdaten gewesen sind, und sie zu beschneiden kostet nichts. Zusammen sind die beiden Dateien die vollständige Aufzeichnung Ihres SSH-Vertrauens in beide Richtungen — wer sich als Sie anmelden darf, und welchen Maschinen Sie vertrauen, sie selbst zu sein — und beide verrotten leise, wenn niemand hinsieht.
Wenn ein Schlüssel durchsickert — und die Passphrasen-Anmerkung
Ein durchgesickerter Schlüssel ist kein Rätsel, das man erst untersucht und dann handelt; er ist ein Schlüssel, der ersetzt werden muss, und die Reihenfolge der Schritte ist kurz. Erzeugen Sie ein neues Schlüsselpaar. Entfernen Sie den alten öffentlichen Schlüssel aus authorized_keys auf jedem Server und jedem Dienst — Ihren Servern, Ihrem Git-Hosting, Ihren Deployment-Pipelines, überall, wo der Schlüssel installiert wurde. Prüfen Sie dann, was der alte Schlüssel erreichen konnte, und suchen Sie nach allem, was nicht an seinem Platz ist: neue authorized_keys-Zeilen, die Sie nicht hinzugefügt haben, Anmeldungen zu Stunden, zu denen Sie nicht gearbeitet haben, unbekannte Prozesse. Wenn Sie etwas finden, behandeln Sie es als Einbruch, nicht als Schrecken, und untersuchen Sie von dort aus weiter. Was Sie nicht tun dürfen, ist, den alten privaten Schlüssel von Ihrem Laptop zu löschen und die Arbeit für erledigt zu halten: Das Löschen Ihrer Kopie bewirkt nichts gegen die Kopien, die durchgesickert sind, und der öffentliche Schlüssel, der noch in authorized_keys sitzt, ist immer noch eine funktionierende Tür.
Eine Passphrase ändert diese Checkliste nicht, aber sie ändert, wie dringend Sie sie abarbeiten. Ein passphrasengeschützter Schlüssel, der als Datei durchsickert, ist weiterhin ein Problem — ein Angreifer kann versuchen, die Passphrase offline mit Maschinengeschwindigkeit zu erraten — aber eine starke Passphrase kauft Ihnen die Zeit, zu rotieren, bevor das Raten gelingt. Ein unverschlüsselter Schlüssel kauft Ihnen überhaupt keine Zeit, und darum ist diese Seite offen darüber, was ihr Generator erzeugt: Version 1 erzeugt unverschlüsselte Schlüssel ohne Passphrasen-Option, weil die bcrypt-KDF von OpenSSH für verschlüsselte private Schlüssel zum Umfang von Version 2 gehört. Wenn Sie hier einen Schlüssel erzeugen, schützen Sie die Datei mit chmod 600 und fügen Sie auf Ihrem eigenen Rechner mit ssh-keygen -p eine Passphrase hinzu — es dauert zehn Sekunden, es konvertiert die Datei an Ort und Stelle, und es ist die wertvollste Gewohnheit in diesem ganzen Artikel. Erzeugen Sie den Schlüssel, setzen Sie die Passphrase, installieren Sie nur die öffentliche Hälfte, prüfen Sie die Dateien zweimal im Jahr und verifizieren Sie jeden Fingerabdruck, bevor Sie ihm vertrauen: Das ist die gesamte Disziplin, und sie passt auf eine Karteikarte.