In einem Satz
SSH-Keys sind ein zusammengehöriges Set aus kryptografischen Dateien – eine private und geheime, eine öffentliche und teilbare – mit denen du deine Identität gegenüber einem Remote-Rechner beweisen kannst, ohne ein Passwort einzutippen.
Welches Problem es löst
In den Anfangstagen des Internets nutzte man für die Verwaltung eines Remote-Servers etwas wie Telnet. Man gab seinen Benutzernamen und sein Passwort ein, und diese flogen im Klartext für jedermann sichtbar durchs Netzwerk. Das war das digitale Äquivalent dazu, seine Bank-PIN durch einen überfüllten Raum zu schreien. Autsch.
Dann kam SSH, die Secure Shell. Sie verschlüsselte die gesamte Kommunikation, was ein monumentaler Fortschritt war. Jetzt konntest du dein Passwort eintippen, und es wurde auf dem Weg zum Server verschlüsselt. Viel besser! Aber Passwörter haben immer noch ihre Tücken. Sie können schwach sein, vergessen, erraten oder mit Brute-Force-Angriffen geknackt werden. Die Verwaltung von Passwörtern für Dutzende von Servern und für ein ganzes Team von Entwicklern wird zu einem Sicherheits- und Logistik-Albtraum. Wer hat worauf Zugriff? Was passiert, wenn jemand das Unternehmen verlässt? Ändert man das Passwort auf 50 Servern und teilt allen das neue mit?
Genau dieses Problem sollen SSH-Keys lösen. Sie ersetzen „etwas, das du weißt“ (ein Passwort) durch „etwas, das du hast“ (einen Private Key). Diese Methode, genannt Public-Key-Authentifizierung, ist drastisch sicherer und wesentlich bequemer für Menschen und automatisierte Systeme. Es ist der Unterschied zwischen einem einzigen, leicht zu stehlenden Generalschlüssel und einer einzigartigen, biometrisch gesicherten Schlüsselkarte für jede Tür, die du öffnen musst.
Wie es unter der Haube funktioniert
Die Magie hinter SSH-Keys ist ein Konzept namens asymmetrische Kryptographie. Im Gegensatz zu einem einfachen Passwort (das ein symmetrisches Geheimnis ist – du und der Server wissen beide dasselbe), besteht ein SSH-Schlüsselpaar aus zwei unterschiedlichen, aber mathematisch miteinander verbundenen Schlüsseln.
Das Public-Private-Key-Paar: Eine einseitige Liebesgeschichte
Stell dir vor, du hast ein magisches Vorhängeschloss und einen einzigen, einzigartigen Schlüssel. Das Vorhängeschloss ist dein Public Key. Du kannst eine Million Kopien dieses Vorhängeschlosses anfertigen und sie jedem geben. Du kannst es auf deiner Website posten, an deine Freunde mailen und auf jeden Server legen, auf den du zugreifen möchtest. Es ist öffentlich; es schadet nicht, wenn es bekannt wird.
Dein Private Key ist der einzige Schlüssel, der genau diese Art von Vorhängeschloss öffnen kann. Du bewachst diesen Schlüssel wie deinen Augapfel. Du behältst ihn auf deinem Computer, teilst ihn niemals und schützt ihn idealerweise mit einer Passphrase.
- Der Private Key kann eine digitale Signatur erstellen.
- Der Public Key kann überprüfen, dass eine Signatur von seinem zugehörigen Private Key erstellt wurde.
Entscheidend ist, dass der Public Key nicht verwendet werden kann, um den Private Key herauszufinden. Die mathematische Beziehung funktioniert nur in eine Richtung, daher „asymmetrisch“.
Der Authentifizierungs-Handshake
Wie spielt sich das also ab, wenn du versuchst, dich einzuloggen? Nehmen wir an, du tippst ssh user@server.com.
- Die Vorstellung: Dein Computer (der Client) klopft an die Tür des Servers. „Hallo, ich möchte mich als
usereinloggen. Ich glaube, mein Public Key ist einer, den du erkennen wirst. Hier ist seine ID.“ - Die Herausforderung: Der Server schaut in die Datei
~/.ssh/authorized_keysdes Benutzersuser. Diese Datei ist einfach eine Liste von Public Keys, die sich als dieser Benutzer einloggen dürfen. Der Server findet einen passenden Public Key. „Ah, ich sehe dein öffentliches Vorhängeschloss! Ich glaube dir, aber ich brauche einen Beweis. Um zu beweisen, dass du den Private Key hast, signiere bitte diese zufällige, einmalige Nachricht, die ich mir gerade ausgedacht habe:R2-D2_is_the_true_hero.“ - Die Signatur: Dein Client empfängt die Herausforderung. Er verwendet deinen Private Key, um eine einzigartige digitale Signatur für genau diese Nachricht zu erstellen. Dann schickt er diese Signatur zurück an den Server. Dein Private Key selbst verlässt niemals, wirklich niemals, deinen Computer.
- Die Verifizierung: Der Server empfängt die Signatur. Er nimmt den Public Key, den er gespeichert hat, und verwendet ihn, um die Signatur mit der ursprünglichen Herausforderungsnachricht zu vergleichen. Da nur dein Private Key diese exakte Signatur für diese exakte Nachricht erzeugen konnte, weiß der Server, dass er mit dir spricht.
- Zugriff gewährt: Die Rechnung geht auf. Der Server sagt: „Die Signatur ist gültig. Willkommen!“ und gewährt dir eine Shell-Sitzung, ohne dass jemals ein Passwort das Netzwerk überquert hat.
Schlüsseltypen: Ein Familienporträt (RSA, ECDSA, Ed25519)
Nicht alle Schlüssel sind gleich. Sie verwenden unterschiedliche mathematische Algorithmen, um die Schlüsselpaare und Signaturen zu erzeugen. Du wirst üblicherweise drei Haupttypen sehen:
| Algorithmus | Kurz & Knapp | Schlüsselgröße (typisch) | Fazit |
|---|---|---|---|
| RSA | Die alte Garde. Basiert auf der Schwierigkeit, riesige Primzahlen zu faktorisieren. | 2048 oder 4096 Bit | Immer noch stark und weit verbreitet, aber langsam und erfordert nach modernen Maßstäben große Schlüssel. |
| ECDSA | Der moderne Standard. Nutzt Elliptische-Kurven-Mathematik, um kleiner und schneller zu sein. | 256 oder 384 Bit | Super Wahl. Ein 256-Bit-ECDSA-Schlüssel bietet ähnliche Sicherheit wie ein 3072-Bit-RSA-Schlüssel. |
| Ed25519 | Der neue heiße Scheiß. Ein spezieller Typ von Elliptic-Curve-Schlüssel, der noch schneller ist. | 256 Bit | Die beste Wahl, falls unterstützt. Schnell, sicher und resistent gegen bestimmte Angriffe. |
Heute ist Ed25519 aufgrund seiner überlegenen Leistung und Sicherheit im Allgemeinen die empfohlene Wahl.
Was ist ein Fingerprint?
Ein Public Key ist eine lange, unschöne Zeichenkette. Nichts, was man sich leicht merken oder vergleichen kann. Ein Fingerprint ist eine kurze, eindeutige Zusammenfassung des Public Keys, die durch eine Hashing-Funktion (wie SHA256) erstellt wird.
SHA256:88+EM65U024w0E7sF2w8w3n98w/L3t8d7f6e5g4h
Er funktioniert wie eine menschenlesbare Seriennummer. Wenn du dich zum allerersten Mal mit einem Server verbindest, zeigt dir SSH den Fingerprint des Server-Public-Keys an und fragt, ob du ihm vertraust. Das ist deine einzige Chance, einen „Man-in-the-Middle“-Angriff zu verhindern, indem du diesen Fingerprint über einen anderen sicheren Kanal verifizierst (z.B. indem du den Sysadmin anrufst und ihn ihm vorliest).
Geschichten aus der Praxis
Das automatisierte Deployment-Skript
Eine DevOps-Ingenieurin, Maya, verwaltete eine Flotte von 20 Webservern. Jedes Mal, wenn sie eine neue Version der Firmen-App bereitstellte, musste sich ihr Skript in jeden Server einloggen, um den neuesten Code zu holen und den Dienst neu zu starten. Ihr erstes Skript fragte sie 20 Mal hintereinander nach dem Serverpasswort, was wahnsinnig langsam war. Ihre nächste Version hatte das Passwort hartcodiert im Skript, was das Auge ihres CISO zucken ließ. Schließlich generierte sie ein einziges, dediziertes SSH-Schlüsselpaar für Deployments. Sie fügte den Public Key zu allen 20 Servern hinzu. Jetzt läuft ihr Skript fehlerfrei und sicher und loggt sich in Sekundenschnelle auf jeder Maschine ein, ohne manuelles Eingreifen.
Lektion: SSH-Keys sind der Grundpfeiler der sicheren, passwortfreien Automatisierung.
Der scheidende Freelancer
Ein kleines Startup engagierte einen Freelancer, David, für ein dreimonatiges Projekt. Um ihm Zugriff auf den Staging-Server zu geben, bat der Tech-Lead, Chen, einfach um Davids öffentlichen SSH-Key und fügte ihn der authorized_keys-Datei des Servers hinzu. David konnte sich nun sicher einloggen und seine Arbeit erledigen. Am Ende des Vertrags bestand Chens gesamter „Offboarding“-Prozess für den Serverzugriff aus einem einzigen Befehl: die authorized_keys-Datei öffnen und die Zeile mit Davids Schlüssel löschen. Der Zugriff war sofort und sauber entzogen, ohne geteilte Passwörter, die man ändern oder sich Sorgen machen müsste.
Lektion: SSH-Keys ermöglichen eine granulare, nachvollziehbare und leicht widerrufbare Zugriffskontrolle auf Pro-Benutzer-Basis.
Der erste GitHub-Push
Ein neuer Entwickler, Sam, trat einem Team bei und klonte deren privates Code-Repository. Nachdem er seine erste Änderung vorgenommen hatte, versuchte er einen git push. Er wurde mit einem „Permission denied“-Fehler konfrontiert. Das Unternehmen hatte, wie viele andere auch, aus Sicherheitsgründen die passwortbasierte Authentifizierung bei GitHub deaktiviert. Das interne Wiki wies ihn an, einen neuen SSH-Key zu generieren und dann in seinen GitHub-Einstellungen den Inhalt seines öffentlichen Schlüssels (id_ed25519.pub) in den Bereich „SSH and GPG keys“ einzufügen. Danach konnte er seinen Code über die SSH-URL des Repositorys (git@github.com:...) pushen. GitHub nutzte exakt denselben Challenge-Response-Mechanismus, um zu überprüfen, ob es wirklich Sam war, der den Code pushte.
Lektion: SSH-Keys sind der Standard für die Authentifizierung bei Diensten, die über den reinen Shell-Zugriff hinausgehen, einschließlich der meisten Code-Hosting-Plattformen.
Häufige Fehler und Fallstricke
- Deinen Private Key teilen. Sende niemals, wirklich niemals, deinen Private Key (
id_ed25519oderid_rsa) an irgendjemanden oder lade ihn irgendwo hoch. Er ist dein Geheimnis. Ihn zu teilen, untergräbt den gesamten Zweck dieses Sicherheitsmodells. - Eine Passphrase vergessen. Dein Private Key ist nur eine Datei auf deiner Festplatte. Wenn dein Laptop gestohlen wird, kann ein Angreifer sie einfach kopieren. Eine starke Passphrase verschlüsselt diese Datei und zwingt den Dieb, sowohl dein Laptop-Passwort als auch die Passphrase deines Keys zu knacken. Das ist eine entscheidende Verteidigungsschicht.
- Den Private Key in ein Public-Key-Feld einfügen. Das ist ein leicht zu machender Fehler. Du richtest einen neuen Dienst ein, er fragt nach deinem Public Key, und du kopierst versehentlich den Inhalt der falschen Datei. Überprüfe immer doppelt, dass der Schlüssel, den du teilst, auf
.pubendet. - Schwache, alte Schlüssel verwenden. Einen 1024-Bit-RSA-Schlüssel in der heutigen Zeit zu generieren, ist eine schlechte Idee. Sie sind potenziell anfällig dafür, von finanzstarken Angreifern geknackt zu werden. Halte dich an moderne Standards: Ed25519 oder zumindest einen 4096-Bit-RSA-Schlüssel.
- Gedankenlos „yes“ tippen. Wenn du dich zum ersten Mal mit einem neuen Host verbindest, warnt dich SSH, dass die Authentizität des Hosts nicht festgestellt werden kann, und zeigt dir seinen Fingerprint. Akzeptiere ihn nicht einfach blind. Das ist der Moment, in dem ein Man-in-the-Middle-Angriff stattfinden kann. Überprüfe den Fingerprint über einen anderen Kanal, wenn du dich in einem nicht vertrauenswürdigen Netzwerk befindest.
Warum du das auf dem Schirm haben solltest
Wenn du Entwickler, Sysadmin, DevOps-Ingenieur oder irgendjemand bist, der sich jemals auf einem Remote-Computer einloggen muss, sind SSH-Keys nicht nur ein „Nice-to-have“ – sie sind fundamental. Sie sind die professionelle, sichere und effiziente Methode, um den Zugriff auf Maschinen zu verwalten.
Du solltest über SSH-Keys nachdenken, wenn:
- du einen neuen Server einrichtest (Cloud oder On-Premise).
- du ein Skript schreibst, das sich mit einer anderen Maschine verbinden muss (
scp,sftp,rsync,git). - du den Zugriff für ein neues Teammitglied einrichtest.
- du dich mit GitHub, GitLab oder Bitbucket verbindest.
- du aufhören willst, Passwörter einzutippen.
Der Umgang mit SSH-Keys ist eine Art Initiationsritus, der dich vom Gelegenheitsnutzer von Remote-Maschinen zu einem kompetenten Operator macht.
Tauche tiefer ein
- RFC 4251: The Secure Shell (SSH) Protocol Architecture - Die offizielle IETF-Spezifikation für das Kernprotokoll von SSH.
- Wikipedia: Secure Shell (SSH) - Ein umfassender Überblick über die Geschichte, Architektur und Anwendung von SSH.
- GitHub Docs: Connecting to GitHub with SSH - Eine praktische Anleitung aus der Praxis von einem der größten Anwender der SSH-Key-Authentifizierung.
- OpenSSH Project Page - Die Homepage der populärsten Implementierung von SSH.
- RFC 8032: Edwards-Curve Digital Signature Algorithm (EdDSA) - Die Spezifikation für die modernen Ed25519- und Ed448-Algorithmen.
- SSH.com: SSH Keys - Eine detaillierte Erklärung von einem der kommerziellen Unternehmen hinter SSH.