MFA für SSH: YubiKey, PAM‑FIDO2, Jump‑Hosts und pragmatische Rückfallstrategien für Adminzugang

Ein sicherer Remote‑Adminzugang ist eine Grundvoraussetzung für zuverlässigen Betrieb. MFA für SSH, also die Kombination aus öffentlichem Schlüssel und einem zweiten Faktor (z. B. FIDO2/YubiKey), reduziert das Risiko kompromittierter Passwörter oder gestohlener SSH‑Keys erheblich. In diesem Beitrag erkläre ich, wie die Technik funktioniert, welche Komponenten (YubiKey‑Resident‑Keys, PAM‑FIDO2, OpenSSH, Jump‑Hosts) zusammenwirken, welche Stolperfallen und Risiken typischerweise auftreten und wie Sie echte Rückfallstrategien für den Notfall planen. Zielgruppe sind Admins, System Engineers und Betriebsteams, die sichere, praktikable Verfahren suchen.

Was bedeutet MFA für SSH und warum ist das wichtig?

MFA (Multi‑Factor Authentication) ist ein Authentifizierungsprinzip mit mindestens zwei unterschiedlichen Faktoren: etwas, das der Anwender besitzt (z. B. ein YubiKey), und etwas, das er kennt oder hat (z. B. ein privater SSH‑Key oder ein Passwort). Für SSH bedeutet das meist: Publickey‑Authentifizierung plus FIDO2/U2F‑Touch oder eine PAM‑basierte zweite Stufe. Der Nutzen ist konkret: Selbst wenn ein privater SSH‑Key exfiltriert wurde, verhindert der fehlende physische Token den Zugriff.

MFA für SSH: Kernelemente und Varianten

OpenSSH mit FIDO2‑Resident‑Keys

OpenSSH unterstützt seit neueren Releases Schlüsseltypen wie ed25519-sk, die FIDO2‑Tokens nutzen. Resident Keys sind private Schlüssel, die direkt auf dem Token abgelegt werden. Das ersetzt lokale Schlüsseldateien und erzwingt Touch/PIN beim Einsatz des Tokens. Nachteil ist die Abhängigkeit vom Token‑Lebenszyklus — planen Sie Ersatz‑ und Recovery‑Prozeduren ein.

# Resident FIDO2‑Key erstellen (speichert Key auf Token, verlangt Touch beim späteren Login)
ssh-keygen -t ed25519-sk -f ~/.ssh/id_ed25519_sk

PAM‑FIDO2 als zentraler zweiter Faktor

PAM (Pluggable Authentication Modules) ist das modulare Authentifizierungssystem unter Linux. Ein PAM‑FIDO2‑Modul (z. B. pam_fido2 oder libpam-u2f) kann in /etc/pam.d/sshd eingebunden werden, um SSH‑Logins zusätzlich zum Publickey zu erzwingen. PAM ist mächtig, aber eine fehlerhafte Konfiguration kann Logins komplett verhindern — testen Sie deshalb zuerst in einer isolierten Umgebung.

# Minimaler relevanter Ausschnitt von /etc/ssh/sshd_config
PubkeyAuthentication yes
ChallengeResponseAuthentication yes
PasswordAuthentication no
AuthenticationMethods publickey,keyboard-interactive

# Beispiel‑PAM‑Snippet in /etc/pam.d/sshd (schematisch)
auth    required    pam_fido2.so debug
account required    pam_nologin.so

Wichtig: Der Parameter AuthenticationMethods zwingt OpenSSH, zuerst Publickey zu verlangen und anschließend PAM (keyboard‑interactive) auszulösen, das dann die FIDO2‑Abfrage übernimmt. Fehlerhafte Reihenfolgen oder fehlende Module führen zu ‚Lockouts‘.

SSH‑Zertifikate als Ergänzung

SSH‑Zertifikate sind von einer internen CA ausgestellte Signaturen für öffentliche SSH‑Keys. Sie vereinfachen Widerruf und zentral gesteuerte Gültigkeiten. Als Ergänzung zu MFA erlauben sie, kurzfristig gültige Zugriffe zu erteilen, ohne Dateien auf Benutzergeräten verteilen zu müssen — ideal für temporäre Notfallzugriffe.

# CA-Schlüssel erzeugen (auf geschütztem CA‑Host)
ssh-keygen -t ed25519 -f /root/ssh_ca_key -N ""
# Benutzer-Öffentlichen Schlüssel signieren (z. B. 1 Stunde gültig)
ssh-keygen -s /root/ssh_ca_key -I emergency -n admin -V +1h user.pub

Jump‑Hosts und Bastion‑Architektur: zentral für MFA‑Betrieb

Ein Jump‑Host (Bastion Host) ist ein kontrollierter Zugangspunkt in ein geschütztes Segment. Er reduziert die Angriffsfläche und ermöglicht zentrale Authentifizierung, Session‑Aufzeichnung und Zugriffskontrolle. Wichtige Betriebsprinzipien:

• Harden Sie den Jump‑Host: minimaler Software‑Stack, strikte Firewall‑Regeln, eingeschränkte Benutzerkonten.
• Setzen Sie MFA zwingend am Jump‑Host durch; nur Verbindungen über die Bastion sollten zu produktiven Hosts möglich sein.
• Session‑Aufzeichnung und Audit: ergänzen Sie Aufzeichnungen (z. B. tty‑recording oder auditd) für forensische Nachvollziehbarkeit.

# ProxyJump-Verwendung (Admin‑Workstation → Bastion → Zielhost)
ssh -J bastion.example.com admin@internal-host.example.net

Agent Forwarding sollte generell deaktiviert sein, weil es Angreifern erlaubt, über eine kompromittierte Zielmaschine den Agenten auszunutzen. Schalten Sie es auf Workstation‑Level nur gezielt für vertrauenswürdige Sitzungen ein.

Praktische PAM‑ und Token‑Konfiguration: Beispiele und Prüfungen

Das PAM‑Mapping für FIDO2 unterscheidet sich je nach Modul. Typisch ist eine Mapping‑Datei, welche einen Token‑Identifikator einer Unix‑UID zuordnet. Beispiele helfen, mögliche Fehlerquellen zu finden.

# Beispiel: /etc/u2f_mappings (schematisch)
# token_hex_serial:username
1234567890abcdef:alice
fedcba0987654321:bob

# Benutzerseitige Debug‑Tools
# Prüfen, ob Token erkannt wird
ssh -v -i ~/.ssh/id_ed25519_sk alice@bastion.example.com
# PAM-Debug-Logs (auf dem Zielhost)
sudo journalctl -u sshd -f

Beim Testen beachten: PAM‑Module schreiben oft eigene Debug‑Logs; aktivieren Sie den Debug‑Modus nur temporär, damit sensible Informationen nicht dauerhaft in Logfiles verbleiben.

Rollout‑Plan: Pilot bis Produktiv

Ein strukturierter, phasenweiser Rollout minimiert Betriebsunterbrechungen:

1. Pilot: 2–5 Admins, isolierte Test‑Jump‑Host‑Umgebung und vollständige Test‑Checkliste.
2. Erweiterung: Inklusion von Betriebsteam, Logging‑KPI und Notfallübungen.
3. Produktiv: Organisation‑weiter Rollout, Schulung, On/Offboarding‑Prozesse operationalisiert.

Während der Pilotphase sollten Sie systematisch testen:

• Erzeugung und Verwendung von Resident Keys.
• PAM‑Fehlerszenarien (Token defekt, PIN‑Fehler) und die damit verknüpften Logeinträge.
• Backupszenarien (Break‑Glass, temporäre SSH‑Zertifikate, OOB‑Konsole).

Rückfallstrategien im Detail — Pläne, Checklisten und Automatisierung

Eine Rückfallstrategie verhindert, dass ein verlorener Token oder ein PAM‑Problem den Betrieb lähmt. Gute Rückfallpläne sind abgestuft und dokumentiert.

Break‑Glass: Prozessablauf

Ein Break‑Glass‑Konto ist eine streng kontrollierte Notfallidentität. Vorschlag für Ablauf und technische Maßnahmen:

• Vorhalten eines Break‑Glass‑Accounts pro kritischem Dienst, geschützt durch physische Schlüsselkopie (in Tresor) oder zeitlich begrenztes Zertifikat.
• Vor Nutzung: Genehmigung per definiertem Mehr‑Augen‑Prozess (z. B. Zweitunterschrift in Ticketing) und automatische Rotation des Passworts nach Ablauf.
• Jede Nutzung wird automatisch auditiert und löst eine Alarmkette (Pager/SMS/Email) an Incident‑Responder aus.

Temporäre SSH‑Zertifikate via Signing‑Service

Ein automatischer Signing‑Service (internes Tool mit RBAC) kann kurzfristig Zertifikate ausstellen, wenn Token fehlen. Implementieren Sie Audit‑Schritte und kurze Validitätsintervalle (z. B. 15–60 Minuten). Ein einfacher systemd‑gesteuerter Signer mit Auth‑Hooks reicht oft aus.

# Beispiel: temporäres Zertifikat (1h Gültigkeit)
ssh-keygen -s /root/ssh_ca_key -I emergency -n admin -V +1h user.pub
# Gültigkeit prüfen (lokal):
ssh-keygen -L -f user-cert.pub

Physischer OOB‑Zugang und Konsole

Out‑of‑Band (IPMI/Redfish, Konsolenserver) darf nicht nur vorhanden, sondern auch gehärtet und regelmäßig getestet sein. OOB stellt sicher, dass Sie Zugriff erhalten, selbst wenn SSH‑Dienste oder Authentifizierungen scheitern. Regeln:

• OOB‑Netze physisch/logisch isolieren.
• Zugriff auf OOB nur über MFA‑gesicherte Admin‑VMs erlauben.
• Firmware regelmäßig patchen und default credentials entfernen.

Konkrete Troubleshooting‑Checks

Wenn Login fehlschlägt, führt systematisches Debugging schnell zur Ursache. Beispiel‑Sequenz:

1. Verbose‑SSH auf der Workstation: ssh -vvv prüfen, ob der sk Key angeboten wird.
2. Server‑Logs prüfen: sudo journalctl -u sshd -b oder /var/log/auth.log.
3. PAM‑Module temporär testen mit einem separaten PAM‑Kontext oder auf einem Testhost.
4. Token‑Health prüfen: Ist der Token beschädigt? PIN‑Versuche überschritten?

# Beispielbefehle
# Debug auf Client
ssh -vvv -i ~/.ssh/id_ed25519_sk alice@bastion.example.com
# Server logs
sudo journalctl -u sshd -n 200
# Suche nach FIDO‑Fehlern
sudo journalctl -u sshd | grep -i fido || sudo grep -i fido /var/log/auth.log

Lifecycle‑Management der Token

Token‑Lifecycle umfasst Ausgabe, Ersatz, Sperrung und Entsorgung. Verwalten Sie Token zentral mit Inventar, Verantwortlichkeiten und Zeitfenstern:

• Ausgabe: Dokumentierte Übergabe mit Signatur und Ticket‑Referenz (z. B. Zammad‑Ticketnummer).
• Ersatz: Standardprozess für beschädigte oder nicht reagierende Tokens; Ausgabe eines temporären Zertifikats für Reprovisionierung.
• Sperrung: Bei Verlust sofort Token als kompromittiert markieren und zugehörige SSH‑Zertifikate bzw. PAM‑Bindings widerrufen.
• Entsorgung: Token sicher löschen (sofern möglich) und physisch vernichten, wenn ausgemustert.

Zur Automation können Sie YubiKey Manager CLI (ykman) nutzen, um Informationen zu serials und konfigurierten Slots abzufragen. Beachten Sie jedoch, dass nicht alle Token‑Modelle exakt dieselben Befehle unterstützen.

# YubiKey Manager: Seriennummer anzeigen
ykman info

Integration in Verzeichnisdienste und CI/CD

In großen Umgebungen authentifizieren Admins oft gegen LDAP/AD. PAM‑FIDO2 lässt sich parallel zu LDAP‑Bindungen betreiben: LDAP liefert Accountinformationen, PAM‑FIDO2 validiert den zweiten Faktor. Achten Sie auf Reihenfolge in /etc/pam.d/sshd, damit LDAP‑Account‑Checks nicht PAM‑FIDO2 blockieren.

CI/CD‑Runnings und Automatisierungen dürfen nicht von physischen Tokens abhängig sein. Verwenden Sie für Pipeline‑Jobs Machine‑Accounts mit SSH‑Zertifikaten oder Host‑Keys, die zentral verwaltet und zeitlich limitiert sind. Bewahren Sie Secrets in Vaults auf und rotieren Sie regelmäßig.

Typische Stolperfallen und wie Sie sie vermeiden

• Fehlerhafte PAM‑Konfigurationen: Testen Sie immer per separatem Admin‑Account und halten Sie eine OOB‑Konsole bereit.
• Inkompatible Token‑Modelle: Nicht alle FIDO2‑Tokens unterstützen Resident Keys; prüfen Sie Hardware‑Matrix vor Kauf.
• USB‑Passthrough in virtuellen Desktops: Token werden manchmal nicht zuverlässig weitergereicht; testen Sie in Ihren Nutzerumgebungen.
• Agent Forwarding: Deaktivieren, da es MFA‑Schutz auf der Workstation aushöhlen kann.
• Logging ohne Korrelation: Stellen Sie sicher, dass SSHD‑Logs, PAM‑Logs und CA‑Signierungsereignisse in Ihr SIEM gelangen.

Spezielle Hinweise für Zammad‑Betriebsteams

Zammad‑Instanzen benötigen oft differenzierte Zugriffsrollen: Entwickler, Applikationsbetreuer, DB‑Admins. Empfehlungen praxisnah umgesetzt:

• Führen Sie Zammad‑spezifische Adminaufgaben nur über die Bastion aus und trennen Sie DB‑Admin‑Sitzungen von Applikations‑Deploys.
• Erfassen Sie Token‑Zuweisungen und Break‑Glass‑Ereignisse direkt im Ticketing (z. B. Zammad), damit Audit‑Trails und Change‑Kontext erhalten bleiben.
• Für Notfallwiederherstellung behalten Sie ein Verfahren, wie Datenbankzugriff mit minimalen Rechten und temporären Zertifikaten gewährt wird — dokumentiert im Disaster‑Recovery‑Runbook.

{
  "ticket_type": "Break-Glass",
  "summary": "Temporärer Zugang: CA-Zertifikat ausstellen",
  "requested_by": "alice",
  "approver": "operations_lead",
  "reason": "Verlorener YubiKey",
  "issued_certificate_ttl": "60m",
  "audit_note": "Certificate issued per emergency procedure"
}

Checkliste für Produktion (kurz)

• Pilot mit 2–5 Admins durchführen und Lessons Learned dokumentieren.
• Jump‑Host härtet, MFA zwingend setzen, Agent Forwarding deaktivieren.
• Temporäre SSH‑Zertifikate einrichten und Signer‑Service testen.
• Break‑Glass‑Konten definieren, Approval‑Workflow implementieren und Audit aktivieren.
• OOB‑Zugänge prüfen und halbjährliche Notfallübungen durchführen.

Fazit und Handlungsempfehlungen

MFA für SSH mit YubiKey und PAM‑FIDO2 ist eine praktikable Maßnahme, die administrativen Zugriff deutlich sicherer macht. Entscheidend ist ein verantwortungsbewusster Rollout: Pilotgruppe, dokumentierte On/Offboarding‑Prozesse, getestete Rückfallstrategien und striktes Logging. Für Zammad‑Betriebsteams gilt zusätzlich, Zugriffe strikt zu trennen, Token‑Zuweisungen im Ticketing zu dokumentieren und Wiederherstellungsverfahren zu proben.

Kurzcheck zum Mitnehmen:

• Definieren Sie eine Pilotgruppe und bauen Sie eine isolierte Testumgebung auf.
• Testen Sie OpenSSH‑sk‑Keys und PAM‑FIDO2 parallel und validieren Sie Logs.
• Härten Sie Jump‑Hosts, deaktivieren Sie Agent Forwarding standardmäßig.
• Implementieren und proben Sie Rückfallstrategien (Break‑Glass, OOB, temporäre Zertifikate).
• Integrieren Sie Token‑Inventar und Change‑Prozesse ins Ticketing (z. B. Zammad) und planen Sie regelmäßige Notfallübungen.

Bei Bedarf eignet sich ein fokussierter Workshop, um technische Optionen, organisatorische Rollen und Notfall‑Playbooks zusammenzuführen und in Ihre Betriebsprozesse zu integrieren.

Betriebsperspektiven: CA‑Schutz, Fail‑Policies und Bastion‑HA

Neben der Nutzer‑Authentifizierung entscheidet die Hardening‑ und Betriebsarchitektur über die Praxisreife von MFA‑SSH. Schützen Sie Ihre SSH‑CA‑Privat‑Keys wie Produktions‑Kryptomaterial: idealerweise in einem HSM oder zumindest offline auf einem dedizierten, gesicherten Host. Legen Sie einen klaren Kompromiss‑Plan fest: Key‑Rotation, Notfall‑Wiederherstellung und Kommunikations‑Playbooks für den Fall eines Schlüsselverlusts.

Entscheidungen zu Fail‑Policies sind kritisch: Ein PAM‑Ausfall kann entweder Logins ablehnen (fail‑closed) oder Durchlass gewähren (fail‑open). Favorisieren Sie fail‑closed mit getesteten OOB‑Rückfallwegen statt stillschweigender Ausnahmefälle, weil letztere Audit und Verantwortlichkeit untergraben.

Bastion‑Hochverfügbarkeit erreichen Sie durch aktive Backup‑Instanzen, zentrale Session‑Aufzeichnung und verteilte Signer‑Services für SSH‑Zertifikate. Synchronisieren Sie nur öffentliche Metadaten (CA‑Publickeys, Audit‑Logs); private Schlüssel bleiben streng isoliert.

Automatisieren Sie Token‑Lifecycle und Notfall‑Zertifikate über Ihre Ticketing‑API (z. B. Zammad) oder Ihre individuelle Unternehmenssoftware, um Ausgabe, Sperrung und Audit lückenlos zu verbinden. Beobachten Sie Kennzahlen: Auth‑Fehler‑Rate, Signier‑Raten, PAM‑Latenz und Break‑Glass‑Events — Alerts bei Abweichungen sind Pflicht.

# Sicherer CA‑Rotation‑Ablauf (vereinfachtes Beispiel)
ssh-keygen -t ed25519 -f /root/ssh_ca_key_new -N ""
cp /root/ssh_ca_key_new.pub /etc/ssh/trusted_user_ca_keys/ca_new.pub
# Signieren und testen, dann swappen
ssh-keygen -s /root/ssh_ca_key_new -I test -n admin -V +5m user.pub

Für dieses Thema sind auch Pam-Fido2 und Jump-Host wichtig. Der Beitrag ordnet diese Aspekte verständlich ein und zeigt, worauf es im Alltag ankommt.