SSH-Zertifikate: Schlüssel, die von selbst ablaufen

Solange es fünf Maschinen sind, funktioniert SSH-Schlüssel verwalten mit authorized_keys. Ab etwa zwanzig, oder sobald Zugänge zeitlich begrenzt sein sollen, kippt der Aufwand: Jede Personaländerung wird zu einem Durchlauf über alle Hosts, und niemand weiß sicher, ob er vollständig war.

Das Prinzip in drei Sätzen#

Eine eigene Zertifizierungsstelle (CA) signiert öffentliche Schlüssel. Der Server vertraut der CA, nicht mehr den einzelnen Schlüsseln. Ein signiertes Zertifikat hat eine Gültigkeitsdauer, läuft sie ab, endet der Zugang von selbst.

Aufbau#

# 1. CA-Schlüsselpaar, auf einer Maschine, die nichts anderes tut
ssh-keygen -t ed25519 -f nutzer-ca -C "nutzer-ca $(date +%F)"

# 2. Öffentlichen CA-Schlüssel auf alle Server verteilen
sudo install -m 0644 nutzer-ca.pub /etc/ssh/nutzer-ca.pub

# /etc/ssh/sshd_config
TrustedUserCAKeys /etc/ssh/nutzer-ca.pub
# authorized_keys bleibt vorerst zusätzlich aktiv — Rückweg!

# 3. Zugang für eine Person ausstellen: 8 Stunden, nur bestimmte Kontonamen
ssh-keygen -s nutzer-ca -I "mara@laptop" -n mara,deploy -V +8h \
  -O clear -O permit-pty -O permit-user-rc mara_ed25519.pub

# 4. Prüfen, was drinsteht
ssh-keygen -L -f mara_ed25519-cert.pub

Der Client nutzt das Zertifikat automatisch, wenn es neben dem Schlüssel liegt. Nach acht Stunden ist der Zugang weg, ohne dass jemand etwas löschen muss.

Host-Zertifikate: das Ende der Fingerabdruckfrage#

Die Rückrichtung ist genauso nützlich und wird meist vergessen: Signierte Host-Schlüssel beenden die Meldung „The authenticity of host … can't be established“, die ohnehin fast niemand prüft.

# Host-CA (getrennt von der Nutzer-CA!)
ssh-keygen -t ed25519 -f host-ca -C "host-ca"
ssh-keygen -s host-ca -I web01 -h -n web01.example.org,203.0.113.10 -V +52w /etc/ssh/ssh_host_ed25519_key.pub

# sshd_config auf dem Server
HostCertificate /etc/ssh/ssh_host_ed25519_key-cert.pub

# known_hosts auf dem Client — eine Zeile für alle Server
@cert-authority *.example.org ssh-ed25519 AAAA... host-ca

Umstellen ohne Aussperren#

1. CA aufsetzen, öffentlichen Teil verteilen, TrustedUserCAKeys setzen, authorized_keys bleibt aktiv.
2. Für alle Personen Zertifikate ausstellen und zwei Wochen parallel fahren.
3. Prüfen, wer sich noch per Datei anmeldet:

journalctl -u ssh --since -14d | grep 'Accepted publickey' | grep -v 'ID .*CA' | head

4. Erst dann authorized_keys leeren und die Konsole des Anbieters vorher testen, wie in Passwort-Login abschalten.

Wann es sich nicht lohnt#

Bei drei Servern und einer Person ist eine CA zusätzlicher Aufbau ohne Gewinn. Dann ist die bessere Investition ein Sprungserver oder ein Hardware-Token (Zweiter Faktor). Zertifikate lohnen sich ab dem Punkt, an dem „wer hat eigentlich noch Zugang?“ nicht mehr aus dem Kopf zu beantworten ist.

Der Betriebsablauf, den man vorher festlegt#

Zertifikate verschieben die Arbeit von „Dateien auf zwanzig Servern pflegen“ zu „einen Ausstellungsvorgang betreiben“. Das ist ein Gewinn, aber nur, wenn dieser Vorgang beschrieben ist. Vier Festlegungen reichen:

Wer stellt aus? Eine benannte Person oder ein Ablauf, nicht „wer gerade Zeit hat“. Der CA-Schlüssel ist der wertvollste Schlüssel im Bestand, wer ihn hat, hat alles.

Wie lange gilt ein Zertifikat? Für Personen ein Arbeitstag, für Dienstkonten so kurz wie der Ablauf es zulässt. Kurze Laufzeiten sind der eigentliche Sicherheitsgewinn, weil sie Widerruf überflüssig machen.

Was passiert, wenn die CA nicht erreichbar ist? Für diesen Fall bleibt ein Notfallschlüssel in authorized_keys auf jedem Server, offline dokumentiert, selten benutzt, jährlich getauscht. Ohne ihn hängt der Zugang an einem einzelnen System.

Wie wird geprüft, dass es funktioniert? Einmal im Quartal ein abgelaufenes Zertifikat vorlegen und bestätigen, dass die Anmeldung scheitert. Ein Mechanismus, dessen Wirkung nie geprüft wurde, ist eine Annahme.