SSH-Schlüsselpaare haben ein Ausuferungsproblem. Zertifikate sind die Lösung.

SSH-Schlüsselpaare funktionieren für drei Server problemlos. Bei dreißig werden sie zum Sicherheitsrisiko. Bei dreihundert sind sie ein Compliance-Albtraum. Veraltete Schlüssel sammeln sich an, ohne Ablaufmechanismus, ohne zentrale Widerrufsmöglichkeit und ohne Audit-Trail, der einen Schlüssel mit einem bestimmten Login-Ereignis verbindet. SSH-Zertifikate lösen alle drei Probleme, ohne dass sich für Entwickler die Art und Weise ändert, wie sie sich mit Servern verbinden.

Das SSH-Key-Sprawl-Problem

Laut Venafis 2024 Machine Identity Management Survey beträgt die durchschnittliche Lebensdauer eines SSH-Schlüssels in einem Unternehmen mit mehr als 100 Entwicklern 4,3 Jahre. Neue Mitarbeiter erzeugen ein Schlüsselpaar, fügen ihren öffentlichen Schlüssel in die authorized_keys aller benötigten Server ein – und wenn sie das Unternehmen verlassen, ändert sich nichts. Offboarding-Checklisten übersehen Server. Die Schlüssel bleiben aktiv.

Die strukturellen Probleme von SSH-Schlüsselpaaren im großen Maßstab:

Keine Ablaufzeit. Ein 2019 erstellter Schlüssel ist 2026 noch genauso gültig – es sei denn, jemand entfernt ihn manuell aus jeder authorized_keys-Datei auf jedem Server, zu dem er hinzugefügt wurde.
Keine zentrale Widerrufsmöglichkeit. Wird ein privater Schlüssel gestohlen oder ein Laptop verloren, bedeutet das Widerrufen des Zugriffs: per SSH auf jeden betroffenen Server einloggen und authorized_keys editieren. In einer Umgebung mit 200 Servern dauert das Stunden – vorausgesetzt, man weiß überhaupt, auf welchen Servern der Schlüssel liegt.
Kein Audit-Trail. sshd protokolliert, welcher Schlüssel-Fingerabdruck eine Sitzung authentifiziert hat, aber es gibt keine autoritative Aufzeichnung, die diesen Fingerabdruck zur Ausstellungszeit mit der Identität eines bestimmten Entwicklers verbindet. Schlüssel-Fingerabdrücke sind keine Identitäten.
Risiko der lateralen Bewegung. Ein gestohlener Schlüssel gewährt Zugriff auf jeden Server, zu dem er hinzugefügt wurde. Es gibt keine Einschränkung des Geltungsbereichs, keine zeitliche Begrenzung und keine Möglichkeit, einen Schlüssel nach der Ausstellung auf eine bestimmte Quell-IP zu beschränken.

Keines davon ist hypothetisch. Der Twitter-Vorfall 2020 betraf einen Insider, der sich per Social Engineering SSH-Zugang verschaffte. Die Schlüsselverwaltung erschwerte die Eingrenzung des Vorfalls erheblich.

So funktionieren SSH-Zertifikate

Eine SSH-Zertifizierungsstelle (CA) selbst ist nichts weiter als ein SSH-Schlüsselpaar – typischerweise ed25519. Anstatt Benutzer-Schlüssel auf Server zu verteilen, konfiguriert man die Server so, dass sie den öffentlichen Schlüssel der CA vertrauen. Die CA signiert dann einzelne öffentliche Benutzerschlüssel, um Zertifikate zu erstellen.

Ein signiertes SSH-Zertifikat enthält die folgenden Felder:

Principals: die Liste der Benutzernamen oder Gruppen, für die dieses Zertifikat gültig ist (z. B. alice, eng-team)
Gültig ab / Gültig bis: feste Zeitstempel – außerhalb dieses Zeitfensters ist das Zertifikat kryptografisch ungültig
Quelladressbeschränkung: optionaler IP-Bereich, von dem aus dieses Zertifikat verwendet werden kann
Erweiterungen: Fähigkeiten wie permit-pty, permit-port-forwarding, permit-agent-forwarding – jede kann pro Zertifikat gewährt oder verweigert werden
Zertifikats-Seriennummer: eine eindeutige Kennung, die in den sshd-Auth-Logs erscheint

Die sshd_config des Servers enthält eine einzige Zeile: TrustedUserCAKeys /etc/ssh/ca_user_key.pub. Das ist die einzige notwendige Konfigurationsänderung. Schluss mit der Verwaltung von authorized_keys-Dateien.

Eigene CA in 15 Minuten einrichten

Sie brauchen weder Teleport noch HashiCorp Vault, um loszulegen. OpenSSH bringt alles Nötige mit.

Schritt 1 – CA-Schlüssel auf einem sicheren Host erzeugen:

ssh-keygen -t ed25519 -f /etc/ssh/ca_user_key -C "SSH User CA"

Bewahren Sie ca_user_key (privat) offline oder in einem Secrets Manager auf. Verteilen Sie ca_user_key.pub auf jeden Server.

Schritt 2 – sshd auf jedem Server konfigurieren:

TrustedUserCAKeys /etc/ssh/ca_user_key.pub

Laden Sie sshd neu. Der Server akzeptiert nun jedes von dieser CA signierte Zertifikat, vorbehaltlich der Principal- und Gültigkeitsbeschränkungen.

Schritt 3 – Einem Benutzer ein Zertifikat ausstellen:

ssh-keygen -s ca_user_key -I "[email protected]" -n alice -V +8h alice.pub

Dies erzeugt alice-cert.pub. Das Flag -I setzt die Schlüssel-ID (wird beim Authentifizieren protokolliert), -n alice setzt den Principal, -V +8h macht es für 8 Stunden ab jetzt gültig.

Schritt 4 – Der Benutzer verbindet sich wie gewohnt:

ssh alice@prod-server-01

OpenSSH präsentiert automatisch das Zertifikat zusammen mit dem privaten Schlüssel. Keine Änderung am Workflow des Benutzers.

Kurzzeit-Zertifikate + Identity-Plattformen

Manuelle Zertifikatsausstellung funktioniert für kleine Teams. Für die Produktion in großem Maßstab möchte man eine automatisierte Ausstellung, die an den Identity Provider angebunden ist.

Teleport fungiert sowohl als SSH-CA als auch als Proxyschicht. Entwickler authentifizieren sich per Okta oder Azure AD SSO, Teleport stellt ein kurzlebiges Zertifikat aus (Standard 12 Stunden), und alle Sitzungsaktivitäten werden aufgezeichnet. Zugriff zu widerrufen bedeutet, den Benutzer aus der IdP-Gruppe zu entfernen – keine Serveränderungen nötig.

HashiCorp Vault SSH Secrets Engine bietet die CA-Funktionalität ohne die Proxyschicht. Konfigurieren Sie eine Vault-Rolle:

vault write ssh/roles/eng-ssh \
  key_type=ca \
  allowed_users="*" \
  default_user=ubuntu \
  ttl=8h \
  max_ttl=24h \
  allowed_extensions="permit-pty,permit-port-forwarding"

Entwickler authentifizieren sich bei Vault (über OIDC/Okta/Azure AD + MFA), fordern ein Zertifikat an mit vault ssh -role eng-ssh -mode ca -mount-point ssh user@host und erhalten ein zeitlich begrenztes Zertifikat. Vault protokolliert jede Ausstellung mit der anfordernden Identität.

AWS EC2 Instance Connect verwendet nativ dasselbe Modell für EC2-Instanzen – einen temporären öffentlichen Schlüssel übertragen (60 Sekunden gültig), verbinden, fertig. Überhaupt keine dauerhaften authorized_keys.

Schlüsselwiderruf ist in all diesen Systemen sofort wirksam. Wenn die CA keine neuen Zertifikate für einen Benutzer mehr ausstellt, laufen alle seine vorhandenen Zertifikate innerhalb von maximal wenigen Stunden ab. Vergleichen Sie das mit der manuellen Suche nach Schlüsseleinträgen auf Hunderten von Servern.

Host-Zertifikate: Die andere Hälfte

SSH-Zertifikate funktionieren in beide Richtungen. Benutzerzertifikate authentifizieren Benutzer gegenüber Servern; Host-Zertifikate authentifizieren Server gegenüber Benutzern.

Ohne Host-Zertifikate verwendet SSH TOFU (Trust On First Use) – beim ersten Verbinden mit einem Host wird man