Passkeys SSH avec FIDO2 : se connecter sans clé privée exposée

Une clé SSH FIDO2 réduit le risque de vol d’une clé privée : le secret cryptographique reste dans le jeton matériel, et copier le fichier situé dans ~/.ssh ne suffit pas à se connecter. Pour les accès humains d’administration, elle s’utilise simplement en branchant ou en approchant la clé, puis en la touchant.

Dans OpenSSH, ces clés sont nommées ed25519-sk ou ecdsa-sk, où « sk » signifie security key. Le terme « passkey » est parfois employé par analogie, mais il s’agit ici d’identifiants SSH reposant sur FIDO2, et non nécessairement de passkeys WebAuthn utilisées dans un navigateur.

Protection et prérequis

Avec une clé SSH classique, le fichier privé local est le secret à protéger. Une sauvegarde mal contrôlée, un poste compromis ou une copie dans un dépôt peut exposer cet accès, même si la clé est protégée par une phrase de passe.

Avec FIDO2, la signature est créée dans le périphérique et le secret cryptographique ne quitte pas la clé. OpenSSH demande par défaut une présence utilisateur, généralement un contact physique ; cela ne protège toutefois pas contre un poste déjà contrôlé lorsqu’un utilisateur branche et touche le jeton.

Le serveur doit utiliser OpenSSH 8.2 ou une version plus récente pour accepter les types de clés de sécurité introduits par OpenSSH. Le client Linux doit disposer d’un OpenSSH compilé avec une prise en charge FIDO2 et d’un jeton compatible, par exemple certaines clés YubiKey, SoloKeys ou Nitrokey.

Vérifiez la version du client avec ssh -V, puis créez une clé sur un poste pilote. Si aucun périphérique n’est détecté, consultez la documentation de la distribution et du fabricant ; fido2-tools fournit notamment fido2-token, qui liste les jetons avec fido2-token -L.

Le serveur n’a pas besoin d’accéder au jeton ni d’installer une bibliothèque FIDO2 : il vérifie la signature SSH reçue comme pour une clé publique classique. Les options sont détaillées dans le manuel de ssh-keygen.

Création et test

Branchez le jeton sur le poste d’administration, puis créez l’identité. Le type ed25519-sk est le choix courant lorsque le matériel le prend en charge.

Créez la clé : ssh-keygen -t ed25519-sk -f ~/.ssh/id_ed25519_sk -C "admin@poste-fido2".
Conservez le fichier public généré : ~/.ssh/id_ed25519_sk.pub.
Ajoutez cette clé publique dans ~/.ssh/authorized_keys du compte concerné sur le serveur.

Si l’ancien accès SSH fonctionne encore, utilisez ssh-copy-id -i ~/.ssh/id_ed25519_sk.pub admin@serveur. Sinon, ajoutez la ligne publique par la procédure habituelle d’administration de comptes ou de gestion de configuration.

Testez depuis une seconde session de terminal, sans fermer l’accès existant : ssh -i ~/.ssh/id_ed25519_sk -o IdentitiesOnly=yes admin@serveur. La demande de toucher et une connexion réussie confirment que le serveur accepte la clé.

Déploiement et règles d’usage

Déployez la clé FIDO2 serveur par serveur : commencez avec un administrateur pilote, validez l’accès depuis son poste habituel et un poste de remplacement, puis généralisez. Ne retirez les anciennes clés qu’après ces tests et après avoir consigné le propriétaire de chaque clé dans authorized_keys.

Gardez temporairement une clé SSH classique de secours, distincte et protégée par une phrase de passe robuste.
Conservez un accès de récupération documenté, par exemple une console d’hébergeur ou un accès hors bande.
Attribuez un jeton à chaque administrateur ; ne partagez ni jeton ni compte Unix.

Pour les comptes les plus sensibles, ajoutez -O verify-required lors de la génération : ssh-keygen -t ed25519-sk -O verify-required -f ~/.ssh/id_ed25519_sk_admin. Cette option exige que le jeton prenne en charge la vérification utilisateur, généralement par PIN ; testez donc le matériel réellement acheté.

Évitez l’option qui supprime la demande de toucher, car elle annule une part essentielle de la protection pour les accès administrateurs. En cas de perte du jeton, créez une nouvelle clé, retirez la clé publique correspondante des serveurs et appliquez votre procédure de révocation.

Une clé FIDO2 peut être utilisée sur un nouveau poste si le fichier d’identité local a été conservé ou si des identifiants résidents compatibles sont récupérables avec ssh-keygen -K. Cette fonction dépend du jeton et doit être testée ; elle ne remplace pas une procédure de secours validée.

Les clés FIDO2 avec toucher conviennent aux accès humains, mais généralement pas aux automatisations CI, sauvegardes ou déploiements non interactifs. Pour ces usages, séparez les identités, limitez leurs droits et appliquez les restrictions du format authorized_keys plutôt que de contourner la présence utilisateur.