# SSH Certificates: Identitätsmanagement ohne authorized_keys

TL;DR / Management Summary Wer hunderte Server verwaltet, verzweifelt an der Pflege der authorized_keys Dateien. SSH-Zertifikate bieten die Lösung: Anstatt Schlüssel auf jedem Server zu hinterlegen, vertraut der Server einer zentralen SSH Certificate Authority (CA). Der Admin lässt seinen Key einmalig (z.B. täglich) signieren und erhält Zugriff auf alle Server. Dies ermöglicht kurzlebige Zugänge, granulare Berechtigungen und macht die manuelle Key-Verteilung überflüssig.

# 1. Einführung & Architektur

Das CA-Prinzip.

In einem klassischen Setup muss der Server den Public Key des Admins kennen. Bei Zertifikaten kennt der Server nur den Public Key der CA.

# Der Zertifikats-Fluss (Mermaid)

graph TD
    A[Admin User] -->|1. Generate Key| B[SSH Key: id_ed25519]
    B -->|2. Request Signing| C[SSH CA Server]
    C -->|3. Sign with CA Key| D[SSH Certificate: id_ed25519-cert.pub]
    D -->|4. Login Request| E[Target Server]
    E -->|5. Verify with Trusted CA Key| F{Valid?}
    F -->|Yes| G[Access Granted]
    F -->|No| H[Deny]
    subgraph "Trust Anchor"
        E --- I[/etc/ssh/trusted-user-ca-keys.pem]
    end

# 2. Aufbau einer SSH CA

Den Schiedsrichter erstellen.

# Schritt 1: CA-Schlüssel generieren (auf dem CA-Server)

Dieser Schlüssel sollte extrem sicher (Offline/Hardware-Token) verwaltet werden.

ssh-keygen -t ed25519 -f ssh_user_ca -C "My Enterprise SSH CA"

# Schritt 2: Den Servern die CA bekannt machen

Kopieren Sie ssh_user_ca.pub auf alle Zielserver nach /etc/ssh/ und passen Sie die sshd_config an:

TrustedUserCAKeys /etc/ssh/ssh_user_ca.pub

Danach: systemctl restart sshd.

# 3. Schlüssel signieren

Zugriff gewähren.

Wenn ein Admin Zugriff braucht, schickt er seinen Public Key an die CA.

# Signierungs-Befehl

# -s: CA Key, -I: Identity, -n: Erlaubte User, -V: Gültigkeit
ssh-keygen -s ssh_user_ca -I "admin_access" -n root,sysadmin -V +1d id_ed25519.pub

Dies erstellt id_ed25519-cert.pub. Der Admin kann sich nun für 24 Stunden als root oder sysadmin einloggen.

# 4. Day-2 Operations: Skalierung & Automatisierung

Kein manuelles Signieren.

In der Praxis nutzt man Tools wie Vault (HashiCorp) oder Teleport, die den CA-Part übernehmen und Kurzzeit-Zertifikate nach einem erfolgreichen LDAP/MFA Login ausgeben.

# 5. Troubleshooting & “War Stories”

Wenn das Zertifikat abgelehnt wird.

# Story 1: “Der Time-Mismatch Fail”

Symptom: Ein Admin hat ein frisches Zertifikat, aber der Login scheitert mit Certificate invalid: current time is before valid-from. Ursache: Die Systemzeit auf dem Server oder dem CA-Host ist nicht synchron (NTP-Fehler). Lösung: Stellen Sie sicher, dass alle Systeme via NTP synchronisiert sind. Nutzen Sie bei der Signierung einen Puffer: -V -5m:+1d (Gültig ab vor 5 Minuten).

# Story 2: “User-Mapping Problem”

Symptom: Das Zertifikat ist gültig, aber der Login als User johndoe schlägt fehl. Als root geht es. Ursache: In der Signierung (-n) wurde der User johndoe nicht explizit aufgeführt. Lösung: Prüfen Sie das Zertifikat: ssh-keygen -Lf id_ed25519-cert.pub. Schauen Sie in die Sektion Principals. Dort muss der Ziel-Username stehen.

# 6. Fazit & Empfehlung

• Wahl: Nutzen Sie SSH-Zertifikate ab einer Flottengröße von 50 Servern.
• Sicherheit: Setzen Sie die Gültigkeit von Zertifikaten so kurz wie möglich (z.B. 8 Stunden). So müssen Sie sich keine Gedanken über das Sperren (Revocation) von Schlüsseln machen.
• Best Practice: Nutzen Sie für die CA-Schlüssel immer Hardware-Token wie den YubiKey (PIV-Slot).

# Anhang: Cheatsheet