SSH Key Management - So geht sichere Schlüsselverwaltung!

Bei der SSH-Schlüsselverwaltung geht es im Kern um ssh key management auf der Ebene von Identitäten, nicht nur um Dateien im ~/.ssh-Verzeichnis. Wer Zugriffe auf Server, Bastions oder Deployments sauber steuern will, braucht eine klare Trennung zwischen Benutzer-, Maschinen- und Host-Schlüsseln. In diesem Artikel ordne ich die wichtigsten Schlüsseltypen, zeige einen sauberen Lebenszyklus und erkläre, welche Werkzeuge in der Praxis wirklich helfen.

Was bei SSH-Schlüsseln eigentlich verwaltet wird

Ich behandle jeden Schlüssel als digitale Identität mit Besitzer, Zweck und Lebensdauer. Der private Schlüssel ist funktional wie ein Passwort: Wer ihn besitzt, kann die Identität übernehmen. Der öffentliche Teil ist nicht geheim, aber ohne saubere Zuordnung nützt er nur dann etwas, wenn klar ist, wer ihn wofür eingesetzt hat.

Im Alltag verwechselt man leicht drei Ebenen, die ich bewusst getrennt halte:

• Benutzerschlüssel steuern den Login eines Menschen oder Dienstkontos.
• Host-Schlüssel bestätigen dem Client, dass er wirklich mit dem erwarteten Server spricht.
• Maschinenschlüssel sind für Automatisierung gedacht und müssen enger begrenzt werden als interaktive Logins.

Die Trennung klingt banal, aber genau daran scheitern viele Umgebungen. Sobald ein Deploy-Key plötzlich auch für Admin-Zugriff, Notfallzugänge und CI genutzt wird, steigt der Schadensradius unnötig. Wenn diese Ebenen sauber auseinanderliegen, wird die eigentliche Strategie viel einfacher zu entscheiden.

Welche Schlüsselstrategie sich in der Praxis bewährt

Für neue menschliche Zugriffe starte ich heute fast immer mit Ed25519. Die aktuellen OpenSSH-Manpages nennen Ed25519 als Standard, wenn ssh-keygen ohne Parameter läuft. RSA nehme ich nur noch, wenn ein älteres Zielsystem nichts anderes akzeptiert; dann aber eher als Kompatibilitätsbrücke und nicht als Erstwahl.

Wenn Kompatibilität ein Problem ist, gehe ich bei RSA eher auf 4096 Bit als auf halbherzige Zwischenlösungen. Wenn keine Legacy-Zwänge bestehen, sind ed25519 oder ein hardwaregebundener Schlüssel mit ed25519-sk für mich die deutlich bessere Ausgangslage. Die Faustregel dahinter ist simpel: ein Schlüssel pro Zweck, nicht ein Schlüssel für alles.

Die Strategie steht damit, aber erst der Lebenszyklus entscheidet, ob sie im Betrieb wirklich trägt.

Wie ein sauberer Lebenszyklus aussieht

Ein gutes Schlüsselsystem scheitert selten an der Kryptografie, sondern an den Übergaben. Ich plane deshalb immer denselben Kreislauf: generieren, schützen, verteilen, nutzen, überprüfen und entziehen. Genau an diesen Punkten gehen in der Praxis die meisten Schwächen hinein.

1. Ich generiere neue Schlüssel mit eindeutigem Kommentar und sauberem Dateinamen, damit Besitzer und Zweck später nachvollziehbar bleiben.
2. Private Schlüssel bekommen eine Passphrase, außer bei eng begrenzten Maschinen-Schlüsseln oder tokengebundenen Schlüsseln.
3. Interaktive Schlüssel lade ich nur bei Bedarf in ssh-agent und setze eine Laufzeit mit ssh-add -t, zum Beispiel 30 Minuten oder für ein Wartungsfenster.
4. Bei sensiblen Logins nutze ich zusätzlich ssh-add -c, damit jeder Einsatz bestätigt werden muss.
5. Öffentliche Schlüssel oder Zertifikate verteile ich nur dort, wo sie wirklich gebraucht werden, und entferne alte Einträge sofort, wenn der Zweck wegfällt.

Bei Zertifikaten wird dieser Ablauf noch sauberer. Mit ssh-keygen -V lässt sich ein Gültigkeitsfenster definieren, und mit TrustedUserCAKeys sowie AuthorizedPrincipalsFile trennst du Vertrauen, Rolle und Identität deutlich besser als mit einzelnen statischen Einträgen. Für den Widerruf nutze ich in OpenSSH eine KRL, damit kompromittierte Schlüssel nicht als Altlasten weiterleben.

Ich halte dabei kurze Gültigkeiten für Zertifikate oft für robuster als dauerhafte Keys, weil sich damit Zugänge von selbst veralten und weniger manuelle Nacharbeit nötig ist. Genau dort entsteht in der Praxis viel Stabilität, ohne dass der Betrieb schwerfälliger wird.

Sobald der Lebenszyklus steht, kommt die eigentliche Zugriffskontrolle auf den Zielsystemen ins Spiel.

Zugriff mit Regeln begrenzen statt nur mit Schlüsseln

Der größte Denkfehler ist, SSH-Zugriff nur über den Schlüssel selbst steuern zu wollen. In der Praxis begrenze ich zusätzlich, von wo ein Schlüssel genutzt werden darf, welcher Befehl ausgeführt werden kann und ob Port- oder Agent-Forwarding überhaupt erlaubt ist.

• from= begrenzt Quelladressen und ist für fixe Netze oder VPN-Bereiche besonders sinnvoll.
• command= erzwingt einen bestimmten Befehl und eignet sich gut für Backup-, Sync- oder Deploy-Konten.
• restrict schaltet riskante Funktionen standardmäßig ab und ist oft die sichere Basis für einfache Zugänge.
• permitopen= erlaubt nur definierte Weiterleitungen, wenn ein Konto Tunnels setzen darf.

Für Rollen und größere Teams ist für mich TrustedUserCAKeys zusammen mit AuthorizedPrincipalsFile der bessere Weg als endlose authorized_keys-Dateien. Der Server vertraut dann einer CA, und die eigentliche Berechtigung steckt in Rollen oder Principals statt in Kopien von Public Keys. Das reduziert Wildwuchs und macht Entzug deutlich einfacher.

Auch Host-Schlüssel gehören dazu. Ich prüfe und inventarisiere sie mit ssh-keyscan, statt sie manuell abzutippen. Wenn Hosts Zertifikate verwenden, kann ssh-keyscan -c auch diese Seite des Vertrauens sauber mit abbilden. So entsteht eine belastbare Vertrauenskette auf beiden Seiten der Verbindung.

Wenn die Regeln gesetzt sind, lohnt sich der Blick auf das Werkzeugset, das Betrieb und Audit wirklich erleichtert.

Welche Werkzeuge den Betrieb wirklich vereinfachen

Ich würde die Tool-Landschaft nicht größer machen als nötig. Für die meisten Umgebungen reichen drei OpenSSH-Bausteine plus ein zentrales Inventar oder eine PAM-Plattform: ssh-keygen für Erzeugung, Fingerprints, Zertifikate und Revocation Lists; ssh-agent und ssh-add für kontrollierte Nutzung; ssh-keyscan für Host-Schlüssel und Known-Hosts-Management. Alles darüber hinaus ist Komfort oder Skalierung, aber selten der eigentliche Sicherheitshebel.

• ssh-keygen nutze ich für neue Schlüssel, Fingerprints, Zertifikate und KRLs.
• ssh-agent und ssh-add halten private Schlüssel nur temporär im Speicher und machen Passphrases im Alltag handhabbar.
• ssh-keyscan sammelt Host-Schlüssel effizient für known_hosts und Audit-Zwecke.
• ProxyJump ist für Bastions meist die bessere Wahl als dauerhaftes Agent Forwarding.
• Inventar oder PAM dokumentiert Besitz, Zweck und Status jedes Schlüssels.

Mozilla beschreibt für Maschinen-Schlüssel genau diesen Ansatz: eigenes Inventar, eindeutige Schlüssel pro Zweck und nur so viel Rechte wie nötig. Das ist nicht spektakulär, aber genau die Art von Disziplin, die später verhindert, dass ein alter Deploy-Key zum Sicherheitsproblem wird. Ich sehe darin eine der nüchternsten und zugleich wirksamsten Praktiken überhaupt.

Besonders wichtig ist für mich der Unterschied zwischen Bequemlichkeit und Risiko: ForwardAgent ist schnell gesetzt, aber als Standard meist die falsche Abkürzung. Für Sprünge über Jump Hosts nutze ich lieber ProxyJump, weil mein Agent dann lokal bleibt und nicht auf fremden Systemen mitläuft.

Trotz guter Tools kippen Umgebungen oft an denselben klassischen Fehlern.

Die häufigsten Fehler bei Identität und Zugriff

In Audits tauchen immer wieder dieselben Schwachstellen auf. Die gute Nachricht: Sie sind banal genug, um sie systematisch abzustellen.

• Ein Schlüssel für alles: Eine Kompromittierung trifft dann Produktionszugang, CI und Notfallzugang gleichzeitig.
• Private Keys ohne Passphrase auf dem Laptop: Das ist bequem, aber im Verlustfall nahezu sofort kritisch.
• Alte Einträge in authorized_keys: Entfernen wird vergessen, besonders nach Teamwechseln oder Projektschluss.
• Zu breite Root- oder Sudo-Rechte für Maschinenkonten: Automatisierung braucht Rechte, aber nicht dieselben wie ein Mensch.
• Dauerhaftes Agent Forwarding: Damit vergrößerst du den Vertrauensradius jedes Jump Hosts unnötig.
• Kein Inventar: Ohne Liste weiß am Ende niemand, welcher Schlüssel wohin gehört und wer ihn noch braucht.

Wenn ich eine Umgebung prüfe, frage ich deshalb immer zuerst: Wer besitzt den Schlüssel, wofür ist er da, wo liegt er, wann läuft er ab und wie wird er entzogen? Diese fünf Fragen decken erstaunlich viele Lücken auf. Sobald eine davon nicht klar beantwortet ist, ist die nächste Schwachstelle meist nur eine Frage der Zeit.

Aus diesen Antworten lässt sich dann eine pragmatische Zielarchitektur ableiten.

Was ich in gewachsenen Umgebungen zuerst vereinheitliche

Für gewachsene Umgebungen würde ich den Fokus heute auf vier Dinge legen: Ed25519 für neue interaktive Zugänge, Hardware-Schlüssel für privilegierte Konten, kurzlebige Zertifikate für Teams mit vielen Servern und ein sauberes Inventar für Maschinen-Schlüssel. Damit deckst du die typischen Risiken ab, ohne in eine unnötig komplexe Plattform zu flüchten.

• Interaktive Benutzerkonten: passwortgeschützt, möglichst hardwaregebunden und mit begrenzter Agent-Laufzeit.
• Automatisierung: eigener Schlüssel pro Dienst, enge IP- und Command-Restriktionen und kein geteilter Root-Zugang.
• Serververtrauen: Host-Schlüssel aktiv prüfen und known_hosts nicht dem Zufall überlassen.
• Entzug: Rotation und Revocation so vorbereiten, dass sie im Incident nicht erst entworfen werden müssen.

Wenn du nur mit einem Punkt anfängst, dann mit einem vollständigen Schlüsselinventar. Markiere dabei Besitzer, Zweck, letzte Nutzung und Entzugsweg, und ersetze anschließend alles, was noch ungeplant, geteilt oder dauerhaft offen ist. Genau dort entsteht in der Praxis der größte Sicherheitsgewinn.