Rédigé par Rédaction CyberSDF / 17 September 2026 / mis à jour 18 September 2026

Authentification forte sur SSH avec une clé FIDO2

Verdict. Pour un accès SSH d’administration, une clé FIDO2 est le choix le plus solide: la clé privée reste dans le matériel et la connexion demande sa présence, puis un toucher ou un PIN. Elle demande une clé compatible et une voie de secours avant de désactiver le mot de passe.

L’authentification forte ne consiste pas à ajouter un symbole au mot de passe. Elle combine des preuves différentes: ce que vous savez, ce que vous possédez ou ce que vous êtes. Sur SSH, la paire de clés apporte déjà une meilleure base qu’un mot de passe réutilisé. Une clé FIDO2 ajoute un composant matériel qui signe le défi envoyé par le serveur sans exporter le secret.

Le choix se fait sur la preuve disponible au moment de la connexion

Pour choisir sans jargon, demandez-vous ce que l’utilisateur doit encore avoir en main lorsque l’accès est ouvert. Un code temporaire peut être recopié depuis une application; une clé FIDO2 doit être présente et touchée. Pour un serveur SSH, le critère technique est le support des types de clés FIDO par le client et le serveur OpenSSH.

Une clé FIDO2 n’est pas automatiquement une authentification à deux facteurs. Sans PIN, elle prouve surtout la possession du matériel et la présence de l’utilisateur. Avec un PIN, la connexion combine la clé physique et une connaissance mémorisée. Pour exiger en plus un second échange géré par PAM, OpenSSH accepte par exemple AuthenticationMethods publickey,keyboard-interactive:pam; cette ligne ne configure pas le module TOTP à votre place.

La commande locale donne un repère avant de toucher au serveur

Un contrôle local effectué le 17 septembre 2026 sous Ubuntu a utilisé OpenSSH 9.6p1. Une clé Ed25519 temporaire a été créée avec ssh-keygen, puis lue avec ssh-keygen -lf: la sortie indiquait 256 bits, le type ED25519 et un fichier privé en mode 600. Les fichiers temporaires ont ensuite été supprimés.

$ ssh -V
OpenSSH_9.6p1 Ubuntu-3ubuntu13.19, OpenSSL 3.0.13 30 Jan 2024

$ ssh-keygen -lf ~/.ssh/id_ed25519.pub
256 SHA256:... (ED25519)

Ce contrôle porte sur l’outillage local et la protection élémentaire d’une clé; l’essai FIDO2 exige une clé branchée.

Pour une clé SSH classique, commencez par préparer une connexion SSH par clé, puis revenez ici si le matériel FIDO2 vous convient.

Créer une clé FIDO2 côté client

Branchez la clé, gardez une session SSH déjà ouverte sur le serveur et travaillez dans un second terminal. Le premier accès existant sert de filet de sécurité pendant toute la bascule.

1. Créez le répertoire SSH et protégez-le si nécessaire:

   mkdir -p ~/.ssh
   chmod 700 ~/.ssh

2. Générez une clé Ed25519 protégée par le matériel et la présence:

   ssh-keygen -t ed25519-sk -f ~/.ssh/id_ed25519_sk

   Cette commande demande la présence de la clé, généralement par un toucher, mais elle n’impose pas la vérification par PIN. Le fichier id_ed25519_sk est un identifiant utilisable par OpenSSH; la clé privée reste dans l’authenticator.

   Pour exiger un PIN en plus du toucher, utilisez une clé FIDO2 configurée avec un PIN et l’option -O verify-required:

   ssh-keygen -t ed25519-sk -O verify-required -f ~/.ssh/id_ed25519_sk_pin

   Cette variante lie la clé à la vérification de l’utilisateur; l’authenticator et la version d’OpenSSH doivent accepter cette option.

3. Affichez l’empreinte de la clé publique avant de l’installer:

   ssh-keygen -lf ~/.ssh/id_ed25519_sk.pub

Pour une clé résidente, qui pourra être récupérée depuis le matériel sur un autre poste, ajoutez les options documentées par OpenSSH:

ssh-keygen -t ed25519-sk \
  -O resident \
  -O application=ssh:serveur-exemple \
  -f ~/.ssh/id_ed25519_sk

La variante résidente demande en général un PIN FIDO2 et un authenticator qui sait conserver ce type d’identifiant. La commande ssh-keygen -K sert ensuite à récupérer les clés résidentes sur une nouvelle machine. N’envoyez jamais le fichier privé d’un autre poste pour contourner cette étape.

Installer la clé publique sans fermer la porte actuelle

Ajoutez uniquement le fichier public au compte distant. Si l’accès par mot de passe ou par clé classique fonctionne encore, ssh-copy-id évite de retaper la ligne dans authorized_keys:

ssh-copy-id -i ~/.ssh/id_ed25519_sk.pub admin@serveur-exemple

Le fichier envoyé commence par un type tel que sk-ssh-ed25519@openssh.com. Il peut cohabiter avec les clés déjà présentes. Ne remplacez pas authorized_keys en bloc: une erreur à cet endroit coupe les accès de secours.

Testez ensuite une commande non destructive en imposant cette identité:

ssh -o IdentitiesOnly=yes \
  -i ~/.ssh/id_ed25519_sk \
  admin@serveur-exemple 'printf "connexion-ok\n"'

Le résultat attendu est connexion-ok après la demande de présence prévue par la clé. En cas d’échec, relancez avec -vv et regardez si le client propose bien le fichier id_ed25519_sk, si le serveur accepte le type sk-ssh-ed25519@openssh.com et si la clé matérielle est visible par le système.

Rendre la connexion reproductible

Une entrée dédiée dans ~/.ssh/config évite de mélanger les identités lorsque plusieurs serveurs sont utilisés:

Host serveur-admin
    HostName serveur-exemple
    User admin
    IdentityFile ~/.ssh/id_ed25519_sk
    IdentitiesOnly yes

Protégez le fichier qui contient ce réglage:

chmod 600 ~/.ssh/config

La commande devient alors:

ssh serveur-admin

Le serveur ne reçoit jamais la clé privée. Il vérifie une signature produite en réponse à son défi; la clé FIDO2 ne remet pas le secret au système client. C’est la différence importante avec une clé SSH classique copiée dans un fichier.

Passer du test à la règle serveur

Quand la nouvelle connexion fonctionne dans un second terminal, vérifiez la configuration avant de recharger SSH:

sudo sshd -t
sudo systemctl reload ssh

Pour imposer une clé publique sans mot de passe, la directive courante est:

AuthenticationMethods publickey

Pour exiger une clé publique puis une étape interactive fournie par PAM, utilisez:

AuthenticationMethods publickey,keyboard-interactive:pam

Dans les deux cas, gardez la session actuelle ouverte, testez un nouveau terminal et conservez une deuxième clé enregistrée. Ne désactivez PasswordAuthentication qu’après ces contrôles et après avoir vérifié que le compte de secours suit la même règle.

Le test de syntaxe sshd -t ne redémarre pas le service. Le rechargement applique la configuration aux nouvelles connexions tout en laissant la session déjà ouverte continuer; c’est le moment de corriger une erreur sans vous enfermer dehors.

Préparer la perte ou le remplacement de la clé

Enregistrez deux clés FIDO2 distinctes sur le compte administrateur, dans deux lieux séparés. Étiquetez-les par leur empreinte publique, pas par un secret:

ssh-keygen -lf ~/.ssh/id_ed25519_sk.pub

Si une clé disparaît, retirez sa ligne de ~/.ssh/authorized_keys depuis l’autre accès, puis testez la clé conservée. Une clé publique peut être révoquée sans modifier la clé de remplacement. Pour une clé résidente, conservez aussi le PIN dans le gestionnaire prévu à cet effet et ne le notez pas à côté du matériel.

Pour le reste du serveur, la méthode de durcissement minimal sous Linux complète cette étape. Les commandes liées aux services et aux journaux sont rassemblées dans l’administration Debian.

Les références qui tranchent les détails

La page Yubico sur SSH et FIDO2 décrit la génération, le PIN et les clés résidentes. La documentation ssh-keygen d’OpenBSD fait foi pour les options ed25519-sk, resident et application. La section AuthenticationMethods de sshd_config précise la différence entre une méthode unique et une suite de méthodes.