MFA pour SSH : YubiKey, PAM‑FIDO2, Jump‑Hosts et stratégies de repli pragmatiques pour l'accès administrateur

Un accès d’administration à distance sécurisé est une condition préalable au fonctionnement fiable. MFA pour SSH, c’est‑à‑dire la combinaison d’une clé publique et d’un deuxième facteur (p. ex. FIDO2/YubiKey), réduit considérablement le risque de mots de passe compromis ou de clés SSH volées. Dans cet article, j’explique comment la technique fonctionne, quelles composantes (YubiKey‑Resident‑Keys, PAM‑FIDO2, OpenSSH, Jump‑Hosts) interagissent, quels pièges et risques apparaissent typiquement et comment planifier de véritables stratégies de secours pour les situations d’urgence. Le public visé est constitué d’admins, de System Engineers et d’équipes d’exploitation à la recherche de procédures sûres et praticables.

Que signifie MFA pour SSH et pourquoi est‑ce important ?

MFA (Multi‑Factor Authentication) est un principe d’authentification reposant sur au moins deux facteurs distincts : quelque chose que l’utilisateur possède (p. ex. un YubiKey) et quelque chose qu’il sait ou détient (une clé SSH privée ou un mot de passe). Pour SSH, cela signifie généralement : authentification par clé publique plus FIDO2/U2F‑Touch ou une seconde étape basée sur PAM. Le bénéfice est concret : même si une clé SSH privée a été exfiltrée, l’absence du token physique empêche l’accès.

MFA pour SSH : éléments centraux et variantes

OpenSSH avec FIDO2‑Resident‑Keys

OpenSSH prend en charge depuis les versions récentes des types de clés comme ed25519-sk, qui utilisent des tokens FIDO2. Les Resident Keys sont des clés privées stockées directement sur le token. Elles remplacent les fichiers de clés locaux et imposent le Touch/PIN lors de l’utilisation du token. L’inconvénient est la dépendance au cycle de vie du token — prévoyez des procédures de remplacement et de récupération.

# 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) est le système d’authentification modulaire sous Linux. Un module PAM‑FIDO2 (p. ex. pam_fido2 ou libpam-u2f) peut être intégré dans /etc/pam.d/sshd pour exiger une authentification SSH supplémentaire en plus de la clé publique. PAM est puissant, mais une mauvaise configuration peut empêcher complètement les connexions — testez donc d’abord dans un environnement isolé.

# 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

Important : le paramètre AuthenticationMethods oblige OpenSSH à exiger d’abord la clé publique puis à déclencher PAM (keyboard‑interactive), qui prend en charge la requête FIDO2. Des ordres erronés ou des modules manquants entraînent des « lockouts ».

Certificats SSH en complément

Les certificats SSH sont des signatures, émises par une CA interne, pour des clés publiques SSH. Ils facilitent la révocation et la gestion centralisée des périodes de validité. En complément de la MFA, ils permettent d’accorder des accès valables à court terme sans distribuer de fichiers sur les postes des utilisateurs — idéal pour des accès d’urgence temporaires.

# 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 (hôte bastion) est un point d’accès contrôlé vers un segment protégé. Il réduit la surface d’attaque et permet une authentification centralisée, l’enregistrement des sessions et le contrôle des accès. Principes opérationnels importants :

• Renforcez le Jump‑Host : pile logicielle minimale, règles strictes de pare‑feu, comptes utilisateurs restreints.
• Imposez le MFA sur le Jump‑Host ; seules les connexions via la bastion doivent pouvoir atteindre les hôtes productifs.
• Enregistrement des sessions et audit : complétez par des enregistrements (p. ex. tty‑recording ou auditd) pour assurer la traçabilité forensique.

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

Le transfert d’agent (Agent Forwarding) doit en principe être désactivé, car il permet à un attaquant, via une machine cible compromise, d’exploiter l’agent. Activez‑le au niveau de la station de travail uniquement et de manière ciblée pour des sessions de confiance.

Configuration pratique de PAM et des tokens : exemples et vérifications

Le mapping PAM pour FIDO2 varie selon le module. Il est courant d’avoir un fichier de mappage qui associe un identifiant de token à une UID Unix. Des exemples aident à identifier les sources d’erreurs potentielles.

# 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

Lors des tests, gardez à l’esprit que les modules PAM écrivent souvent leurs propres journaux de débogage ; n’activez le mode débogage que temporairement afin qu’aucune information sensible ne demeure en permanence dans les fichiers de logs.

Plan de déploiement : du pilote à la production

Un déploiement structuré et par phases minimise les interruptions d’exploitation :

1. Pilote : 2–5 administrateurs, environnement de Jump‑Host de test isolé et liste de contrôle de tests complète.
2. Extension : inclusion de l’équipe d’exploitation, KPI de journalisation et exercices de gestion des incidents.
3. Production : déploiement à l’échelle de l’organisation, formation, processus d’intégration et de sortie opérationnalisés.

Pendant la phase pilote, testez systématiquement :

• La génération et l’utilisation de clés résidentes (Resident Keys).
• Les scénarios d’erreur PAM (jeton défectueux, erreur de PIN) et les entrées de journal associées.
• Les scénarios de secours (Break‑Glass, certificats SSH temporaires, console OOB).

Stratégies de repli en détail — plans, listes de contrôle et automatisation

Une stratégie de repli évite qu’un jeton perdu ou un problème PAM paralyse l’exploitation. De bons plans de repli sont gradués et documentés.

Break‑Glass : déroulement du processus

Un compte Break‑Glass est une identité d’urgence strictement contrôlée. Proposition de déroulé et mesures techniques :

• Maintenir un compte Break‑Glass par service critique, protégé par une copie physique de clé (en coffre) ou par un certificat à validité limitée dans le temps.
• Avant utilisation : approbation via un processus de contrôle à plusieurs yeux défini (p. ex. seconde signature dans le système de tickets) et rotation automatique du mot de passe après utilisation.
• Chaque utilisation est automatiquement auditée et déclenche une chaîne d’alerte (pager/SMS/e‑mail) vers les intervenants d’incident.

Certificats SSH temporaires via un service de signature

Un service de signature automatique (outil interne avec RBAC) peut émettre à court terme des certificats lorsque des tokens font défaut. Implémentez des étapes d’audit et des périodes de validité courtes (p. ex. 15–60 minutes). Un signataire géré par systemd avec des hooks d’authentification suffit souvent.

# 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

Accès OOB physique et console

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:

• Isolieren Sie OOB‑Netze physisch/logisch.
• Erlauben Sie Zugriff auf OOB nur über MFA‑gesicherte Admin‑VMs.
• Patchen Sie Firmware regelmäßig und entfernen Sie default credentials.

Contrôles de dépannage concrets

Si la connexion échoue, un débogage systématique mène rapidement à la cause. Séquence d’exemple :

1. Mode verbeux SSH sur la station de travail : vérifier avec ssh -vvv si la clé sk est proposée.
2. Vérifier les logs du serveur : sudo journalctl -u sshd -b ou /var/log/auth.log.
3. Tester temporairement les modules PAM mit einem separaten PAM‑Kontext oder auf einem Testhost.
4. Vérifier l’état du token : le token est‑il endommagé ? Les tentatives de PIN ont‑elles été dépassées ?

# 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

Gestion du cycle de vie des Tokens

Le cycle de vie des Tokens umfasst l’émission, le remplacement, le blocage et l’élimination. Gérez les Tokens de façon centralisée avec un inventaire, des responsabilités et des fenêtres temporelles :

• Émission : remise documentée avec signature et référence de ticket (p. ex. numéro de ticket Zammad).
• Remplacement : processus standard pour Tokens endommagés ou non réactifs ; émission d’un certificat temporaire pour le réapprovisionnement.
• Blocage : en cas de perte, marquer immédiatement le Token comme compromis et révoquer les certificats SSH et/ou les bindings PAM associés.
• Élimination : effacer le Token de manière sécurisée (si possible) et détruire physiquement lorsqu’il est mis hors service.

Pour l’automatisation, vous pouvez utiliser YubiKey Manager CLI (ykman) pour interroger les informations sur les numéros de série et les slots configurés. Notez toutefois que tous les modèles de Tokens ne supportent pas exactement les mêmes commandes.

# YubiKey Manager: Seriennummer anzeigen
ykman info

Intégration dans les services d’annuaire et CI/CD

Dans de grands environnements, les administrateurs s’authentifient souvent contre LDAP/AD. PAM‑FIDO2 kann parallel zu LDAP‑Bindungen betrieben werden: LDAP liefert Accountinformationen, PAM‑FIDO2 validiert den zweiten Faktor. Veillez à l’ordre dans /etc/pam.d/sshd, afin que les vérifications de compte LDAP ne bloquent pas PAM‑FIDO2.

Les exécutions CI/CD et les automatisations ne doivent pas dépendre de Tokens physiques. Pour les jobs de pipeline, utilisez des comptes machines avec des certificats SSH ou des clés d’hôte, gérés de manière centralisée et à durée limitée. Stockez les secrets dans des Vaults et faites‑les tourner régulièrement.

Pièges typiques et comment les éviter

• Configurations PAM erronées : testez toujours avec un compte administrateur séparé et gardez une console OOB à disposition.
• Modèles de Tokens incompatibles : tous les Tokens FIDO2 ne prennent pas en charge les clés résidentes ; vérifiez la matrice matérielle avant l’achat.
• USB‑Passthrough dans les desktops virtuels : les Tokens ne sont parfois pas transmis de manière fiable ; testez dans vos environnements utilisateurs.
• Agent Forwarding : désactivez‑le, car il peut saper la protection MFA sur la station de travail.

Remarques spécifiques pour les équipes d’exploitation Zammad

Les instances Zammad nécessitent souvent des rôles d’accès différenciés : développeurs, responsables applicatifs, administrateurs de bases de données. Recommandations appliquées de manière pragmatique :

• Exécutez les tâches d’administration spécifiques à Zammad uniquement depuis le bastion et séparez les sessions d’administration DB des déploiements applicatifs.
• Enregistrez les attributions de tokens et les événements Break‑Glass directement dans le ticketing (p.ex. Zammad), afin de préserver les pistes d’audit et le contexte des changements.
• Pour la reprise d’urgence, conservez une procédure définissant comment l’accès à la base de données est accordé avec des droits minimaux et des certificats temporaires — documentée dans le runbook de reprise après sinistre.

{
  "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"
}

Liste de contrôle pour la production (brève)

• Réalisez un pilote avec 2–5 administrateurs et documentez les retours d’expérience.
• Renforcez le jump‑host, imposez le MFA, désactivez l’Agent Forwarding.
• Configurer des certificats SSH temporaires et tester le service de signature.
• Définir des comptes Break‑Glass, implémenter un workflow d’approbation et activer l’audit.
• Vérifier les accès OOB et mener des exercices d’urgence semestriels.

Conclusion et recommandations opérationnelles

L’authentification MFA pour SSH avec YubiKey et PAM‑FIDO2 est une mesure pragmatique qui renforce significativement la sécurité des accès administratifs. L’élément décisif est un déploiement responsable : groupe pilote, processus d’on/offboarding documentés, stratégies de repli testées et journalisation stricte. Pour les équipes d’exploitation Zammad, il convient en plus de séparer strictement les accès, de documenter les attributions de tokens dans le ticketing et d’exercer les procédures de restauration.

Rappel rapide à emporter :

• Définissez un groupe pilote et établissez un environnement de test isolé.
• Testez les OpenSSH‑sk‑Keys et PAM‑FIDO2 en parallèle et validez les logs.
• Renforcez les jump‑hosts, désactivez l’Agent Forwarding par défaut.
• Implémentez et exercez les stratégies de repli (Break‑Glass, OOB, certificats temporaires).
• Intégrez l’inventaire des tokens et les processus de changement dans le ticketing (p.ex. Zammad) et planifiez des exercices d’urgence réguliers.

Au besoin, un atelier ciblé permet de réunir les options techniques, les rôles organisationnels et les playbooks d’urgence, et de les intégrer à vos processus d’exploitation.

Perspectives d’exploitation: protection de la CA, politiques de défaillance et HA du bastion

Outre l’authentification des utilisateurs, l’architecture de hardening et d’exploitation détermine la maturité opérationnelle du MFA‑SSH. Protégez vos clés privées SSH‑CA comme du matériel cryptographique de production : idéalement dans un HSM ou au minimum hors ligne sur un hôte dédié et sécurisé. Établissez un plan de compromis clair : rotation des clés, restauration d’urgence et playbooks de communication en cas de perte de clé.

Les décisions concernant les politiques de défaillance sont critiques : une défaillance du PAM peut soit refuser les connexions (fail‑closed), soit les autoriser (fail‑open). Favorisez le mode fail‑closed avec des voies de repli OOB testées plutôt que des exceptions implicites, car ces dernières compromettent l’audit et la responsabilité.

La haute disponibilité d’un bastion s’obtient par des instances de secours actives, l’enregistrement centralisé des sessions et des services de signature distribués pour les certificats SSH. Ne synchronisez que les métadonnées publiques (CA‑Publickeys, Audit‑Logs) ; les clés privées restent strictement isolées.

Automatisez le cycle de vie des jetons et les certificats d’urgence via votre API de ticketing (p. ex. Zammad) ou votre logiciel d’entreprise sur mesure, afin de relier de manière traçable l’émission, la révocation et l’audit. Surveillez les indicateurs : taux d’erreurs d’authentification, taux de signature, latence PAM et Break‑Glass‑Events — des alertes en cas d’écart sont obligatoires.

# 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

Pour ce sujet, Pam-Fido2 et les Jump-Host sont également importants. L’article replace ces aspects de façon compréhensible et montre ce qui compte au quotidien.