YubiKey et FIDO2 : authentification SSH par clé matérielle

Une clé SSH stockée sur disque, c'est une clé qui peut fuir. Vol de laptop, malware avec accès en lecture, image disque qui finit dans un repo Git par mégarde, dump LSASS sur Windows. Le vecteur a beau être documenté depuis vingt ans, il continue de générer des incidents.

OpenSSH a intégré FIDO2 en 2020 (version 8.2). Une clé matérielle YubiKey ou Token2 stocke le secret cryptographique, exige une touche physique pour signer, et ne peut pas être copiée. Pour les administrateurs systèmes, les développeurs avec accès production, les équipes sécurité qui se connectent à des bastions, c'est le standard 2026.

Ce qui suit est l'opération concrète : générer la clé, la déployer, la révoquer. Pas un cours sur FIDO2.

• Pourquoi FIDO2 pour SSH plutôt qu'une clé classique
• Types de clés YubiKey et Token2 disponibles
• Génération de la clé : ed25519-sk vs ecdsa-sk
• Clé résidente vs clé non-résidente
• Déploiement utilisateur final
• Intégration bastion et serveurs cibles
• Révocation, rotation, perte
• Limites et signaux d'alerte

Trois propriétés que la clé matérielle apporte et qu'une clé fichier n'a pas.

Non-extractibilité. Le secret cryptographique est généré dans le secure element de la clé matérielle, signé là, sorti jamais. Un attaquant qui prend le contrôle du laptop ne peut pas voler la clé. Il peut au mieux l'utiliser tant que la clé est branchée et que l'utilisateur valide chaque connexion par une touche.

User presence. Chaque signature exige une action physique : toucher le contact métallique de la YubiKey, ou appuyer sur le bouton du Token2. Un script qui tente d'enchainer 1000 connexions SSH non supervisées est bloqué net. Pour les sessions sensibles (root sur bastion, accès production), c'est ce qu'on veut.

Multi-protocole. La même YubiKey 5 sert pour SSH FIDO2, WebAuthn (login web), GPG, OTP, OATH-HOTP. Un objet, plusieurs protocoles, durée de vie typique 5+ ans. ROI évident.

Pour le hardening SSH global, FIDO2 est la couche qu'on ajoute au-dessus du reste. Voir aussi SSH bastion MFA pour le pattern bastion.

YubiKey 5 reste le produit dominant. Variantes utiles :

• YubiKey 5 NFC : USB-A + NFC. Pour postes desktop classiques.
• YubiKey 5C NFC : USB-C + NFC. Pour laptops modernes et mobiles.
• YubiKey 5 Nano : USB-A miniature, reste branché en permanence dans un port.
• YubiKey 5C Nano : équivalent USB-C.
• YubiKey Bio : USB-A ou USB-C avec capteur biométrique. Empreinte digitale au lieu de touch contact. Pour les utilisateurs qui ne veulent pas toucher.

Token2 est l'alternative européenne, moins coûteuse, certifiée FIDO2. Compatible OpenSSH FIDO2 sans particularité. Pour des déploiements parc avec contrainte budget, à considérer.

NitroKey 3 (allemand) couvre un segment open hardware avec firmware open source. Bon choix souverain, mais l'écosystème OpenSSH est moins testé.

Recommandation pour un déploiement parc : standardiser sur deux modèles (un USB-A pour les desktops, un USB-C/NFC pour les laptops/mobiles), commander 2 par utilisateur (une principale + une de secours).

OpenSSH supporte deux types de clés FIDO2 :

# Recommandé : ed25519-sk
ssh-keygen -t ed25519-sk -O resident -O verify-required \
           -O application=ssh:work -C "alice@work-laptop"

# Alternative : ecdsa-sk (si firmware YubiKey ancien)
ssh-keygen -t ecdsa-sk -O resident -O verify-required

ed25519-sk est le défaut moderne. Plus rapide, clés plus courtes, mêmes propriétés sécurité.

Options importantes :

• -O resident : la clé est stockée sur la YubiKey (clé résidente). On peut la récupérer plus tard depuis n'importe quel poste avec ssh-keygen -K. Sans cette option, le fichier id_ed25519_sk local doit être conservé.
• -O verify-required : exige le PIN FIDO2 en plus de la touche. Recommandé pour l'authentification production.
• -O application=ssh:work : différencie les usages SSH sur la même clé. Permet d'avoir plusieurs identités SSH sur une seule YubiKey.

Au moment du ssh-keygen, la YubiKey clignote, on touche le contact, la clé est générée. Le secret reste dans la YubiKey. Le fichier ~/.ssh/id_ed25519_sk ne contient qu'un handle, inutilisable sans la clé physique.

Distinction qui compte côté ops.

Non-résidente (-O resident absent). La clé privée est dans la YubiKey, mais la métadonnée d'association est dans le fichier id_ed25519_sk local. Si on perd ce fichier, on a perdu la capacité d'utiliser la clé même si on a toujours la YubiKey. À éviter pour des cas où l'utilisateur change de poste.

Résidente (-O resident). La métadonnée est aussi sur la YubiKey. On peut récupérer la clé sur n'importe quel poste avec ssh-keygen -K. Le poste devient interchangeable. Limite : les YubiKey 5 supportent typiquement 25 clés résidentes. Pour un usage admin avec 100 serveurs, on regroupe par environnement (un seul application=ssh:prod, un seul ssh:dev) et la clé sert pour tous les serveurs du groupe.

Recommandation parc : toujours résidente, avec PIN obligatoire (-O verify-required).

Workflow standard pour ajouter une YubiKey à un poste utilisateur :

1. Installer le firmware FIDO2 récent sur la YubiKey (ykman). Vérifier au moins firmware 5.4+.
2. Définir un PIN FIDO2 : ykman fido access change-pin. PIN entre 6 et 63 caractères, doit être différent du PIN OpenPGP s'il est aussi utilisé.
3. Générer la clé SSH avec ssh-keygen -t ed25519-sk -O resident -O verify-required.
4. Pousser la clé publique dans ~/.ssh/authorized_keys des serveurs cibles, ou dans un IdP centralisé (LDAP, Vault SSH, SSH CA OpenSSH).
5. Tester : ssh user@target. La YubiKey doit clignoter, demander le PIN, demander la touche.
6. Sauvegarder une YubiKey de secours : générer une seconde clé sur la YubiKey backup, pousser sa clé publique dans les mêmes authorized_keys ou la même CA.

Pour un parc, automatiser via un script qui guide l'utilisateur pas à pas. La friction d'install est réelle : compter 15 minutes par utilisateur la première fois.

Sur le serveur SSH, configuration minimale dans sshd_config :

PubkeyAuthentication yes
AuthenticationMethods publickey
PubkeyAcceptedAlgorithms +ssh-ed25519,sk-ssh-ed25519@openssh.com,ssh-ed25519-cert-v01@openssh.com,sk-ssh-ed25519-cert-v01@openssh.com

Pour distinguer les clés FIDO2 des clés classiques, certains opérateurs forcent uniquement sk- algorithms en prod :

PubkeyAcceptedAlgorithms sk-ssh-ed25519@openssh.com,sk-ssh-ed25519-cert-v01@openssh.com

Ainsi, une connexion SSH avec clé classique non-FIDO2 est refusée même si la clé est dans authorized_keys. Le bastion devient FIDO2-only.

Pour un déploiement multi-bastion / multi-serveurs, SSH CA centralisé couplé à FIDO2 est l'architecture cible. La clé YubiKey signe un certificat éphémère via la CA, le certificat porte les principals (utilisateurs autorisés sur quels groupes de serveurs), expire après quelques heures. Plus aucun authorized_keys à gérer côté serveurs.

Pour le contexte SSH avancé (jump hosts, tunnels), SSH avancé tunnels proxy reste valide en complément.

Perte ou compromission. Si une YubiKey est perdue :

1. Révoquer la clé publique côté serveurs : suppression de la ligne dans authorized_keys, ou révocation du certificat dans la CA SSH.
2. Forcer la rotation de la YubiKey de secours (générer une nouvelle clé sur la backup, distribuer la nouvelle pubkey).
3. Si un PIN FIDO2 fort était configuré, le risque immédiat est limité : un attaquant a quelques essais avant que la YubiKey se bloque (typiquement 8 PIN ratés).

Rotation périodique. Pas d'obligation cryptographique de rotation pour une clé ed25519-sk. Mais la rotation symbolique reste utile : remplacement de la YubiKey tous les 3-5 ans, audit des accès résiduels.

Sortie d'un employé. Révocation immédiate côté CA SSH ou authorized_keys central. La YubiKey physique est récupérée à la sortie. Si pas récupérée, révocation suffit.

Documenter. Un runbook clair : "que faire si je perds ma YubiKey", "qui appeler", "comment activer la backup". Pas un wiki abstrait, une page concrète accessible hors VPN.

Compatibilité legacy. OpenSSH < 8.2 ne supporte pas FIDO2. RHEL 7 et Debian 10 sont concernés. Pour les serveurs old-stable, soit on upgrade, soit on utilise une CA SSH qui valide la clé FIDO2 côté bastion et émet un cert classique pour les hosts old-stable.

Headless / automation. Un script de CI ne peut pas toucher une YubiKey. Pour les pipelines, prévoir une identité de service avec une clé classique ou un secret manager dédié (Vault SSH avec OIDC). Ne pas mélanger les deux mondes.

OTP vs FIDO2 vs CCID. Une YubiKey expose plusieurs interfaces : OTP, FIDO2, OpenPGP (CCID), PIV. Si on désactive l'OTP par confusion, on casse les couplages "tap pour générer un OTP" pour des apps non-SSH. Documenter ce qu'on touche.

Limite de clés résidentes. 25 sur YubiKey 5. Si on veut une identité distincte par serveur, on plafonne vite. Standardiser sur quelques applications grouped (dev, staging, prod, perso, gpg).

Bug NFC sur Android. Certains téléphones Android ne reconnaissent pas le tap NFC YubiKey du premier coup. Tester avant de bannir le SSH classique mobile.

Sur les déploiements YubiKey qu'on opère pour nos clients, le ROI sécurité se mesure en incidents évités. Un employé qui se fait voler son laptop ne livre plus la clé SSH au voleur. Un dump disque chez un sous-traitant ne contient plus de clés SSH exploitables. La friction utilisateur disparait au bout de 2-3 semaines, le geste de toucher la YubiKey devient mécanique. Si vous voulez déployer FIDO2 SSH sur un parc de 50+ admins/devs avec un bastion centralisé et une CA SSH, on peut auditer votre cible et opérer le rollout avec runbooks et formation utilisateur.

• OpenSSH FIDO2 documentation : annonce et spécifications de l'intégration.
• Yubico developers - FIDO2 SSH : guide officiel YubiKey pour SSH.
• FIDO Alliance specifications : référence FIDO2/CTAP2.
• Token2 documentation : alternative européenne YubiKey.
• ssh-keygen man page : référence options FIDO2 (-O resident, verify-required, application).
• NIST SP 800-63B Authenticator Assurance : référentiel niveaux d'authentification incluant les clés matérielles.