L’audit de sécurité interne a mis un chiffre embarrassant sur la table : sur les neuf développeurs ayant accès en SSH au parc de serveurs de l’agence, trois utilisaient une clé SSH générée il y a plus de quatre ans, dont l’historique de circulation entre anciens ordinateurs, sauvegardes et parfois messages Slack était impossible à reconstituer avec certitude. Une clé SSH classique, une fois exportée dans un fichier, peut être copiée, sauvegardée ailleurs, ou oubliée sur une machine désaffectée sans que personne ne s’en rende compte.
Ce constat ne concerne volontairement pas les passkeys utilisées pour l’authentification des utilisateurs WordPress eux-mêmes, sujet traité par ailleurs côté sécurité applicative. Il porte uniquement sur l’accès SSH des développeurs de l’agence au parc de serveurs, un périmètre différent mais tout aussi sensible : une seule clé compromise peut donner accès à l’ensemble des sites clients hébergés.
Ce qu’apporte une passkey face à une clé SSH classique
Une clé SSH classique, même protégée par une phrase de passe, reste un fichier : elle peut être copiée d’une machine à l’autre, exportée, ou exfiltrée si la machine du développeur est compromise. Une passkey, au sens strict du standard FIDO2/WebAuthn, génère une paire de clés dont la partie privée ne quitte jamais l’élément matériel sécurisé qui l’a créée (une clé de sécurité physique de type YubiKey, ou l’enclave sécurisée d’un ordinateur récent). Techniquement impossible à exporter, elle élimine le risque de copie silencieuse qui affecte une clé SSH classique stockée en fichier.
Le support natif dans OpenSSH
Depuis OpenSSH 8.2, publié en 2020, le protocole supporte nativement les clés de sécurité FIDO2 via les types de clé ecdsa-sk et ed25519-sk (le suffixe -sk signifiant security key). Cette prise en charge native évite de dépendre d’un logiciel tiers pour faire le pont entre la clé de sécurité physique et le client SSH.
# Génération d'une clé liée à une clé de sécurité physique
ssh-keygen -t ed25519-sk -O resident -O verify-required \
-f ~/.ssh/id_ed25519_sk_prenom
# Options clés :
# -O resident : la clé est stockée sur le dispositif physique lui-même
# -O verify-required : exige une vérification (PIN ou biométrie) à chaque usageL’option -O resident stocke un résumé de la clé directement sur le dispositif physique, ce qui permet de la retrouver même sans accès au fichier public généré sur la machine d’origine, un atout en cas de changement d’ordinateur. L’option -O verify-required impose une vérification supplémentaire (code PIN de la clé de sécurité, ou empreinte biométrique) à chaque connexion, empêchant qu’un simple vol physique de la clé de sécurité suffise à usurper l’accès.
Déploiement sur le parc de serveurs
Côté serveur, la migration a consisté à ajouter la clé publique de type -sk de chaque développeur au fichier authorized_keys habituel, exactement comme pour une clé SSH classique, ce qui n’a nécessité aucune modification de la configuration serveur elle-même :
- Chaque développeur génère sa propre paire de clés liée à sa clé de sécurité physique personnelle.
- La clé publique générée est ajoutée au fichier
authorized_keysde chaque serveur du parc via le système de gestion de configuration déjà en place. - Les anciennes clés SSH classiques sont retirées progressivement, serveur par serveur, une fois la nouvelle clé validée fonctionnelle pour chaque développeur.
Le cas de la révocation immédiate
Le bénéfice le plus concret constaté après la migration concerne le départ d’un développeur : avec une clé SSH classique potentiellement copiée sur plusieurs machines personnelles au fil des années, la certitude de révocation complète était toujours incertaine. Avec une passkey liée à un dispositif physique unique remis par l’entreprise, la révocation consiste simplement à retirer l’entrée authorized_keys correspondante et à récupérer physiquement la clé de sécurité, sans se demander si une copie existe ailleurs.
| Aspect | Clé SSH classique | Passkey (FIDO2/sk) |
|---|---|---|
| Exportable en fichier copiable | Oui | Non, liée au matériel |
| Vérification supplémentaire à l’usage | Phrase de passe optionnelle | PIN ou biométrie, imposable |
| Certitude de révocation complète | Faible si copies possibles | Forte, dispositif physique unique |
Une clé SSH qu’on ne peut pas copier n’est pas une contrainte pour le développeur, c’est une garantie pour l’agence entière : le jour d’un départ, personne n’a plus à se demander où cette clé a pu circuler au fil des années.
Ce que cette migration n’a pas résolu
Cette mise en place ne dispense pas d’une gestion rigoureuse des comptes serveur eux-mêmes : un compte partagé entre plusieurs développeurs, ou un accès root direct plutôt qu’un compte nominatif avec élévation via sudo, reste un problème distinct que la passkey seule ne règle pas. Chaque développeur du parc dispose désormais d’un compte nominatif propre, avec sa passkey associée, ce qui permet également une traçabilité précise des connexions dans les journaux d’authentification.
En résumé
Remplacer les clés SSH classiques par des passkeys liées au matériel a réglé un problème structurel que l’agence traînait depuis plusieurs années : l’incertitude sur la circulation réelle des clés d’accès entre développeurs et machines. Le support natif d’OpenSSH depuis la version 8.2 a rendu cette migration possible sans changement de configuration côté serveur, avec un bénéfice immédiat et mesurable au moment de la révocation d’un accès.
