Gestion des accès SSH : Bannir les mots de passe au profit des clés de sécurité (FIDO2 / YubiKey)

Dans le paysage cybernétique moderne, le protocole SSH (Secure Shell) constitue l’épine dorsale de l’administration système. Pourtant, la méthode d’authentification la plus couramment répandue — le couple identifiant/mot de passe — représente l’un des maillons les plus faibles de la chaîne de sécurité informatique. Attaques par force brute, hameçonnage ciblé, pulvérisation de mots de passe (password spraying) ou réutilisation d’identifiants compromis : les vecteurs d’attaque exploitant cette vulnérabilité sont nombreux et redoutablement efficaces.

L’authentification par clés SSH traditionnelles (RSA ou Ed25519 stockées sur le disque local) a apporté un gain de sécurité majeur, mais elle n’est pas exempte de risques. Un logiciel malveillant exécuté sur le poste d’un administrateur ou une sauvegarde de poste non chiffrée peut entraîner le vol pur et simple de la clé privée. Pour éliminer définitivement ces risques, l’industrie s’oriente désormais vers le modèle Zero Trust Hardware-Bound en s’appuyant sur la norme FIDO2 / WebAuthn via des clés de sécurité physiques comme la YubiKey.

Les limites des méthodes d’authentification traditionnelles

Pour comprendre l’impératif de migration vers FIDO2, il convient de dresser le bilan des faiblesses des mécanismes historiques.

1. Le mot de passe : un risque permanent

L’utilisation de mots de passe pour se connecter à un serveur SSH expose l’infrastructure à :

• Des attaques automatisées continues : Tout serveur exposé sur Internet subit quotidiennement des milliers de tentatives de connexion par mot de passe via des bots.

• L’ingénierie sociale : Un mot de passe peut être saisi par inadvertance sur un portail de hameçonnage imitant une interface d’administration.

• La fatigue décisionnelle : Les utilisateurs ont tendance à réutiliser ou à simplifier leurs mots de passe si aucune contrainte matérielle ne leur est imposée.

2. Les clés SSH classiques stockées sur disque

Bien que nettement supérieures aux mots de passe, les clés RSA ou Ed25519 standards stockées dans le répertoire ~/.ssh/ posent d’autres défis :

• Le vol de clé privée : Un malware (ex: infostealer) présent sur la machine cliente peut lire le fichier id_ed25519 et l’exfiltrer. Même si le fichier est protégé par une phrase explicative (passphrase), celle-ci peut être interceptée par un keylogger.

• La prolifération des clés (Key Sprawl) : Sans gestion centralisée, suivre quelle clé appartient à qui et sur quels serveurs elle est autorisée devient rapidement ingérable.

La révolution FIDO2 et OpenSSH : Comment ça fonctionne ?

Depuis la version 8.2 d’OpenSSH (publiée au début de l’année 2020), le protocole intègre nativement la prise en charge des jetons de sécurité matériels FIDO2 / U2F. Cette intégration repose sur deux nouveaux types de clés :

• ecdsa-sk (ECDSA Security Key)

• ed25519-sk (Ed25519 Security Key — vivement recommandée)

Le suffixe -sk signifie Security Key. Lorsqu’une clé de ce type est générée, la véritable clé privée ne réside jamais sous forme lisible sur le disque dur de l’ordinateur. Elle est soit générée et conservée exclusivement dans le composant cryptographique sécurisé de la YubiKey, soit chiffrée par le composant matériel sous la forme d’un key handle.

Les mécanismes de protection intégrés

1. Pression physique obligatoire (User Presence) : Lors de chaque tentative de connexion SSH, la YubiKey clignote. L’utilisateur doit toucher physiquement le capteur de la clé pour valider la transaction. Un logiciel malveillant distant ne peut pas simuler cette interaction physique.

2. Code PIN / Biométrie (User Verification) : FIDO2 permet d’exiger la saisie d’un code PIN local configuré sur la YubiKey ou une empreinte digitale (pour les modèles YubiKey Bio). Il s’agit d’un véritable facteur d’authentification multifacteur (MFA) matériel : ce que j’ai (la clé physique) + ce que je sais/ce que je suis (le PIN ou l’empreinte).

3. Résistance au hameçonnage : Les mécanismes FIDO2 lient l’authentification à l’identité du matériel et au contexte, rendant les attaques par relais (Man-in-the-Middle) inopérantes.

Clés résidantes (Resident Keys) vs Clés non-résidantes

OpenSSH et FIDO2 proposent deux modes de fonctionnement distincts :

PortabilitéIl faut copier le fichier de clé publique/stump sur la machine cliente.Cas d’usagePoste de travail fixe d’un administrateur.

Guide pratique de mise en œuvre

Étape 1 : Générer la clé SSH FIDO2 sur la YubiKey

Sur la machine cliente (qui doit disposer d’OpenSSH 8.2 ou supérieur et des bibliothèques libfido2), exécutez la commande suivante :

# Génération d'une clé Ed25519 sécurisée par matériel (mode résidant recommandé)
ssh-keygen -t ed25519-sk -O resident -O verify-required -C "admin-secu@entreprise.com"

Explication des options :

• -t ed25519-sk : Spécifie le type d’algorithme sécurisé par matériel.

• -O resident : Enregistre la clé dans le composant interne de la YubiKey pour pouvoir la récupérer sur n’importe quel poste.

• -O verify-required : Force la vérification du code PIN de la YubiKey lors de chaque signature SSH (MFA strict).

Lors de l’exécution, le système vous demandera d’entrer le code PIN de votre YubiKey, puis de toucher le capteur lumineux.

Étape 2 : Déployer la clé publique sur le serveur cible

Comme pour une clé classique, copiez la clé publique générée (~/.ssh/id_ed25519_sk.pub) sur le serveur distant dans le fichier ~/.ssh/authorized_keys de l’utilisateur concerné :

ssh-copy-id -i ~/.ssh/id_ed25519_sk.pub user@serveur-distant.com

Étape 3 : Endurcir la configuration du serveur SSH (sshd_config)

Une fois la clé configurée et la connexion validée, il est impératif de désactiver totalement l’authentification par mot de passe sur le serveur. Éditez le fichier /etc/ssh/sshd_config :

# Désactivation totale des mots de passe
PasswordAuthentication no
ChallengeResponseAuthentication no
KbdInteractiveAuthentication no

# Interdiction de la connexion root par mot de passe
PermitRootLogin prohibit-password

# Exigence stricte des types de clés autorisés (optionnel mais recommandé)
PubkeyAcceptedKeyTypes sk-ssh-ed25519@openssh.com,sk-ecdsa-sha2-nistp256@openssh.com

Rechargez ensuite le service SSH pour appliquer les modifications :

sudo systemctl reload sshd

Gestion de la résilience et des cas de perte

L’une des réticences majeures lors du passage aux clés physiques concerne la perte, le vol ou la détérioration de la YubiKey. Une stratégie d’accès basée sur la clé physique doit obligatoirement inclure un plan de secours :

1. La règle des deux clés (Primary & Backup) : Tout administrateur doit configurer au minimum deux YubiKeys physiques. La clé principale est portée au quotidien, tandis que la clé de secours est conservée dans un coffre-fort physique sécurisé. Les deux clés publiques sont inscrites dans le fichier authorized_keys.

2. L’utilisation de certificats SSH (OpenSSH CA) : Pour les infrastructures d’envergure, plutôt que de copier des clés publiques sur des milliers de serveurs, il est préférable de déployer une Autorité de Certification (CA) SSH. La CA signe la clé publique temporaire de l’administrateur après validation par la YubiKey.

3. Accès d’urgence d’infrastructures (Break-Glass) : Conserver un accès d’urgence hors-ligne (ex: console KVM/IPMI protégée par un mot de passe maître complexe stocké sous scellé) pour parer à tout blocage.

Bilan : Un alignement parfait sur les exigences NIS 2 et Zero Trust

En éliminant les mots de passe au profit des clés de sécurité matérielles FIDO2 / YubiKey, les organisations réduisent drastiquement leur surface d’attaque. Cette démarche s’inscrit pleinement dans les architectures de sécurité modernes Zero Trust et répond aux exigences de renforcer la sécurité des accès à privilèges imposées par les réglementations européennes telles que NIS 2. Le coût modéré d’un jeton physique est infiniment inférieur à celui d’une compromission globale issue d’un vol d’identifiant SSH.

Pourquoi faire appel à un infogérant pour gérer vos accès FIDO2 / YubiKey ?

Bien que la technologie FIDO2 soit redoutablement efficace, sa mise en œuvre à l’échelle d’une entreprise implique des défis organisationnels et techniques. Faire appel à un expert en infogérance permet de sécuriser cette transition.

1. Expertise technique et intégration sur mesure

Un prestataire spécialisé en infogérance vous accompagne dans l’audit de votre parc (serveurs Linux, instances Cloud AWS/GCP/Azure) pour concevoir une politique d’accès Zero Trust conforme aux exigences de l’ANSSI et aux directives européennes (NIS 2, DORA).

2. Déploiement d’une Autorité de Certification SSH (CA SSH)

Au lieu de copier manuellement des clés sur chaque serveur, un infogérant met en place une PKI / CA SSH. Les administrateurs obtiennent des certificats éphémères signés via leur YubiKey, garantissant un contrôle d’accès dynamique et la suppression des accès résiduels.

3. Gestion de la perte de clé et plan de secours (Break-Glass)

Le risque principal lié aux clés physiques est la perte ou le vol du jeton. L’infogérant garantit la continuité d’activité grâce à :

• La mise en place de clés YubiKey de secours (Backup Keys) stockées sous scellé.

• Des procédures d’urgence sécurisées pour restaurer les accès sans compromettre la sécurité globale.

4. Supervision 24/7 et maintien en condition de sécurité (MCS)

Un infogérant centralise l’analyse des journaux de connexion (logs SSH), détecte les anomalies en temps réel et assure la mise à jour continue de vos serveurs pour pare-feu et configurations OpenSSH.

En résumé : Passez au Passwordless SSH

L’association d’OpenSSH et des clés de sécurité matérielles FIDO2 / YubiKey supprime définitivement le maillon faible du mot de passe. En confiant cette transition et le maintien de votre infrastructure à un prestataire d’infogérance, vous bénéficiez d’une sécurité maximale, d’une conformité réglementaire assurée et d’une gestion sereine au quotidien.