MFA per SSH: YubiKey, PAM‑FIDO2, Jump‑Hosts e strategie di fallback pragmatiche per l'accesso amministrativo

Un accesso amministrativo remoto sicuro è un prerequisito fondamentale per un funzionamento affidabile. MFA per SSH, cioè la combinazione di chiave pubblica e di un secondo fattore (p.es. FIDO2/YubiKey), riduce significativamente il rischio di password compromesse o di chiavi SSH rubate. In questo articolo spiego come funziona la tecnologia, quali componenti (YubiKey‑Resident‑Keys, PAM‑FIDO2, OpenSSH, Jump‑Hosts) interagiscono, quali insidie e rischi tipicamente emergono e come pianificare vere strategie di fallback per le emergenze. Il pubblico di riferimento sono admin, System Engineers e i team di operation che cercano procedure sicure e praticabili.

Cosa significa MFA per SSH e perché è importante?

MFA (Multi‑Factor Authentication) è un principio di autenticazione con almeno due fattori distinti: qualcosa che l’utente possiede (p.es. un YubiKey) e qualcosa che conosce o possiede (p.es. una chiave SSH privata o una password). Per SSH questo significa di norma: autenticazione con chiave pubblica più touch FIDO2/U2F o una seconda fase basata su PAM. Il beneficio è concreto: anche se una chiave SSH privata viene esfiltrata, l’assenza del token fisico impedisce l’accesso.

MFA per SSH: elementi chiave e varianti

OpenSSH con FIDO2‑Resident‑Keys

OpenSSH supporta, nelle release recenti, tipi di chiave come ed25519-sk che sfruttano token FIDO2. I Resident Keys sono chiavi private memorizzate direttamente sul token. Questo sostituisce i file di chiave locali e impone l’uso del touch/PIN all’utilizzo del token. Lo svantaggio è la dipendenza dal ciclo di vita del token — pianificate procedure di sostituzione e recovery.

# 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 come secondo fattore centrale

PAM (Pluggable Authentication Modules) è il sistema modulare di autenticazione su Linux. Un modulo PAM‑FIDO2 (p.es. pam_fido2 o libpam-u2f) può essere integrato in /etc/pam.d/sshd per imporre i login SSH oltre all’autenticazione con chiave pubblica. PAM è potente, ma una configurazione errata può impedire del tutto i login — testate pertanto prima in un ambiente isolato.

# 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

Importante: il parametro AuthenticationMethods obbliga OpenSSH a richiedere prima la chiave pubblica e successivamente a invocare PAM (keyboard‑interactive), che poi gestisce la richiesta FIDO2. Ordinamenti errati o moduli mancanti causano blocchi degli accessi (‚lockouts‘).

Certificati SSH come complemento

I certificati SSH sono firme emesse da una CA interna per le chiavi pubbliche SSH. Semplificano il revoca e la gestione centralizzata delle validità. Come complemento alla MFA permettono di concedere accessi validi per brevi periodi senza dover distribuire file sui dispositivi degli utenti — ideale per accessi temporanei di emergenza.

# 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

Un Jump‑Host (Bastion Host) è un punto di accesso controllato in un segmento protetto. Riduce la superficie di attacco e permette autenticazione centralizzata, registrazione delle sessioni e controllo degli accessi. Principi operativi importanti:

• Rafforzate il Jump‑Host: stack software minimo, regole firewall stringenti, account utente limitati.
• Imponete l’MFA sul Jump‑Host; solo le connessioni tramite la Bastion dovrebbero poter raggiungere gli host di produzione.
• Registrazione delle sessioni e audit: integrate registrazioni (ad es. tty‑recording o auditd) per la ricostruzione forense.

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

Agent Forwarding dovrebbe essere generalmente disabilitato, poiché consente a un attaccante di sfruttare l’agente tramite una macchina target compromessa. Attivatelo a livello Workstation solo in modo mirato per sessioni di fiducia.

Configurazione pratica PAM‑ e token: esempi e verifiche

Il mapping PAM per FIDO2 varia a seconda del modulo. Tipico è un file di mapping che associa un identificatore di token a una UID Unix. Esempi aiutano a individuare potenziali cause di errore.

# 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

Durante i test tenete presente: i moduli PAM spesso scrivono log di debug propri; abilitate la modalità di debug solo temporaneamente, affinché informazioni sensibili non rimangano permanentemente nei file di log.

Piano di rollout: dal pilota alla produzione

Un rollout strutturato e a fasi minimizza le interruzioni operative:

1. Pilota: 2–5 Admins, ambiente di test isolato per il Jump‑Host e checklist di test completa.
2. Estensione: inclusione del team operativo, KPI di logging e esercitazioni di emergenza.
3. Produzione: rollout a livello organizzativo, formazione, processi di On/Offboarding operationalizzati.

Durante la fase pilota dovreste testare in modo sistematico:

• Generazione e utilizzo di Resident Keys.
• Scenario di errore PAM (token difettoso, errore PIN) e le voci di log correlate.
• Scenari di backup (Break‑Glass, certificati SSH temporanei, console OOB).

Strategie di fallback in dettaglio — piani, checklist e automazione

Una strategia di fallback evita che un token smarrito o un problema PAM paralizzi l’operatività. Buoni piani di fallback sono graduati e documentati.

Break‑Glass: flusso procedurale

Un account Break‑Glass è un’identità d’emergenza strettamente controllata. Suggerimento per il flusso e le misure tecniche:

• Mantenimento di un account Break‑Glass per ciascun servizio critico, protetto tramite copia fisica della chiave (in cassaforte) o certificato con validità limitata.
• Prima dell’uso: autorizzazione tramite processo a più occhi definito (ad es. doppia firma nel ticketing) e rotazione automatica della password alla scadenza.
• Ogni utilizzo viene automaticamente sottoposto ad audit e attiva una catena di allarme (Pager/SMS/Email) verso gli Incident‑Responder.

Certificati SSH temporanei via Signing‑Service

Un Signing‑Service automatico (tool interno con RBAC) può emettere certificati a breve termine quando mancano i token. Implementate passaggi di audit e intervalli di validità brevi (ad es. 15–60 minuti). Un semplice signer gestito da systemd con Auth‑Hooks spesso è sufficiente.

# Esempio: certificato temporaneo (validità 1h)
ssh-keygen -s /root/ssh_ca_key -I emergency -n admin -V +1h user.pub
# Verifica della validità (locale):
ssh-keygen -L -f user-cert.pub

Accesso OOB fisico e console

Out‑of‑Band (IPMI/Redfish, Konsolenserver) non deve solo essere presente, ma anche essere approfonditamente protetto e testato regolarmente. OOB garantisce l’accesso anche se i servizi SSH o le autenticazioni falliscono. Regole:

• Isolare le reti OOB fisicamente/logicamente.
• Consentire l’accesso all’OOB solo tramite VM amministrative protette da MFA.
• Aggiornare regolarmente il firmware e rimuovere le credenziali di default.

Controlli concreti di troubleshooting

Se il login fallisce, un debug sistematico porta rapidamente alla causa. Sequenza di esempio:

1. SSH in modalità verbose sulla workstation: controllare ssh -vvv per vedere se viene offerta la chiave sk.
2. Controllare i log del server: sudo journalctl -u sshd -b o /var/log/auth.log.
3. Testare temporaneamente i moduli PAM con un contesto PAM separato o su un host di test.
4. Verificare lo stato del token: il token è danneggiato? Tentativi PIN superati?

# Esempi di comandi
# Debug sul client
ssh -vvv -i ~/.ssh/id_ed25519_sk alice@bastion.example.com
# Log del server
sudo journalctl -u sshd -n 200
# Ricerca errori FIDO
sudo journalctl -u sshd | grep -i fido || sudo grep -i fido /var/log/auth.log

Gestione del ciclo di vita dei token

Il ciclo di vita dei token comprende emissione, sostituzione, sospensione e smaltimento. Gestite i token centralmente con inventario, responsabilità e finestre temporali:

• Emissione: consegna documentata con firma e riferimento ticket (p.es. numero ticket Zammad).
• Sostituzione: processo standard per token danneggiati o non rispondenti; emissione di un certificato temporaneo per la reprovisioning.
• Sospensione: in caso di smarrimento, marcare immediatamente il token come compromesso e revocare i relativi certificati SSH o i binding PAM.
• Smaltimento: cancellare in modo sicuro il token (se possibile) e distruggerlo fisicamente quando fuori servizio.

Per l’automazione è possibile usare YubiKey Manager CLI (ykman) per interrogare seriali e slot configurati. Tenete presente tuttavia che non tutti i modelli di token supportano esattamente gli stessi comandi.

# YubiKey Manager: mostrare il numero di serie
ykman info

Integrazione in servizi directory e CI/CD

In ambienti di grandi dimensioni gli amministratori spesso si autenticano contro LDAP/AD. PAM‑FIDO2 può funzionare in parallelo con i bind LDAP: LDAP fornisce le informazioni sull’account, PAM‑FIDO2 valida il secondo fattore. Prestate attenzione all’ordine in /etc/pam.d/sshd, in modo che i controlli account LDAP non blocchino PAM‑FIDO2.

I processi CI/CD e le automazioni non devono dipendere da token fisici. Utilizzate per i job di pipeline account macchina con certificati SSH o host‑key, gestiti centralmente e con limitazioni temporali. Conservate i segreti in vault e ruotateli regolarmente.

Problemi tipici e come evitarli

• Configurazioni PAM errate: testate sempre con un account amministrativo separato e tenete a disposizione una console OOB.
• Modelli di token incompatibili: non tutti i token FIDO2 supportano Resident Keys; verificate la matrice hardware prima dell’acquisto.
• USB‑passthrough nei desktop virtuali: i token talvolta non vengono inoltrati in modo affidabile; testate nei vostri ambienti utente.
• Agent forwarding: disabilitatelo, perché può erodere la protezione MFA sulla workstation.

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.

La disponibilità elevata del bastion si ottiene tramite istanze di backup attive, registrazione centrale delle sessioni e servizi di firma distribuiti per i certificati SSH. Sincronizzate solo i metadati pubblici (chiavi pubbliche CA, log di audit); le chiavi private rimangono strettamente isolate.

Automatizzate il ciclo di vita dei token e i certificati di emergenza tramite la vostra API di ticketing (es. Zammad) o il vostro software aziendale personalizzato, per collegare emissione, revoca e audit senza soluzione di continuità. Monitorate le metriche: tasso di errori di autenticazione, tassi di firma, latenza PAM e eventi break-glass — gli alert in caso di deviazioni sono obbligatori.

# 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

Per questo ambito sono inoltre importanti Pam-Fido2 e Jump-Host. L’articolo inquadra questi aspetti in modo chiaro e mostra cosa conta nella pratica quotidiana.