Les mots de passe SSH sont le maillon faible de la plupart des serveurs exposés sur Internet. Un serveur fraîchement installé reçoit des milliers de tentatives de connexion par force brute en quelques heures, et il suffit d’un mot de passe réutilisé pour qu’un attaquant prenne le contrôle. L’authentification par clé règle ce problème : à la place d’un secret partagé que l’on peut deviner, vous prouvez votre identité avec une clé cryptographique impossible à brute-forcer. La commande ssh-keygen, livrée avec OpenSSH, génère cette paire de clés en quelques secondes.
Ce tutoriel vous guide en 12 étapes, de la génération d’une clé Ed25519 jusqu’au durcissement complet du serveur, en passant par la désactivation des mots de passe, les clés matérielles FIDO2 et l’échange de clés post-quantique introduit dans OpenSSH. Comptez environ 20 minutes pour un poste de travail Linux, macOS ou Windows et un serveur distant. Toutes les commandes sont prêtes à copier, avec des exemples de sortie et un dépannage détaillé des erreurs les plus fréquentes.
Authentification SSH par clé : ce qui change en 2026
L’authentification par clé publique repose sur une paire asymétrique : une clé privée que vous gardez sur votre machine et une clé publique que vous déposez sur le serveur. Lors de la connexion, le serveur envoie un défi que seule la clé privée peut résoudre. Le secret ne transite jamais sur le réseau, contrairement à un mot de passe. Même si quelqu’un intercepte la totalité de l’échange, il ne peut pas en déduire votre clé privée.
La version stable la plus récente, OpenSSH 10.3, a été publiée le 2 avril 2026. Plusieurs jalons récents expliquent pourquoi 2026 est un bon moment pour migrer vers les clés. OpenSSH 8.8 a désactivé l’algorithme de signature ssh-rsa qui dépendait de SHA-1, OpenSSH 8.2 a introduit la prise en charge des clés de sécurité matérielles FIDO2, et OpenSSH 8.1 a ajouté des protections mémoire pour la clé privée contre les attaques par canaux auxiliaires et par exécution spéculative. En parallèle, OpenSSH a généralisé l’échange de clés hybride post-quantique, d’abord avec sntrup761x25519, puis avec mlkem768x25519, pour résister aux futurs ordinateurs quantiques tout en restant compatible avec X25519.
Concrètement, une clé bien configurée vous apporte trois bénéfices immédiats. D’abord, l’immunité totale à la force brute en ligne : aucune liste de mots de passe ne peut deviner une clé Ed25519 de 256 bits. Ensuite, la possibilité de désactiver complètement l’authentification par mot de passe sur le serveur, ce qui réduit la surface d’attaque à zéro pour cette catégorie d’attaques. Enfin, l’automatisation propre des scripts, sauvegardes et déploiements sans stocker de mot de passe en clair. Une clé protégée par une bonne phrase de passe combine donc commodité et sécurité, à condition de respecter les permissions de fichiers que nous détaillerons à l’étape 6.
Prérequis : versions d’OpenSSH et outils nécessaires
Avant de générer la moindre clé, vérifiez que votre environnement dispose d’une version récente d’OpenSSH côté client et côté serveur. Les fonctions modernes (Ed25519, clés FIDO2, échange post-quantique) exigent des versions à jour. Voici les prérequis recommandés pour ce tutoriel.
| Composant | Version minimale | Recommandé en 2026 | Rôle |
|---|---|---|---|
| OpenSSH (client + serveur) | 8.2 | 10.3 (avr. 2026) | Génération de clés, FIDO2, post-quantique |
| Type de clé par défaut | Ed25519 | Ed25519 | Algorithme de signature |
| Système client | Linux, macOS 10.15+ | Windows 10/11 inclus | OpenSSH intégré nativement |
| Accès serveur | Compte avec mot de passe | Compte sudo non-root | Pour déposer la clé publique |
| Clé matérielle (option) | FIDO2 / U2F | YubiKey, Nitrokey | Clés ed25519-sk |
Sous Linux, OpenSSH est généralement préinstallé ; sinon, installez le paquet openssh-client (Debian, Ubuntu) ou openssh-clients (Fedora, RHEL). Sous macOS, le client est livré avec le système. Sous Windows 10 et 11, OpenSSH est disponible comme fonctionnalité facultative et accessible depuis PowerShell ou le Terminal Windows. Vous aurez aussi besoin d’un accès initial au serveur, typiquement par mot de passe, pour y copier votre clé publique. Travaillez toujours avec un compte utilisateur disposant de sudo plutôt qu’en root direct.
Dernier point de méthode : gardez une seconde session SSH ouverte vers le serveur pendant tout le tutoriel. Lorsque vous modifierez la configuration de sshd aux étapes 9 et 10, une erreur peut vous verrouiller dehors. Une session de secours déjà connectée vous laisse une chance de corriger le tir sans passer par la console physique ou le panneau de secours de votre hébergeur.
Ed25519, RSA, ECDSA : quel algorithme choisir
Le choix de l’algorithme conditionne la sécurité et les performances de votre clé. OpenSSH proposait historiquement RSA par défaut, puis a basculé vers Ed25519 dans les versions modernes. Aujourd’hui, Ed25519 est le choix recommandé pour la grande majorité des cas d’usage. Le tableau suivant compare les quatre familles.
| Type de clé | Taille | Niveau de sécurité | Vitesse | Recommandation 2026 |
|---|---|---|---|---|
| Ed25519 | 256 bits | ~128 bits | Très rapide | Choix par défaut |
| RSA 4096 | 4096 bits | ~128 bits | Lent à générer | Compatibilité héritée |
| RSA 3072 | 3072 bits | ~112-128 bits | Moyen | Minimum acceptable |
| ECDSA | 256-521 bits | ~128-256 bits | Rapide | Second choix |
| ed25519-sk | 256 bits + FIDO2 | ~128 bits + matériel | Rapide | Postes sensibles |
Ed25519 s’impose pour plusieurs raisons. La clé est petite (256 bits) et de taille fixe, la génération et la vérification sont très rapides, et le niveau de sécurité avoisine 128 bits, équivalent à du RSA 3072 voire 4096 bits sans la lourdeur. La courbe Edwards 25519 a été conçue pour éviter les pièges d’implémentation qui ont historiquement affaibli ECDSA, notamment la dépendance à une source d’aléa de qualité à chaque signature. Pour un usage interactif quotidien, Ed25519 est plus rapide, plus court et plus sûr.
RSA conserve un intérêt pour la compatibilité avec des équipements anciens (vieux pare-feu, appliances, systèmes embarqués) qui ne reconnaissent pas Ed25519. Dans ce cas, n’utilisez jamais moins de 3072 bits, et préférez 4096 bits pour les clés à longue durée de vie. Attention : c’est l’algorithme de signature ssh-rsa basé sur SHA-1 qui a été désactivé dans OpenSSH 8.8, pas les clés RSA elles-mêmes, qui restent prises en charge avec des signatures SHA-2 (rsa-sha2-256 et rsa-sha2-512). ECDSA reste un second choix : il fonctionne, mais Ed25519 offre les mêmes garanties avec moins de surface d’erreur. Réservez ECDSA aux environnements qui l’imposent explicitement.
Étape 1 : vérifier votre installation OpenSSH
Commencez par confirmer la version d’OpenSSH installée, sur le client comme sur le serveur. La fonction ssh-keygen et les algorithmes disponibles dépendent directement de cette version.
# Côté client : version d'OpenSSH
ssh -V
# Sortie attendue (exemple)
# OpenSSH_10.3p1, OpenSSL 3.5.0 1 Apr 2026
# Lister les types de clés que ssh-keygen sait générer
ssh-keygen --help 2>&1 | grep -A1 "key type"La commande ssh -V affiche la version sur la sortie d’erreur standard, c’est normal. Si vous obtenez une version inférieure à 8.2, mettez à jour avant de continuer, sinon les clés FIDO2 et l’échange post-quantique ne seront pas disponibles. Sous Windows, ouvrez PowerShell et lancez la même commande ; si OpenSSH n’est pas reconnu, activez la fonctionnalité « Client OpenSSH » dans les paramètres de Windows.
Vérifiez aussi le contenu de votre dossier ~/.ssh. S’il existe déjà des fichiers id_ed25519 ou id_rsa, vous possédez peut-être déjà une clé. Ne l’écrasez pas à l’aveugle : une clé écrasée est définitivement perdue, avec tous les accès qui en dépendent. Listez d’abord ce que vous avez.
# Inspecter le dossier des clés
ls -la ~/.ssh
# Sortie possible
# drwx------ 2 user user 4096 14 juin 09:12 .
# -rw------- 1 user user 411 14 juin 09:12 id_ed25519
# -rw-r--r-- 1 user user 99 14 juin 09:12 id_ed25519.pubÉtape 2 : générer une paire de clés avec ssh-keygen
Place à la commande centrale du tutoriel. Pour générer une clé Ed25519 moderne, exécutez ssh-keygen avec l’algorithme Ed25519 et un commentaire identifiant la clé. Le commentaire (souvent votre adresse e-mail ou un libellé machine) facilite le tri plus tard dans le fichier authorized_keys.
# Générer une clé Ed25519 avec ssh-keygen
ssh-keygen -t ed25519 -a 100 -C "sam@portable-2026" -f ~/.ssh/id_ed25519
# Sortie interactive
# Generating public/private ed25519 key pair.
# Enter passphrase (empty for no passphrase):
# Enter same passphrase again:
# Your identification has been saved in /home/sam/.ssh/id_ed25519
# Your public key has been saved in /home/sam/.ssh/id_ed25519.pub
# The key fingerprint is:
# SHA256:Xy9c...e1Q sam@portable-2026Décortiquons les options. -t ed25519 sélectionne l’algorithme. -a 100 fixe le nombre de tours de la fonction de dérivation de clé qui protège la clé privée (nous y revenons à l’étape 3). -C ajoute un commentaire descriptif. -f impose le chemin du fichier de sortie, ce qui évite d’écraser une clé existante par accident. Si vous omettez -f, ssh-keygen propose le chemin par défaut et vous demande confirmation avant d’écraser.
Pour un cas qui exige RSA (compatibilité héritée), la commande change peu : ssh-keygen -t rsa -b 4096 -a 100 -C "sam@legacy". L’option -b 4096 définit la taille en bits ; ne descendez jamais sous 3072. La génération RSA 4096 prend nettement plus de temps qu’Ed25519, parfois plusieurs secondes, c’est normal. À l’issue de l’étape, vous disposez de deux fichiers : la clé privée (id_ed25519, à protéger absolument) et la clé publique (id_ed25519.pub, que vous pouvez diffuser librement).
Étape 3 : protéger la clé privée avec une phrase de passe
Une clé privée sans phrase de passe est un fichier qui donne un accès complet à quiconque met la main dessus. Si votre ordinateur portable est volé ou si une sauvegarde fuite, une clé non chiffrée se réutilise instantanément. La phrase de passe chiffre la clé privée au repos : pour l’utiliser, il faut connaître le secret.
Lors de la génération, ssh-keygen vous demande deux fois la phrase de passe. Choisissez une phrase longue (quatre mots aléatoires ou plus), pas un mot de passe court. L’option -a contrôle le nombre de tours de la fonction de dérivation de clé (KDF) appliquée à cette phrase : plus la valeur est élevée, plus une attaque par dictionnaire sur la clé volée devient lente. La valeur 100 offre un bon compromis ; sur une machine récente, le déverrouillage reste imperceptible.
# Ajouter ou changer la phrase de passe d'une clé existante
ssh-keygen -p -a 200 -f ~/.ssh/id_ed25519
# Sortie
# Enter old passphrase:
# Enter new passphrase (empty for no passphrase):
# Enter same passphrase again:
# Your identification has been saved with the new passphrase.La commande ssh-keygen -p change la phrase de passe sans régénérer la clé : la paire reste identique, donc vous n’avez pas à redéployer la clé publique sur vos serveurs. C’est la bonne approche si vous aviez créé une clé sans phrase de passe et que vous voulez la sécuriser après coup. Pour éviter de saisir la phrase à chaque connexion, vous chargerez la clé dans ssh-agent à l’étape 8 : vous la déverrouillez une fois par session, puis l’agent s’en charge.
Étape 4 : inspecter et comprendre vos fichiers de clés
Avant de déployer quoi que ce soit, apprenez à lire vos clés. La clé publique est une seule ligne de texte que vous pouvez afficher sans risque ; la clé privée ne doit jamais être affichée ni copiée hors de la machine.
# Afficher la clé publique
cat ~/.ssh/id_ed25519.pub
# ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIE9...k3l sam@portable-2026
# Afficher l'empreinte (fingerprint) de la clé
ssh-keygen -lf ~/.ssh/id_ed25519.pub
# 256 SHA256:Xy9c...e1Q sam@portable-2026 (ED25519)
# Afficher l'empreinte en art ASCII (pour comparaison visuelle)
ssh-keygen -lvf ~/.ssh/id_ed25519.pubLa clé publique se compose de trois champs : le type (ssh-ed25519), la donnée encodée en base64, puis le commentaire. C’est cette ligne que vous déposez dans authorized_keys sur le serveur. L’empreinte SHA256 affichée par ssh-keygen -lf est l’identifiant court de la clé : OpenSSH l’affiche lors de la première connexion à un hôte, et vous pouvez la comparer pour détecter une attaque de l’homme du milieu.
Un point souvent oublié : la clé publique peut être régénérée à partir de la clé privée, mais l’inverse est impossible. Si vous perdez le fichier .pub mais conservez la clé privée, récupérez-le ainsi.
# Reconstruire la clé publique depuis la clé privée
ssh-keygen -y -f ~/.ssh/id_ed25519 > ~/.ssh/id_ed25519.pubÉtape 5 : copier la clé publique sur le serveur
Pour autoriser votre clé sur le serveur, sa clé publique doit figurer dans ~/.ssh/authorized_keys du compte distant. L’outil ssh-copy-id automatise cette opération : il se connecte une dernière fois par mot de passe, crée le dossier .ssh si besoin, ajoute votre clé et règle les permissions.
# Méthode recommandée : ssh-copy-id
ssh-copy-id -i ~/.ssh/id_ed25519.pub [email protected]
# Sortie
# Number of key(s) added: 1
# Now try logging into the machine, with: "ssh '[email protected]'"
# and check to make sure that only the key(s) you wanted were added.Si ssh-copy-id n’est pas disponible (cas fréquent sous Windows), copiez la clé manuellement. La commande suivante envoie votre clé publique et l’ajoute proprement au fichier distant, en créant le dossier avec les bonnes permissions.
# Méthode manuelle (depuis le client)
cat ~/.ssh/id_ed25519.pub | ssh [email protected] \
"mkdir -p ~/.ssh && chmod 700 ~/.ssh && \
cat >> ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys"
# Sous Windows PowerShell
type $env:USERPROFILE\.ssh\id_ed25519.pub | ssh [email protected] `
"mkdir -p ~/.ssh; cat >> ~/.ssh/authorized_keys"Utilisez bien >> (ajout) et non > (écrasement) : sinon vous remplacez toutes les clés déjà autorisées, y compris celles de vos collègues ou de vos systèmes automatisés. Chaque clé occupe une ligne dans authorized_keys ; un compte peut en contenir plusieurs, une par appareil. Après cette étape, ne fermez pas encore votre session par mot de passe : testez d’abord la connexion par clé à l’étape 7.
Étape 6 : régler les permissions de ~/.ssh et authorized_keys
OpenSSH refuse d’utiliser une clé si les permissions de fichiers sont trop ouvertes. C’est une protection volontaire : si d’autres utilisateurs du système peuvent lire ou modifier vos fichiers de clés, le serveur considère la clé comme compromise et l’ignore. La plupart des erreurs « Permission denied (publickey) » viennent en réalité de permissions incorrectes.
| Fichier ou dossier | Permission | Octal | Signification |
|---|---|---|---|
~/.ssh | drwx------ | 700 | Accès propriétaire uniquement |
~/.ssh/authorized_keys | -rw------- | 600 | Lecture/écriture propriétaire |
~/.ssh/id_ed25519 (privée) | -rw------- | 600 | Clé privée, jamais lisible par d’autres |
~/.ssh/id_ed25519.pub | -rw-r--r-- | 644 | Clé publique, lecture autorisée |
~/.ssh/config | -rw------- | 600 | Configuration client |
# Corriger les permissions sur le serveur (et sur le client)
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
chmod 600 ~/.ssh/id_ed25519
chmod 644 ~/.ssh/id_ed25519.pub
# Vérifier aussi le propriétaire : le dossier doit appartenir à l'utilisateur
chown -R "$USER":"$USER" ~/.sshLe propriétaire compte autant que les bits de permission. Si ~/.ssh appartient à root alors que vous vous connectez en tant que sam, OpenSSH refusera la clé. Vérifiez aussi le dossier personnel lui-même : un répertoire home accessible en écriture par le groupe (par exemple en 775) peut faire échouer l’authentification, car un tiers pourrait y créer ou remplacer le dossier .ssh. En cas de doute, chmod 750 ~ ou chmod 700 ~ sur le serveur résout souvent un blocage persistant.
Étape 7 : se connecter et configurer ~/.ssh/config
Testez maintenant la connexion par clé. Tant que l’authentification par mot de passe reste active, vous ne risquez pas de vous verrouiller : en cas d’échec, le serveur retombera sur le mot de passe.
# Connexion avec mode verbeux pour diagnostiquer
ssh -v -i ~/.ssh/id_ed25519 [email protected]
# Lignes clés à repérer dans la sortie
# debug1: Offering public key: /home/sam/.ssh/id_ed25519 ED25519
# debug1: Server accepts key: /home/sam/.ssh/id_ed25519 ED25519
# debug1: Authentication succeeded (publickey).Si vous voyez « Authentication succeeded (publickey) », la clé fonctionne. Pour éviter de taper le chemin, l’adresse et l’utilisateur à chaque fois, créez un fichier ~/.ssh/config sur le client. Vous pourrez alors écrire simplement ssh prod.
# ~/.ssh/config
Host prod
HostName 198.51.100.10
User sam
IdentityFile ~/.ssh/id_ed25519
IdentitiesOnly yes
Port 22
Host *
AddKeysToAgent yes
ServerAliveInterval 60L’option IdentitiesOnly yes est importante : elle force OpenSSH à n’essayer que la clé indiquée, au lieu de présenter toutes vos clés au serveur. Sans elle, un serveur peut rejeter votre connexion après trop de tentatives ratées si vous possédez de nombreuses clés. AddKeysToAgent yes charge automatiquement la clé dans l’agent au premier usage, et ServerAliveInterval 60 évite les déconnexions sur les sessions inactives.
Étape 8 : charger la clé dans ssh-agent
Saisir la phrase de passe à chaque connexion devient vite pénible. L’agent SSH garde la clé déverrouillée en mémoire pour la durée de votre session : vous tapez la phrase une seule fois, puis l’agent répond aux défis sans vous solliciter.
# Démarrer l'agent (si nécessaire) et ajouter la clé
eval "$(ssh-agent -s)"
# Agent pid 4123
ssh-add ~/.ssh/id_ed25519
# Enter passphrase for /home/sam/.ssh/id_ed25519:
# Identity added: /home/sam/.ssh/id_ed25519 (sam@portable-2026)
# Lister les clés chargées
ssh-add -l
# 256 SHA256:Xy9c...e1Q sam@portable-2026 (ED25519)
# Ajouter une clé avec expiration automatique (1 heure)
ssh-add -t 3600 ~/.ssh/id_ed25519L’option -t 3600 fixe une durée de vie : après une heure, l’agent oublie la clé et vous devrez la recharger. C’est une bonne pratique sur les postes partagés. Sous macOS, ajoutez --apple-use-keychain pour mémoriser la phrase de passe dans le trousseau. Sous Windows, le service « Agent d’authentification OpenSSH » remplit le même rôle ; activez-le puis utilisez ssh-add dans PowerShell.
Un mot d’avertissement sur la redirection d’agent (ssh -A ou ForwardAgent yes). Cette fonction expose le socket de votre agent sur le serveur distant : si ce serveur est compromis, l’attaquant peut s’en servir pour rebondir vers vos autres machines tant que votre session est ouverte. N’activez la redirection d’agent que vers des hôtes de confiance, et préférez ProxyJump (ssh -J) pour traverser un rebond sans exposer l’agent.
Étape 9 : désactiver l’authentification par mot de passe
C’est l’étape qui sécurise réellement le serveur. Tant que le mot de passe reste accepté, les robots continueront leurs tentatives de force brute. Une fois votre connexion par clé validée, désactivez les mots de passe dans la configuration du démon SSH.
# Éditer la configuration du serveur (sur le serveur)
sudo nano /etc/ssh/sshd_config
# Réglages à appliquer
PubkeyAuthentication yes
PasswordAuthentication no
ChallengeResponseAuthentication no
KbdInteractiveAuthentication no
PermitRootLogin prohibit-password
UsePAM yesSur les distributions récentes, certains réglages vivent dans des fichiers séparés sous /etc/ssh/sshd_config.d/. Un fichier comme 50-cloud-init.conf peut réactiver PasswordAuthentication yes et écraser votre réglage. Vérifiez l’ensemble avec sudo sshd -T | grep -i passwordauthentication, qui affiche la valeur réellement appliquée après fusion de tous les fichiers.
# Tester la configuration AVANT de redémarrer (détecte les erreurs de syntaxe)
sudo sshd -t
# Recharger le service sans couper les sessions existantes
sudo systemctl reload ssh # Debian/Ubuntu
sudo systemctl reload sshd # Fedora/RHEL
# Confirmer la valeur effective
sudo sshd -T | grep -i passwordauthentication
# passwordauthentication noNe fermez surtout pas votre session de secours avant d’avoir ouvert une nouvelle connexion par clé dans un autre terminal. Si la nouvelle connexion réussit, vous pouvez fermer l’ancienne sereinement. Si elle échoue, votre session déjà ouverte vous permet de corriger sshd_config et de recharger le service sans perdre l’accès.
Étape 10 : durcir le serveur et activer le post-quantique
Au-delà de la désactivation des mots de passe, quelques réglages renforcent nettement la posture du serveur. Ils limitent les algorithmes faibles, réduisent la fenêtre des attaques et activent l’échange de clés résistant au quantique.
# Durcissement de /etc/ssh/sshd_config
# Échange de clés hybride post-quantique en priorité
KexAlgorithms mlkem768x25519-sha256,sntrup761x25519-sha512,curve25519-sha256
# N'accepter que les clés hôtes et algos de signature modernes
HostKeyAlgorithms ssh-ed25519,rsa-sha2-512,rsa-sha2-256
PubkeyAcceptedAlgorithms ssh-ed25519,[email protected],rsa-sha2-512
# Réduire la surface d'attaque
MaxAuthTries 3
LoginGraceTime 20
AllowUsers sam
X11Forwarding noLa directive KexAlgorithms place l’échange hybride post-quantique en tête. Le principe de l’hybride est simple : il combine un mécanisme post-quantique (ML-KEM 768, normalisé par le NIST, ou NTRU Prime) avec X25519 classique. Même si l’un des deux est cassé, le secret reste protégé par l’autre. Cela protège contre la stratégie « récolter maintenant, déchiffrer plus tard », où un attaquant enregistre aujourd’hui le trafic chiffré pour le casser quand un ordinateur quantique sera disponible.
MaxAuthTries 3 coupe la connexion après trois échecs, et LoginGraceTime 20 réduit le délai avant authentification, ce qui gêne les attaques par épuisement de connexions. AllowUsers restreint la liste des comptes autorisés à se connecter en SSH. Pour aller plus loin, associez ce durcissement à un outil de bannissement d’IP comme Fail2ban, qui bloque automatiquement les adresses trop insistantes. Testez toujours avec sudo sshd -t avant de recharger.
Étape 11 : clés matérielles FIDO2 (ed25519-sk)
Pour les comptes les plus sensibles, une clé matérielle FIDO2 (YubiKey, Nitrokey, etc.) lie la clé SSH à un appareil physique. La partie secrète ne quitte jamais le jeton : même une machine entièrement compromise ne peut pas voler la clé, car chaque authentification exige une présence physique (toucher le bouton du jeton).
# Générer une clé SSH adossée à un jeton FIDO2
ssh-keygen -t ed25519-sk -O resident -O verify-required \
-C "sam@yubikey" -f ~/.ssh/id_ed25519_sk
# Sortie
# Generating public/private ed25519-sk key pair.
# You may need to touch your authenticator to authorize key generation.
# Enter PIN for authenticator:
# Your identification has been saved in /home/sam/.ssh/id_ed25519_skLe suffixe -sk (pour security key) indique une clé adossée à un dispositif FIDO2, disponible depuis OpenSSH 8.2. L’option -O resident stocke une référence sur le jeton lui-même, ce qui permet de récupérer la clé sur une nouvelle machine. -O verify-required impose la saisie du code PIN du jeton à chaque usage, en plus du toucher physique. Déployez la clé publique id_ed25519_sk.pub exactement comme une clé classique, via ssh-copy-id.
Côté serveur, autorisez ce type de clé avec PubkeyAcceptedAlgorithms [email protected] (déjà inclus à l’étape 10). Si vous changez de poste de travail, récupérez les clés résidentes stockées sur le jeton avec ssh-keygen -K, qui télécharge les références depuis le matériel vers le dossier .ssh local. C’est la solution la plus robuste contre le vol de clé, recommandée pour les administrateurs et les accès à privilèges élevés.
Étape 12 : rotation, révocation et inventaire des clés
Une clé SSH n’est pas éternelle. La rotation régulière limite l’impact d’une fuite passée inaperçue. Planifiez un renouvellement (par exemple tous les 12 mois pour les clés personnelles, plus court pour les comptes de service) et révoquez immédiatement une clé après la perte d’un appareil, le départ d’un collaborateur ou un soupçon de compromission.
# Révoquer une clé : retirer sa ligne de authorized_keys sur le serveur
# Repérer la clé par son commentaire
grep -n "sam@ancien-portable" ~/.ssh/authorized_keys
# Supprimer la ligne correspondante (ex. ligne 2)
sed -i '2d' ~/.ssh/authorized_keys
# Lister toutes les empreintes autorisées pour audit
ssh-keygen -lf ~/.ssh/authorized_keysPour les parcs importants, les certificats SSH simplifient la rotation. Au lieu de distribuer chaque clé publique sur chaque serveur, une autorité de certification (CA) signe les clés avec une durée de validité courte. Le serveur fait confiance à la CA, pas à chaque clé individuelle. Quand un certificat expire, l’accès cesse automatiquement, sans toucher aux fichiers authorized_keys. C’est l’approche privilégiée pour gérer des centaines de serveurs sans dispersion de clés statiques.
# Créer une CA et signer une clé utilisateur (aperçu)
ssh-keygen -t ed25519 -f ~/.ssh/ca_user -C "CA utilisateur"
ssh-keygen -s ~/.ssh/ca_user -I "sam" -n sam \
-V +52w ~/.ssh/id_ed25519.pub
# Signed user key ~/.ssh/id_ed25519-cert.pub: id "sam" valid 52 weeksPièges courants à éviter
- Écraser une clé existante. Lancer
ssh-keygensans-fet confirmer l’écrasement détruit définitivement l’ancienne clé et tous les accès liés. Listez toujours~/.sshavant de générer. - Utiliser
>au lieu de>>. En copiant manuellement la clé publique, l’écrasement remplace toutes les clés autorisées du compte distant au lieu d’ajouter la vôtre. - Oublier la phrase de passe. Une clé privée sans phrase de passe est un accès complet en clair. En cas de vol du portable ou de fuite d’une sauvegarde, elle est réutilisable immédiatement.
- Permissions trop ouvertes. Un dossier
~/.sshen 755 ou unauthorized_keysen 644 fait silencieusement échouer l’authentification par clé. Respectez 700 et 600. - Fermer la session de secours trop tôt. Désactiver les mots de passe avant d’avoir validé la connexion par clé dans un nouveau terminal peut vous verrouiller hors du serveur.
- Activer la redirection d’agent partout.
ForwardAgent yesvers un hôte non fiable expose votre agent et permet un rebond vers vos autres serveurs. Réservez-la aux hôtes de confiance.
Dépannage : 8 erreurs SSH fréquentes
| Message d’erreur | Cause probable | Solution |
|---|---|---|
Permission denied (publickey) | Aucune clé acceptée par le serveur | Vérifier authorized_keys, permissions et bon utilisateur |
Bad owner or permissions | Permissions de ~/.ssh trop ouvertes | chmod 700 ~/.ssh et 600 sur les fichiers |
Agent admitted failure to sign | Clé non chargée dans l’agent | ssh-add ~/.ssh/id_ed25519 |
Too many authentication failures | Trop de clés présentées | Ajouter IdentitiesOnly yes dans config |
no matching host key type found | Algorithme désactivé (ex. ssh-rsa) | Migrer vers Ed25519 ou signatures SHA-2 |
Connection refused | Service SSH arrêté ou mauvais port | Vérifier systemctl status ssh et le port |
Host key verification failed | Clé hôte changée (réinstallation) | ssh-keygen -R hôte puis reconnexion |
sign_and_send_pubkey: no mutual signature | Algorithme de signature non négocié | Activer rsa-sha2-512 ou passer à Ed25519 |
La méthode universelle de diagnostic reste le mode verbeux. Lancez ssh -vvv sam@hôte : la sortie montre chaque clé offerte, l’algorithme négocié et la raison exacte d’un refus. Côté serveur, surveillez les journaux avec sudo journalctl -u ssh -f (ou -u sshd selon la distribution) pendant que vous tentez de vous connecter : vous y verrez le motif du rejet, souvent une question de permissions ou de propriété de fichier.
Si une clé hôte a changé après une réinstallation légitime du serveur, OpenSSH bloque la connexion par sécurité. Retirez l’ancienne entrée avec ssh-keygen -R 198.51.100.10, puis reconnectez-vous et vérifiez l’empreinte affichée avant d’accepter la nouvelle clé. Ne supprimez jamais cette entrée sans avoir confirmé que le changement est légitime : c’est précisément le mécanisme qui détecte une attaque de l’homme du milieu.
Astuces avancées pour gérer vos clés à grande échelle
Plusieurs techniques font gagner du temps une fois les bases acquises. Le multiplexage de connexions réutilise une connexion TCP existante pour les suivantes vers le même hôte, ce qui accélère les commandes répétées et les transferts de fichiers. Ajoutez ces lignes à votre ~/.ssh/config.
# Multiplexage : connexions plus rapides vers le même hôte
Host *
ControlMaster auto
ControlPath ~/.ssh/sockets/%r@%h:%p
ControlPersist 10m
# Créer le dossier des sockets
mkdir -p ~/.ssh/sockets && chmod 700 ~/.ssh/socketsLe rebond via ProxyJump (ssh -J bastion sam@interne) traverse un serveur intermédiaire sans exposer votre agent, contrairement à la redirection d’agent. C’est la bonne manière d’atteindre un serveur interne derrière un bastion. Pour les environnements gérés, combinez clés et certificats SSH : une CA signe des certificats à courte durée de vie, et les serveurs ne font confiance qu’à la CA, ce qui supprime la dispersion de clés statiques et simplifie la rotation décrite à l’étape 12.
Enfin, séparez vos clés par usage : une clé pour le travail, une pour les serveurs personnels, une pour les services Git (GitHub, GitLab). Cette segmentation limite l’impact d’une compromission et facilite la révocation ciblée. Combinée à IdentitiesOnly yes dans la configuration, elle garantit que chaque hôte ne reçoit que la clé qui le concerne. Pour aller plus loin sur la sécurité des accès, consultez nos guides sur le durcissement de SSH avec Fail2ban et la mise en place de VPN.
Questions fréquentes sur ssh-keygen
Ed25519 ou RSA : que choisir en 2026 ?
Choisissez Ed25519 par défaut. Il est plus rapide, génère des clés courtes et offre un niveau de sécurité d’environ 128 bits, équivalent à RSA 3072-4096 bits. Ne réservez RSA (4096 bits minimum, jamais sous 3072) qu’aux équipements anciens qui ne reconnaissent pas Ed25519.
Faut-il vraiment une phrase de passe sur la clé privée ?
Oui. Sans phrase de passe, la clé privée donne un accès complet à quiconque la copie. La phrase de passe chiffre la clé au repos. Combinée à ssh-agent, elle ne se saisit qu’une fois par session, donc le confort est préservé.
Pourquoi j’obtiens « Permission denied (publickey) » ?
Dans la majorité des cas, ce sont des permissions de fichiers trop ouvertes : le dossier ~/.ssh doit être en 700 et authorized_keys en 600, avec le bon propriétaire. Vérifiez aussi que la clé publique figure bien dans authorized_keys du bon compte. Le mode ssh -vvv précise la cause exacte.
Comment changer la phrase de passe sans régénérer la clé ?
Utilisez ssh-keygen -p -f ~/.ssh/id_ed25519. La paire de clés reste identique, donc vous n’avez pas à redéployer la clé publique sur vos serveurs. C’est aussi la commande pour ajouter une phrase de passe à une clé qui n’en avait pas.
Une clé SSH est-elle résistante aux ordinateurs quantiques ?
La signature Ed25519 reste vulnérable à un futur ordinateur quantique, mais OpenSSH protège déjà l’échange de clés de session avec des schémas hybrides post-quantiques (mlkem768x25519, sntrup761x25519). Activez-les via KexAlgorithms comme à l’étape 10 pour contrer la stratégie « récolter maintenant, déchiffrer plus tard ».
Puis-je utiliser la même clé sur plusieurs serveurs ?
Techniquement oui, en déposant la même clé publique sur chaque serveur. Mais pour limiter l’impact d’une fuite, mieux vaut une clé par contexte (travail, perso, Git). En cas de compromission, vous ne révoquez qu’une clé sans casser tous vos accès.
Quelle version d’OpenSSH faut-il au minimum ?
OpenSSH 8.2 suffit pour Ed25519 et les clés FIDO2, mais visez la version stable la plus récente (10.3, avril 2026) pour bénéficier de l’échange post-quantique par défaut et des derniers correctifs de sécurité. Vérifiez avec ssh -V.
Related Coverage
- Fail2ban : protéger SSH en 12 étapes, 30 min
- VPN WireGuard sur Linux : 12 étapes, 30 min
- GPG : chiffrer fichiers et emails, 12 étapes
- Certificat SSL gratuit avec Certbot : 11 étapes
- Sécurité des mots de passe : longueur, hachage et gestionnaires
- Sécurité en ligne : protéger ses données et ses accès
Sources et références : notes de version OpenSSH, manuel ssh-keygen (OpenBSD), SSH Academy : ssh-keygen, Mozilla OpenSSH Security Guidelines, EdDSA (Ed25519).
