Une clé SSH ed25519-sk est une clé Ed25519 dont l'opération de signature s'effectue à l'intérieur d'une clé de sécurité FIDO2. Vous la créez avec ssh-keygen -t ed25519-sk. Elle exige un toucher sur la clé à chaque connexion et ne fonctionne que si le client et le serveur utilisent OpenSSH 8.2 ou une version ultérieure, publiée en février 2020.
En quoi une clé OpenSSH ed25519-sk diffère d'une clé Ed25519 classique
OpenSSH prend en charge Ed25519 depuis la version 6.5 (janvier 2014) et la variante FIDO2 ed25519-sk depuis la 8.2 (février 2020). La différence tient à l'endroit où se trouve le secret. Avec une clé Ed25519 classique, ~/.ssh/id_ed25519 est la clé privée : quiconque la copie et connaît la phrase de passe peut se connecter à vos serveurs.
Avec ed25519-sk, la signature est calculée à l'intérieur de la clé matérielle. Le fichier que ssh-keygen écrit sur le disque, id_ed25519_sk, est un identifiant de clé (key handle) inutilisable sans l'appareil physique. Chaque authentification exige en outre la présence de l'utilisateur : un toucher sur la clé. Voler l'ordinateur portable ou le fichier ne suffit plus.
Ce qui ne change pas : la clé publique va dans authorized_keys comme d'habitude, désormais avec le type [email protected], et les permissions attendues restent les mêmes : ~/.ssh en 700, authorized_keys et les fichiers de clé en 600.
Comment générer une clé ed25519-sk avec ssh-keygen, étape par étape
La commande de base est ssh-keygen -t ed25519-sk avec la clé FIDO2 branchée ; ssh-keygen vous demande de la toucher pendant la génération. Toutes les options -O sont décrites dans la page de manuel officielle de ssh-keygen.
# Non-resident key: the handle stays in ~/.ssh/id_ed25519_sk
ssh-keygen -t ed25519-sk -C "work-key"
# Resident key, PIN required, with its own label
ssh-keygen -t ed25519-sk -O resident -O verify-required -O application=ssh:production
# Install the public key on the server
ssh-copy-id -i ~/.ssh/id_ed25519_sk.pub user@server
# On another machine: pull the resident keys off the token
ssh-keygen -K
# Or load them straight into ssh-agent
ssh-add -KLes options que vous utiliserez réellement :
- -O resident : stocke l'identifiant sur le token afin de pouvoir le récupérer sur une autre machine.
- -O verify-required : en plus du toucher, exige le code PIN du token pour chaque signature.
- -O application=ssh:nom : permet de distinguer plusieurs clés résidentes sur un même token ; la valeur doit commencer par
ssh:. - -O no-touch-required : supprime le toucher, mais le serveur ne l'accepte que si la ligne de
authorized_keysporte l'optionno-touch-required.
-O resident sur ed25519-sk : la clé voyage dans le token FIDO2
Avec -O resident, l'identifiant est stocké sur le token FIDO2 lui-même, et pas seulement dans le fichier local. Sur une nouvelle machine, branchez le token et lancez ssh-keygen -K, qui écrit les fichiers dans le répertoire courant, ou ssh-add -K pour le charger dans l'agent sans rien écrire sur le disque.
L'avantage est que vous ne dépendez plus du fichier de chaque machine. Le risque en est le reflet : quiconque détient le token peut en extraire l'identifiant, protégez-le donc avec un code PIN et associez -O resident à -O verify-required. Sans -O resident, perdre id_ed25519_sk signifie perdre l'accès depuis cette machine, même si vous avez toujours le token. Les tokens qui n'implémentent que U2F ne peuvent pas stocker d'identifiants résidents.
Quels serveurs acceptent les clés ed25519-sk : OpenSSH 8.2 ou ultérieur
Un serveur accepte les clés ed25519-sk si son sshd est OpenSSH 8.2 ou une version ultérieure. Le serveur n'a besoin d'aucun token branché ; il doit seulement comprendre le type de clé [email protected]. Vérifiez avant de retirer votre clé actuelle :
# OpenSSH version installed on the server
ssh -V
# Public key algorithms sshd actually accepts
sudo sshd -T | grep -i pubkeyaccepted
# ~/.ssh/authorized_keys line that also requires a PIN
verify-required [email protected] AAAA... work-keySi [email protected] apparaît dans la sortie de sshd -T, la clé fonctionnera. Pour exiger un code PIN de tous les utilisateurs, ajoutez PubkeyAuthOptions verify-required à sshd_config. Un serveur antérieur à la 8.2 est aussi antérieur à la 8.8, la version qui a désactivé par défaut les signatures SHA-1 ssh-rsa : sa mise à jour se fait donc attendre de toute façon. La page des notes de version d'OpenSSH indique ce qui a été livré dans chaque version.
Clés ed25519-sk contre clés Ed25519 sur un téléphone : tableau comparatif
Sur un ordinateur, ed25519-sk fonctionne avec n'importe quel OpenSSH 8.2 ou ultérieur et un token branché ; sur iOS et Android, cela dépend de l'implémentation de FIDO2 par le client et de la façon dont le token se connecte au téléphone. L'alternative mobile habituelle est une clé Ed25519 générée sur l'appareil lui-même.
| Élément comparé | ed25519-sk sur ordinateur | Ed25519 dans le stockage sécurisé du téléphone |
|---|---|---|
| Où se trouve le secret | Dans le token FIDO2 | Dans le stockage sécurisé d'iOS ou d'Android |
| Ce qu'il faut pour se connecter | Le token branché et un toucher | Le téléphone qui contient la clé |
| OpenSSH minimal sur le serveur | 8.2 (février 2020) | 6.5 (janvier 2014) |
| Si quelqu'un copie le fichier | Inutile sans le token physique | Dans termi1, la clé privée ne quitte jamais l'appareil |
| Utiliser la clé sur une autre machine | Avec -O resident et ssh-keygen -K | Générer une clé distincte par appareil |
termi1, le terminal SSH pour iOS et Android, suit le second modèle : il génère la clé sur le téléphone, la conserve dans le stockage sécurisé du système et n'envoie jamais la clé privée aux serveurs de termi1 ; l'IA n'ouvre pas non plus la session et ne reçoit pas de clés. Une configuration raisonnable consiste à avoir une clé ed25519-sk pour l'ordinateur portable plus une clé par téléphone dans authorized_keys, afin de ne révoquer que celle que vous perdez. Avec Mosh, l'authentification n'a lieu que lors de la connexion SSH initiale qui lance mosh-server ; passer du Wi-Fi aux données mobiles ne la déclenche pas à nouveau, et tmux conserve tout ce que vous avez laissé en cours d'exécution.
4 erreurs lors de la configuration de clés ed25519-sk avec OpenSSH
- Serveur antérieur à OpenSSH 8.2. sshd ne reconnaît pas le type de clé et la rejette ; gardez votre ancienne clé tant que vous n'avez pas vérifié la version.
- Un seul token FIDO2 enregistré. S'il est perdu ou tombe en panne, votre accès disparaît avec lui. Enregistrez deux tokens, ou un token plus une clé de secours.
- Supprimer id_ed25519_sk pour une clé non résidente. Sans
-O resident, il est impossible de la récupérer depuis le token ; sauvegardez-la ou créez la clé en mode résident. - Fermer l'ancienne session avant de tester. Ouvrez une seconde connexion avec
ssh -i ~/.ssh/id_ed25519_sk user@serveravant de modifiersshd_config.
Questions fréquentes
Quelle version d'OpenSSH faut-il pour les clés ed25519-sk ?
Les clés ed25519-sk exigent OpenSSH 8.2 ou une version ultérieure, publiée en février 2020, à la fois sur le client qui crée et utilise la clé et sur le serveur qui la vérifie. Vérifiez la version installée avec ssh -V et les algorithmes acceptés par le serveur avec sshd -T.
Que fait -O resident dans ssh-keygen ?
L'option -O resident de ssh-keygen stocke l'identifiant FIDO2 sur la clé de sécurité elle-même, ce qui permet de le récupérer sur une autre machine avec ssh-keygen -K ou de le charger dans l'agent avec ssh-add -K. Il vaut mieux la combiner avec un code PIN sur le token et -O verify-required.
Peut-on voler une clé ed25519-sk en copiant le fichier ?
Une clé ed25519-sk ne peut pas être utilisée en copiant uniquement le fichier id_ed25519_sk, car ce fichier n'est qu'un identifiant de clé et la signature est calculée à l'intérieur du token FIDO2. La connexion exige l'appareil physique et, par défaut, un toucher à chaque authentification.
Peut-on utiliser des clés SSH FIDO2 depuis un téléphone ?
L'utilisation de clés SSH FIDO2 sur iOS ou Android dépend de la prise en charge d'ed25519-sk par le client mobile et de la façon dont le token se connecte au téléphone. L'alternative courante est une clé Ed25519 générée sur l'appareil et conservée dans son stockage sécurisé, comme le fait termi1.