{"id":150,"date":"2026-06-14T16:32:27","date_gmt":"2026-06-14T16:32:27","guid":{"rendered":"https:\/\/shattered.io\/fr\/2026\/06\/14\/ssh-keygen-cle-ssh-authentification\/"},"modified":"2026-06-14T16:33:47","modified_gmt":"2026-06-14T16:33:47","slug":"ssh-keygen-cle-ssh-authentification","status":"publish","type":"post","link":"https:\/\/shattered.io\/fr\/2026\/06\/14\/ssh-keygen-cle-ssh-authentification\/","title":{"rendered":"ssh-keygen : cl\u00e9 SSH en 12 \u00e9tapes, 20 min [2026]"},"content":{"rendered":"\n

Les mots de passe SSH sont le maillon faible de la plupart des serveurs expos\u00e9s sur Internet. Un serveur fra\u00eechement install\u00e9 re\u00e7oit des milliers de tentatives de connexion par force brute en quelques heures, et il suffit d’un mot de passe r\u00e9utilis\u00e9 pour qu’un attaquant prenne le contr\u00f4le. L’authentification par cl\u00e9 r\u00e8gle ce probl\u00e8me : \u00e0 la place d’un secret partag\u00e9 que l’on peut deviner, vous prouvez votre identit\u00e9 avec une cl\u00e9 cryptographique impossible \u00e0 brute-forcer. La commande ssh-keygen<\/code>, livr\u00e9e avec OpenSSH, g\u00e9n\u00e8re cette paire de cl\u00e9s en quelques secondes.<\/p>\n\n\n\n

Ce tutoriel vous guide en 12 \u00e9tapes, de la g\u00e9n\u00e9ration d’une cl\u00e9 Ed25519 jusqu’au durcissement complet du serveur, en passant par la d\u00e9sactivation des mots de passe, les cl\u00e9s mat\u00e9rielles FIDO2 et l’\u00e9change de cl\u00e9s 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\u00eates \u00e0 copier, avec des exemples de sortie et un d\u00e9pannage d\u00e9taill\u00e9 des erreurs les plus fr\u00e9quentes.<\/p>\n\n\n\n

Authentification SSH par cl\u00e9 : ce qui change en 2026<\/h2>\n\n\n\n

L’authentification par cl\u00e9 publique repose sur une paire asym\u00e9trique : une cl\u00e9 priv\u00e9e<\/strong> que vous gardez sur votre machine et une cl\u00e9 publique<\/strong> que vous d\u00e9posez sur le serveur. Lors de la connexion, le serveur envoie un d\u00e9fi que seule la cl\u00e9 priv\u00e9e peut r\u00e9soudre. Le secret ne transite jamais sur le r\u00e9seau, contrairement \u00e0 un mot de passe. M\u00eame si quelqu’un intercepte la totalit\u00e9 de l’\u00e9change, il ne peut pas en d\u00e9duire votre cl\u00e9 priv\u00e9e.<\/p>\n\n\n\n

La version stable la plus r\u00e9cente, OpenSSH 10.3, a \u00e9t\u00e9 publi\u00e9e le 2 avril 2026. Plusieurs jalons r\u00e9cents expliquent pourquoi 2026 est un bon moment pour migrer vers les cl\u00e9s. OpenSSH 8.8 a d\u00e9sactiv\u00e9 l’algorithme de signature ssh-rsa<\/code> qui d\u00e9pendait de SHA-1, OpenSSH 8.2 a introduit la prise en charge des cl\u00e9s de s\u00e9curit\u00e9 mat\u00e9rielles FIDO2, et OpenSSH 8.1 a ajout\u00e9 des protections m\u00e9moire pour la cl\u00e9 priv\u00e9e contre les attaques par canaux auxiliaires et par ex\u00e9cution sp\u00e9culative. En parall\u00e8le, OpenSSH a g\u00e9n\u00e9ralis\u00e9 l’\u00e9change de cl\u00e9s hybride post-quantique, d’abord avec sntrup761x25519<\/code>, puis avec mlkem768x25519<\/code>, pour r\u00e9sister aux futurs ordinateurs quantiques tout en restant compatible avec X25519.<\/p>\n\n\n\n

Concr\u00e8tement, une cl\u00e9 bien configur\u00e9e vous apporte trois b\u00e9n\u00e9fices imm\u00e9diats. D’abord, l’immunit\u00e9 totale \u00e0 la force brute en ligne : aucune liste de mots de passe ne peut deviner une cl\u00e9 Ed25519 de 256 bits. Ensuite, la possibilit\u00e9 de d\u00e9sactiver compl\u00e8tement l’authentification par mot de passe sur le serveur, ce qui r\u00e9duit la surface d’attaque \u00e0 z\u00e9ro pour cette cat\u00e9gorie d’attaques. Enfin, l’automatisation propre des scripts, sauvegardes et d\u00e9ploiements sans stocker de mot de passe en clair. Une cl\u00e9 prot\u00e9g\u00e9e par une bonne phrase de passe combine donc commodit\u00e9 et s\u00e9curit\u00e9, \u00e0 condition de respecter les permissions de fichiers que nous d\u00e9taillerons \u00e0 l’\u00e9tape 6.<\/p>\n\n\n\n

Pr\u00e9requis : versions d’OpenSSH et outils n\u00e9cessaires<\/h2>\n\n\n\n

Avant de g\u00e9n\u00e9rer la moindre cl\u00e9, v\u00e9rifiez que votre environnement dispose d’une version r\u00e9cente d’OpenSSH c\u00f4t\u00e9 client et c\u00f4t\u00e9 serveur. Les fonctions modernes (Ed25519, cl\u00e9s FIDO2, \u00e9change post-quantique) exigent des versions \u00e0 jour. Voici les pr\u00e9requis recommand\u00e9s pour ce tutoriel.<\/p>\n\n\n\n

Composant<\/th>Version minimale<\/th>Recommand\u00e9 en 2026<\/th>R\u00f4le<\/th><\/tr><\/thead>
OpenSSH (client + serveur)<\/td>8.2<\/td>10.3 (avr. 2026)<\/td>G\u00e9n\u00e9ration de cl\u00e9s, FIDO2, post-quantique<\/td><\/tr>
Type de cl\u00e9 par d\u00e9faut<\/td>Ed25519<\/td>Ed25519<\/td>Algorithme de signature<\/td><\/tr>
Syst\u00e8me client<\/td>Linux, macOS 10.15+<\/td>Windows 10\/11 inclus<\/td>OpenSSH int\u00e9gr\u00e9 nativement<\/td><\/tr>
Acc\u00e8s serveur<\/td>Compte avec mot de passe<\/td>Compte sudo non-root<\/td>Pour d\u00e9poser la cl\u00e9 publique<\/td><\/tr>
Cl\u00e9 mat\u00e9rielle (option)<\/td>FIDO2 \/ U2F<\/td>YubiKey, Nitrokey<\/td>Cl\u00e9s ed25519-sk<\/code><\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

Sous Linux, OpenSSH est g\u00e9n\u00e9ralement pr\u00e9install\u00e9 ; sinon, installez le paquet openssh-client<\/code> (Debian, Ubuntu) ou openssh-clients<\/code> (Fedora, RHEL). Sous macOS, le client est livr\u00e9 avec le syst\u00e8me. Sous Windows 10 et 11, OpenSSH est disponible comme fonctionnalit\u00e9 facultative et accessible depuis PowerShell ou le Terminal Windows. Vous aurez aussi besoin d’un acc\u00e8s initial au serveur, typiquement par mot de passe, pour y copier votre cl\u00e9 publique. Travaillez toujours avec un compte utilisateur disposant de sudo<\/code> plut\u00f4t qu’en root<\/code> direct.<\/p>\n\n\n\n

Dernier point de m\u00e9thode : gardez une seconde session SSH ouverte vers le serveur pendant tout le tutoriel. Lorsque vous modifierez la configuration de sshd<\/code> aux \u00e9tapes 9 et 10, une erreur peut vous verrouiller dehors. Une session de secours d\u00e9j\u00e0 connect\u00e9e vous laisse une chance de corriger le tir sans passer par la console physique ou le panneau de secours de votre h\u00e9bergeur.<\/p>\n\n\n\n

Ed25519, RSA, ECDSA : quel algorithme choisir<\/h2>\n\n\n\n

Le choix de l’algorithme conditionne la s\u00e9curit\u00e9 et les performances de votre cl\u00e9. OpenSSH proposait historiquement RSA par d\u00e9faut, puis a bascul\u00e9 vers Ed25519 dans les versions modernes. Aujourd’hui, Ed25519 est le choix recommand\u00e9 pour la grande majorit\u00e9 des cas d’usage. Le tableau suivant compare les quatre familles.<\/p>\n\n\n\n

Type de cl\u00e9<\/th>Taille<\/th>Niveau de s\u00e9curit\u00e9<\/th>Vitesse<\/th>Recommandation 2026<\/th><\/tr><\/thead>
Ed25519<\/td>256 bits<\/td>~128 bits<\/td>Tr\u00e8s rapide<\/td>Choix par d\u00e9faut<\/td><\/tr>
RSA 4096<\/td>4096 bits<\/td>~128 bits<\/td>Lent \u00e0 g\u00e9n\u00e9rer<\/td>Compatibilit\u00e9 h\u00e9rit\u00e9e<\/td><\/tr>
RSA 3072<\/td>3072 bits<\/td>~112-128 bits<\/td>Moyen<\/td>Minimum acceptable<\/td><\/tr>
ECDSA<\/td>256-521 bits<\/td>~128-256 bits<\/td>Rapide<\/td>Second choix<\/td><\/tr>
ed25519-sk<\/td>256 bits + FIDO2<\/td>~128 bits + mat\u00e9riel<\/td>Rapide<\/td>Postes sensibles<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

Ed25519 s’impose pour plusieurs raisons. La cl\u00e9 est petite (256 bits) et de taille fixe, la g\u00e9n\u00e9ration et la v\u00e9rification sont tr\u00e8s rapides, et le niveau de s\u00e9curit\u00e9 avoisine 128 bits, \u00e9quivalent \u00e0 du RSA 3072 voire 4096 bits sans la lourdeur. La courbe Edwards 25519 a \u00e9t\u00e9 con\u00e7ue pour \u00e9viter les pi\u00e8ges d’impl\u00e9mentation qui ont historiquement affaibli ECDSA, notamment la d\u00e9pendance \u00e0 une source d’al\u00e9a de qualit\u00e9 \u00e0 chaque signature. Pour un usage interactif quotidien, Ed25519 est plus rapide, plus court et plus s\u00fbr.<\/p>\n\n\n\n

RSA conserve un int\u00e9r\u00eat pour la compatibilit\u00e9 avec des \u00e9quipements anciens (vieux pare-feu, appliances, syst\u00e8mes embarqu\u00e9s) qui ne reconnaissent pas Ed25519. Dans ce cas, n’utilisez jamais moins de 3072 bits, et pr\u00e9f\u00e9rez 4096 bits pour les cl\u00e9s \u00e0 longue dur\u00e9e de vie. Attention : c’est l’algorithme de signature ssh-rsa<\/code> bas\u00e9 sur SHA-1 qui a \u00e9t\u00e9 d\u00e9sactiv\u00e9 dans OpenSSH 8.8, pas les cl\u00e9s RSA elles-m\u00eames, qui restent prises en charge avec des signatures SHA-2 (rsa-sha2-256<\/code> et rsa-sha2-512<\/code>). ECDSA reste un second choix : il fonctionne, mais Ed25519 offre les m\u00eames garanties avec moins de surface d’erreur. R\u00e9servez ECDSA aux environnements qui l’imposent explicitement.<\/p>\n\n\n\n

\u00c9tape 1 : v\u00e9rifier votre installation OpenSSH<\/h2>\n\n\n\n

Commencez par confirmer la version d’OpenSSH install\u00e9e, sur le client comme sur le serveur. La fonction ssh-keygen<\/code> et les algorithmes disponibles d\u00e9pendent directement de cette version.<\/p>\n\n\n\n

# C\u00f4t\u00e9 client : version d'OpenSSH\nssh -V\n\n# Sortie attendue (exemple)\n# OpenSSH_10.3p1, OpenSSL 3.5.0 1 Apr 2026\n\n# Lister les types de cl\u00e9s que ssh-keygen sait g\u00e9n\u00e9rer\nssh-keygen --help 2>&1 | grep -A1 \"key type\"<\/code><\/pre>\n\n\n\n
La commande ssh -V<\/code> affiche la version sur la sortie d’erreur standard, c’est normal. Si vous obtenez une version inf\u00e9rieure \u00e0 8.2, mettez \u00e0 jour avant de continuer, sinon les cl\u00e9s FIDO2 et l’\u00e9change post-quantique ne seront pas disponibles. Sous Windows, ouvrez PowerShell et lancez la m\u00eame commande ; si OpenSSH n’est pas reconnu, activez la fonctionnalit\u00e9 \u00ab Client OpenSSH \u00bb dans les param\u00e8tres de Windows.<\/p>\n\n\n\n
V\u00e9rifiez aussi le contenu de votre dossier ~\/.ssh<\/code>. S’il existe d\u00e9j\u00e0 des fichiers id_ed25519<\/code> ou id_rsa<\/code>, vous poss\u00e9dez peut-\u00eatre d\u00e9j\u00e0 une cl\u00e9. Ne l’\u00e9crasez pas \u00e0 l’aveugle : une cl\u00e9 \u00e9cras\u00e9e est d\u00e9finitivement perdue, avec tous les acc\u00e8s qui en d\u00e9pendent. Listez d’abord ce que vous avez.<\/p>\n\n\n\n
# Inspecter le dossier des cl\u00e9s\nls -la ~\/.ssh\n\n# Sortie possible\n# drwx------  2 user user 4096 14 juin 09:12 .\n# -rw-------  1 user user  411 14 juin 09:12 id_ed25519\n# -rw-r--r--  1 user user   99 14 juin 09:12 id_ed25519.pub<\/code><\/pre>\n\n\n\n
\u00c9tape 2 : g\u00e9n\u00e9rer une paire de cl\u00e9s avec ssh-keygen<\/h2>\n\n\n\n
Place \u00e0 la commande centrale du tutoriel. Pour g\u00e9n\u00e9rer une cl\u00e9 Ed25519 moderne, ex\u00e9cutez ssh-keygen<\/code> avec l’algorithme Ed25519 et un commentaire identifiant la cl\u00e9. Le commentaire (souvent votre adresse e-mail ou un libell\u00e9 machine) facilite le tri plus tard dans le fichier authorized_keys<\/code>.<\/p>\n\n\n\n
# G\u00e9n\u00e9rer une cl\u00e9 Ed25519 avec ssh-keygen\nssh-keygen -t ed25519 -a 100 -C \"sam@portable-2026\" -f ~\/.ssh\/id_ed25519\n\n# Sortie interactive\n# Generating public\/private ed25519 key pair.\n# Enter passphrase (empty for no passphrase):\n# Enter same passphrase again:\n# Your identification has been saved in \/home\/sam\/.ssh\/id_ed25519\n# Your public key has been saved in \/home\/sam\/.ssh\/id_ed25519.pub\n# The key fingerprint is:\n# SHA256:Xy9c...e1Q sam@portable-2026<\/code><\/pre>\n\n\n\n
D\u00e9cortiquons les options. -t ed25519<\/code> s\u00e9lectionne l’algorithme. -a 100<\/code> fixe le nombre de tours de la fonction de d\u00e9rivation de cl\u00e9 qui prot\u00e8ge la cl\u00e9 priv\u00e9e (nous y revenons \u00e0 l’\u00e9tape 3). -C<\/code> ajoute un commentaire descriptif. -f<\/code> impose le chemin du fichier de sortie, ce qui \u00e9vite d’\u00e9craser une cl\u00e9 existante par accident. Si vous omettez -f<\/code>, ssh-keygen<\/code> propose le chemin par d\u00e9faut et vous demande confirmation avant d’\u00e9craser.<\/p>\n\n\n\n
Pour un cas qui exige RSA (compatibilit\u00e9 h\u00e9rit\u00e9e), la commande change peu : ssh-keygen -t rsa -b 4096 -a 100 -C \"sam@legacy\"<\/code>. L’option -b 4096<\/code> d\u00e9finit la taille en bits ; ne descendez jamais sous 3072. La g\u00e9n\u00e9ration RSA 4096 prend nettement plus de temps qu’Ed25519, parfois plusieurs secondes, c’est normal. \u00c0 l’issue de l’\u00e9tape, vous disposez de deux fichiers : la cl\u00e9 priv\u00e9e (id_ed25519<\/code>, \u00e0 prot\u00e9ger absolument) et la cl\u00e9 publique (id_ed25519.pub<\/code>, que vous pouvez diffuser librement).<\/p>\n\n\n\n
\u00c9tape 3 : prot\u00e9ger la cl\u00e9 priv\u00e9e avec une phrase de passe<\/h2>\n\n\n\n
Une cl\u00e9 priv\u00e9e sans phrase de passe est un fichier qui donne un acc\u00e8s complet \u00e0 quiconque met la main dessus. Si votre ordinateur portable est vol\u00e9 ou si une sauvegarde fuite, une cl\u00e9 non chiffr\u00e9e se r\u00e9utilise instantan\u00e9ment. La phrase de passe chiffre la cl\u00e9 priv\u00e9e au repos : pour l’utiliser, il faut conna\u00eetre le secret.<\/p>\n\n\n\n
Lors de la g\u00e9n\u00e9ration, ssh-keygen<\/code> vous demande deux fois la phrase de passe. Choisissez une phrase longue (quatre mots al\u00e9atoires ou plus), pas un mot de passe court. L’option -a<\/code> contr\u00f4le le nombre de tours de la fonction de d\u00e9rivation de cl\u00e9 (KDF) appliqu\u00e9e \u00e0 cette phrase : plus la valeur est \u00e9lev\u00e9e, plus une attaque par dictionnaire sur la cl\u00e9 vol\u00e9e devient lente. La valeur 100 offre un bon compromis ; sur une machine r\u00e9cente, le d\u00e9verrouillage reste imperceptible.<\/p>\n\n\n\n
# Ajouter ou changer la phrase de passe d'une cl\u00e9 existante\nssh-keygen -p -a 200 -f ~\/.ssh\/id_ed25519\n\n# Sortie\n# Enter old passphrase:\n# Enter new passphrase (empty for no passphrase):\n# Enter same passphrase again:\n# Your identification has been saved with the new passphrase.<\/code><\/pre>\n\n\n\n
La commande ssh-keygen -p<\/code> change la phrase de passe sans r\u00e9g\u00e9n\u00e9rer la cl\u00e9 : la paire reste identique, donc vous n’avez pas \u00e0 red\u00e9ployer la cl\u00e9 publique sur vos serveurs. C’est la bonne approche si vous aviez cr\u00e9\u00e9 une cl\u00e9 sans phrase de passe et que vous voulez la s\u00e9curiser apr\u00e8s coup. Pour \u00e9viter de saisir la phrase \u00e0 chaque connexion, vous chargerez la cl\u00e9 dans ssh-agent<\/code> \u00e0 l’\u00e9tape 8 : vous la d\u00e9verrouillez une fois par session, puis l’agent s’en charge.<\/p>\n\n\n\n
\u00c9tape 4 : inspecter et comprendre vos fichiers de cl\u00e9s<\/h2>\n\n\n\n
Avant de d\u00e9ployer quoi que ce soit, apprenez \u00e0 lire vos cl\u00e9s. La cl\u00e9 publique est une seule ligne de texte que vous pouvez afficher sans risque ; la cl\u00e9 priv\u00e9e ne doit jamais \u00eatre affich\u00e9e ni copi\u00e9e hors de la machine.<\/p>\n\n\n\n
# Afficher la cl\u00e9 publique\ncat ~\/.ssh\/id_ed25519.pub\n# ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIE9...k3l sam@portable-2026\n\n# Afficher l'empreinte (fingerprint) de la cl\u00e9\nssh-keygen -lf ~\/.ssh\/id_ed25519.pub\n# 256 SHA256:Xy9c...e1Q sam@portable-2026 (ED25519)\n\n# Afficher l'empreinte en art ASCII (pour comparaison visuelle)\nssh-keygen -lvf ~\/.ssh\/id_ed25519.pub<\/code><\/pre>\n\n\n\n
La cl\u00e9 publique se compose de trois champs : le type (ssh-ed25519<\/code>), la donn\u00e9e encod\u00e9e en base64, puis le commentaire. C’est cette ligne que vous d\u00e9posez dans authorized_keys<\/code> sur le serveur. L’empreinte SHA256 affich\u00e9e par ssh-keygen -lf<\/code> est l’identifiant court de la cl\u00e9 : OpenSSH l’affiche lors de la premi\u00e8re connexion \u00e0 un h\u00f4te, et vous pouvez la comparer pour d\u00e9tecter une attaque de l’homme du milieu.<\/p>\n\n\n\n
Un point souvent oubli\u00e9 : la cl\u00e9 publique peut \u00eatre r\u00e9g\u00e9n\u00e9r\u00e9e \u00e0 partir de la cl\u00e9 priv\u00e9e, mais l’inverse est impossible. Si vous perdez le fichier .pub<\/code> mais conservez la cl\u00e9 priv\u00e9e, r\u00e9cup\u00e9rez-le ainsi.<\/p>\n\n\n\n
# Reconstruire la cl\u00e9 publique depuis la cl\u00e9 priv\u00e9e\nssh-keygen -y -f ~\/.ssh\/id_ed25519 > ~\/.ssh\/id_ed25519.pub<\/code><\/pre>\n\n\n\n
\u00c9tape 5 : copier la cl\u00e9 publique sur le serveur<\/h2>\n\n\n\n
Pour autoriser votre cl\u00e9 sur le serveur, sa cl\u00e9 publique doit figurer dans ~\/.ssh\/authorized_keys<\/code> du compte distant. L’outil ssh-copy-id<\/code> automatise cette op\u00e9ration : il se connecte une derni\u00e8re fois par mot de passe, cr\u00e9e le dossier .ssh<\/code> si besoin, ajoute votre cl\u00e9 et r\u00e8gle les permissions.<\/p>\n\n\n\n
# M\u00e9thode recommand\u00e9e : ssh-copy-id\nssh-copy-id -i ~\/.ssh\/id_ed25519.pub sam@198.51.100.10\n\n# Sortie\n# Number of key(s) added: 1\n# Now try logging into the machine, with:   \"ssh 'sam@198.51.100.10'\"\n# and check to make sure that only the key(s) you wanted were added.<\/code><\/pre>\n\n\n\n
Si ssh-copy-id<\/code> n’est pas disponible (cas fr\u00e9quent sous Windows), copiez la cl\u00e9 manuellement. La commande suivante envoie votre cl\u00e9 publique et l’ajoute proprement au fichier distant, en cr\u00e9ant le dossier avec les bonnes permissions.<\/p>\n\n\n\n
# M\u00e9thode manuelle (depuis le client)\ncat ~\/.ssh\/id_ed25519.pub | ssh sam@198.51.100.10 \\\n  \"mkdir -p ~\/.ssh && chmod 700 ~\/.ssh && \\\n   cat >> ~\/.ssh\/authorized_keys && chmod 600 ~\/.ssh\/authorized_keys\"\n\n# Sous Windows PowerShell\ntype $env:USERPROFILE\\.ssh\\id_ed25519.pub | ssh sam@198.51.100.10 `\n  \"mkdir -p ~\/.ssh; cat >> ~\/.ssh\/authorized_keys\"<\/code><\/pre>\n\n\n\n
Utilisez bien >><\/code> (ajout) et non ><\/code> (\u00e9crasement) : sinon vous remplacez toutes les cl\u00e9s d\u00e9j\u00e0 autoris\u00e9es, y compris celles de vos coll\u00e8gues ou de vos syst\u00e8mes automatis\u00e9s. Chaque cl\u00e9 occupe une ligne dans authorized_keys<\/code> ; un compte peut en contenir plusieurs, une par appareil. Apr\u00e8s cette \u00e9tape, ne fermez pas encore votre session par mot de passe : testez d’abord la connexion par cl\u00e9 \u00e0 l’\u00e9tape 7.<\/p>\n\n\n\n
\u00c9tape 6 : r\u00e9gler les permissions de ~\/.ssh et authorized_keys<\/h2>\n\n\n\n
OpenSSH refuse d’utiliser une cl\u00e9 si les permissions de fichiers sont trop ouvertes. C’est une protection volontaire : si d’autres utilisateurs du syst\u00e8me peuvent lire ou modifier vos fichiers de cl\u00e9s, le serveur consid\u00e8re la cl\u00e9 comme compromise et l’ignore. La plupart des erreurs \u00ab Permission denied (publickey) \u00bb viennent en r\u00e9alit\u00e9 de permissions incorrectes.<\/p>\n\n\n\n
Fichier ou dossier<\/th>Permission<\/th>Octal<\/th>Signification<\/th><\/tr><\/thead>
~\/.ssh<\/code><\/td>drwx------<\/code><\/td>700<\/td>Acc\u00e8s propri\u00e9taire uniquement<\/td><\/tr>
~\/.ssh\/authorized_keys<\/code><\/td>-rw-------<\/code><\/td>600<\/td>Lecture\/\u00e9criture propri\u00e9taire<\/td><\/tr>
~\/.ssh\/id_ed25519<\/code> (priv\u00e9e)<\/td>-rw-------<\/code><\/td>600<\/td>Cl\u00e9 priv\u00e9e, jamais lisible par d’autres<\/td><\/tr>
~\/.ssh\/id_ed25519.pub<\/code><\/td>-rw-r--r--<\/code><\/td>644<\/td>Cl\u00e9 publique, lecture autoris\u00e9e<\/td><\/tr>
~\/.ssh\/config<\/code><\/td>-rw-------<\/code><\/td>600<\/td>Configuration client<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
# Corriger les permissions sur le serveur (et sur le client)\nchmod 700 ~\/.ssh\nchmod 600 ~\/.ssh\/authorized_keys\nchmod 600 ~\/.ssh\/id_ed25519\nchmod 644 ~\/.ssh\/id_ed25519.pub\n\n# V\u00e9rifier aussi le propri\u00e9taire : le dossier doit appartenir \u00e0 l'utilisateur\nchown -R \"$USER\":\"$USER\" ~\/.ssh<\/code><\/pre>\n\n\n\n
Le propri\u00e9taire compte autant que les bits de permission. Si ~\/.ssh<\/code> appartient \u00e0 root<\/code> alors que vous vous connectez en tant que sam<\/code>, OpenSSH refusera la cl\u00e9. V\u00e9rifiez aussi le dossier personnel lui-m\u00eame : un r\u00e9pertoire home<\/code> accessible en \u00e9criture par le groupe (par exemple en 775) peut faire \u00e9chouer l’authentification, car un tiers pourrait y cr\u00e9er ou remplacer le dossier .ssh<\/code>. En cas de doute, chmod 750 ~<\/code> ou chmod 700 ~<\/code> sur le serveur r\u00e9sout souvent un blocage persistant.<\/p>\n\n\n\n
\u00c9tape 7 : se connecter et configurer ~\/.ssh\/config<\/h2>\n\n\n\n
Testez maintenant la connexion par cl\u00e9. Tant que l’authentification par mot de passe reste active, vous ne risquez pas de vous verrouiller : en cas d’\u00e9chec, le serveur retombera sur le mot de passe.<\/p>\n\n\n\n
# Connexion avec mode verbeux pour diagnostiquer\nssh -v -i ~\/.ssh\/id_ed25519 sam@198.51.100.10\n\n# Lignes cl\u00e9s \u00e0 rep\u00e9rer dans la sortie\n# debug1: Offering public key: \/home\/sam\/.ssh\/id_ed25519 ED25519\n# debug1: Server accepts key: \/home\/sam\/.ssh\/id_ed25519 ED25519\n# debug1: Authentication succeeded (publickey).<\/code><\/pre>\n\n\n\n
Si vous voyez \u00ab Authentication succeeded (publickey) \u00bb, la cl\u00e9 fonctionne. Pour \u00e9viter de taper le chemin, l’adresse et l’utilisateur \u00e0 chaque fois, cr\u00e9ez un fichier ~\/.ssh\/config<\/code> sur le client. Vous pourrez alors \u00e9crire simplement ssh prod<\/code>.<\/p>\n\n\n\n
# ~\/.ssh\/config\nHost prod\n    HostName 198.51.100.10\n    User sam\n    IdentityFile ~\/.ssh\/id_ed25519\n    IdentitiesOnly yes\n    Port 22\n\nHost *\n    AddKeysToAgent yes\n    ServerAliveInterval 60<\/code><\/pre>\n\n\n\n
L’option IdentitiesOnly yes<\/code> est importante : elle force OpenSSH \u00e0 n’essayer que la cl\u00e9 indiqu\u00e9e, au lieu de pr\u00e9senter toutes vos cl\u00e9s au serveur. Sans elle, un serveur peut rejeter votre connexion apr\u00e8s trop de tentatives rat\u00e9es si vous poss\u00e9dez de nombreuses cl\u00e9s. AddKeysToAgent yes<\/code> charge automatiquement la cl\u00e9 dans l’agent au premier usage, et ServerAliveInterval 60<\/code> \u00e9vite les d\u00e9connexions sur les sessions inactives.<\/p>\n\n\n\n
\u00c9tape 8 : charger la cl\u00e9 dans ssh-agent<\/h2>\n\n\n\n
Saisir la phrase de passe \u00e0 chaque connexion devient vite p\u00e9nible. L’agent SSH garde la cl\u00e9 d\u00e9verrouill\u00e9e en m\u00e9moire pour la dur\u00e9e de votre session : vous tapez la phrase une seule fois, puis l’agent r\u00e9pond aux d\u00e9fis sans vous solliciter.<\/p>\n\n\n\n
# D\u00e9marrer l'agent (si n\u00e9cessaire) et ajouter la cl\u00e9\neval \"$(ssh-agent -s)\"\n# Agent pid 4123\n\nssh-add ~\/.ssh\/id_ed25519\n# Enter passphrase for \/home\/sam\/.ssh\/id_ed25519:\n# Identity added: \/home\/sam\/.ssh\/id_ed25519 (sam@portable-2026)\n\n# Lister les cl\u00e9s charg\u00e9es\nssh-add -l\n# 256 SHA256:Xy9c...e1Q sam@portable-2026 (ED25519)\n\n# Ajouter une cl\u00e9 avec expiration automatique (1 heure)\nssh-add -t 3600 ~\/.ssh\/id_ed25519<\/code><\/pre>\n\n\n\n
L’option -t 3600<\/code> fixe une dur\u00e9e de vie : apr\u00e8s une heure, l’agent oublie la cl\u00e9 et vous devrez la recharger. C’est une bonne pratique sur les postes partag\u00e9s. Sous macOS, ajoutez --apple-use-keychain<\/code> pour m\u00e9moriser la phrase de passe dans le trousseau. Sous Windows, le service \u00ab Agent d’authentification OpenSSH \u00bb remplit le m\u00eame r\u00f4le ; activez-le puis utilisez ssh-add<\/code> dans PowerShell.<\/p>\n\n\n\n
Un mot d’avertissement sur la redirection d’agent<\/strong> (ssh -A<\/code> ou ForwardAgent yes<\/code>). 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\u00f4tes de confiance, et pr\u00e9f\u00e9rez ProxyJump<\/code> (ssh -J<\/code>) pour traverser un rebond sans exposer l’agent.<\/p>\n\n\n\n
\u00c9tape 9 : d\u00e9sactiver l’authentification par mot de passe<\/h2>\n\n\n\n
C’est l’\u00e9tape qui s\u00e9curise r\u00e9ellement le serveur. Tant que le mot de passe reste accept\u00e9, les robots continueront leurs tentatives de force brute. Une fois votre connexion par cl\u00e9 valid\u00e9e, d\u00e9sactivez les mots de passe dans la configuration du d\u00e9mon SSH.<\/p>\n\n\n\n
# \u00c9diter la configuration du serveur (sur le serveur)\nsudo nano \/etc\/ssh\/sshd_config\n\n# R\u00e9glages \u00e0 appliquer\nPubkeyAuthentication yes\nPasswordAuthentication no\nChallengeResponseAuthentication no\nKbdInteractiveAuthentication no\nPermitRootLogin prohibit-password\nUsePAM yes<\/code><\/pre>\n\n\n\n
Sur les distributions r\u00e9centes, certains r\u00e9glages vivent dans des fichiers s\u00e9par\u00e9s sous \/etc\/ssh\/sshd_config.d\/<\/code>. Un fichier comme 50-cloud-init.conf<\/code> peut r\u00e9activer PasswordAuthentication yes<\/code> et \u00e9craser votre r\u00e9glage. V\u00e9rifiez l’ensemble avec sudo sshd -T | grep -i passwordauthentication<\/code>, qui affiche la valeur r\u00e9ellement appliqu\u00e9e apr\u00e8s fusion de tous les fichiers.<\/p>\n\n\n\n
# Tester la configuration AVANT de red\u00e9marrer (d\u00e9tecte les erreurs de syntaxe)\nsudo sshd -t\n\n# Recharger le service sans couper les sessions existantes\nsudo systemctl reload ssh   # Debian\/Ubuntu\nsudo systemctl reload sshd  # Fedora\/RHEL\n\n# Confirmer la valeur effective\nsudo sshd -T | grep -i passwordauthentication\n# passwordauthentication no<\/code><\/pre>\n\n\n\n
Ne fermez surtout pas votre session de secours avant d’avoir ouvert une nouvelle connexion par cl\u00e9 dans un autre terminal. Si la nouvelle connexion r\u00e9ussit, vous pouvez fermer l’ancienne sereinement. Si elle \u00e9choue, votre session d\u00e9j\u00e0 ouverte vous permet de corriger sshd_config<\/code> et de recharger le service sans perdre l’acc\u00e8s.<\/p>\n\n\n\n
\u00c9tape 10 : durcir le serveur et activer le post-quantique<\/h2>\n\n\n\n
Au-del\u00e0 de la d\u00e9sactivation des mots de passe, quelques r\u00e9glages renforcent nettement la posture du serveur. Ils limitent les algorithmes faibles, r\u00e9duisent la fen\u00eatre des attaques et activent l’\u00e9change de cl\u00e9s r\u00e9sistant au quantique.<\/p>\n\n\n\n
# Durcissement de \/etc\/ssh\/sshd_config\n# \u00c9change de cl\u00e9s hybride post-quantique en priorit\u00e9\nKexAlgorithms mlkem768x25519-sha256,sntrup761x25519-sha512,curve25519-sha256\n\n# N'accepter que les cl\u00e9s h\u00f4tes et algos de signature modernes\nHostKeyAlgorithms ssh-ed25519,rsa-sha2-512,rsa-sha2-256\nPubkeyAcceptedAlgorithms ssh-ed25519,sk-ssh-ed25519@openssh.com,rsa-sha2-512\n\n# R\u00e9duire la surface d'attaque\nMaxAuthTries 3\nLoginGraceTime 20\nAllowUsers sam\nX11Forwarding no<\/code><\/pre>\n\n\n\n
La directive KexAlgorithms<\/code> place l’\u00e9change hybride post-quantique en t\u00eate. Le principe de l’hybride est simple : il combine un m\u00e9canisme post-quantique (ML-KEM 768, normalis\u00e9 par le NIST, ou NTRU Prime) avec X25519 classique. M\u00eame si l’un des deux est cass\u00e9, le secret reste prot\u00e9g\u00e9 par l’autre. Cela prot\u00e8ge contre la strat\u00e9gie \u00ab r\u00e9colter maintenant, d\u00e9chiffrer plus tard \u00bb, o\u00f9 un attaquant enregistre aujourd’hui le trafic chiffr\u00e9 pour le casser quand un ordinateur quantique sera disponible.<\/p>\n\n\n\n
MaxAuthTries 3<\/code> coupe la connexion apr\u00e8s trois \u00e9checs, et LoginGraceTime 20<\/code> r\u00e9duit le d\u00e9lai avant authentification, ce qui g\u00eane les attaques par \u00e9puisement de connexions. AllowUsers<\/code> restreint la liste des comptes autoris\u00e9s \u00e0 se connecter en SSH. Pour aller plus loin, associez ce durcissement \u00e0 un outil de bannissement d’IP comme Fail2ban, qui bloque automatiquement les adresses trop insistantes. Testez toujours avec sudo sshd -t<\/code> avant de recharger.<\/p>\n\n\n\n
\u00c9tape 11 : cl\u00e9s mat\u00e9rielles FIDO2 (ed25519-sk)<\/h2>\n\n\n\n
Pour les comptes les plus sensibles, une cl\u00e9 mat\u00e9rielle FIDO2 (YubiKey, Nitrokey, etc.) lie la cl\u00e9 SSH \u00e0 un appareil physique. La partie secr\u00e8te ne quitte jamais le jeton : m\u00eame une machine enti\u00e8rement compromise ne peut pas voler la cl\u00e9, car chaque authentification exige une pr\u00e9sence physique (toucher le bouton du jeton).<\/p>\n\n\n\n
# G\u00e9n\u00e9rer une cl\u00e9 SSH adoss\u00e9e \u00e0 un jeton FIDO2\nssh-keygen -t ed25519-sk -O resident -O verify-required \\\n  -C \"sam@yubikey\" -f ~\/.ssh\/id_ed25519_sk\n\n# Sortie\n# Generating public\/private ed25519-sk key pair.\n# You may need to touch your authenticator to authorize key generation.\n# Enter PIN for authenticator:\n# Your identification has been saved in \/home\/sam\/.ssh\/id_ed25519_sk<\/code><\/pre>\n\n\n\n
Le suffixe -sk<\/code> (pour security key<\/em>) indique une cl\u00e9 adoss\u00e9e \u00e0 un dispositif FIDO2, disponible depuis OpenSSH 8.2. L’option -O resident<\/code> stocke une r\u00e9f\u00e9rence sur le jeton lui-m\u00eame, ce qui permet de r\u00e9cup\u00e9rer la cl\u00e9 sur une nouvelle machine. -O verify-required<\/code> impose la saisie du code PIN du jeton \u00e0 chaque usage, en plus du toucher physique. D\u00e9ployez la cl\u00e9 publique id_ed25519_sk.pub<\/code> exactement comme une cl\u00e9 classique, via ssh-copy-id<\/code>.<\/p>\n\n\n\n
C\u00f4t\u00e9 serveur, autorisez ce type de cl\u00e9 avec PubkeyAcceptedAlgorithms sk-ssh-ed25519@openssh.com<\/code> (d\u00e9j\u00e0 inclus \u00e0 l’\u00e9tape 10). Si vous changez de poste de travail, r\u00e9cup\u00e9rez les cl\u00e9s r\u00e9sidentes stock\u00e9es sur le jeton avec ssh-keygen -K<\/code>, qui t\u00e9l\u00e9charge les r\u00e9f\u00e9rences depuis le mat\u00e9riel vers le dossier .ssh<\/code> local. C’est la solution la plus robuste contre le vol de cl\u00e9, recommand\u00e9e pour les administrateurs et les acc\u00e8s \u00e0 privil\u00e8ges \u00e9lev\u00e9s.<\/p>\n\n\n\n
\u00c9tape 12 : rotation, r\u00e9vocation et inventaire des cl\u00e9s<\/h2>\n\n\n\n
Une cl\u00e9 SSH n’est pas \u00e9ternelle. La rotation r\u00e9guli\u00e8re limite l’impact d’une fuite pass\u00e9e inaper\u00e7ue. Planifiez un renouvellement (par exemple tous les 12 mois pour les cl\u00e9s personnelles, plus court pour les comptes de service) et r\u00e9voquez imm\u00e9diatement une cl\u00e9 apr\u00e8s la perte d’un appareil, le d\u00e9part d’un collaborateur ou un soup\u00e7on de compromission.<\/p>\n\n\n\n
# R\u00e9voquer une cl\u00e9 : retirer sa ligne de authorized_keys sur le serveur\n# Rep\u00e9rer la cl\u00e9 par son commentaire\ngrep -n \"sam@ancien-portable\" ~\/.ssh\/authorized_keys\n\n# Supprimer la ligne correspondante (ex. ligne 2)\nsed -i '2d' ~\/.ssh\/authorized_keys\n\n# Lister toutes les empreintes autoris\u00e9es pour audit\nssh-keygen -lf ~\/.ssh\/authorized_keys<\/code><\/pre>\n\n\n\n
Pour les parcs importants, les certificats SSH<\/strong> simplifient la rotation. Au lieu de distribuer chaque cl\u00e9 publique sur chaque serveur, une autorit\u00e9 de certification (CA) signe les cl\u00e9s avec une dur\u00e9e de validit\u00e9 courte. Le serveur fait confiance \u00e0 la CA, pas \u00e0 chaque cl\u00e9 individuelle. Quand un certificat expire, l’acc\u00e8s cesse automatiquement, sans toucher aux fichiers authorized_keys<\/code>. C’est l’approche privil\u00e9gi\u00e9e pour g\u00e9rer des centaines de serveurs sans dispersion de cl\u00e9s statiques.<\/p>\n\n\n\n
# Cr\u00e9er une CA et signer une cl\u00e9 utilisateur (aper\u00e7u)\nssh-keygen -t ed25519 -f ~\/.ssh\/ca_user -C \"CA utilisateur\"\nssh-keygen -s ~\/.ssh\/ca_user -I \"sam\" -n sam \\\n  -V +52w ~\/.ssh\/id_ed25519.pub\n# Signed user key ~\/.ssh\/id_ed25519-cert.pub: id \"sam\" valid 52 weeks<\/code><\/pre>\n\n\n\n
Pi\u00e8ges courants \u00e0 \u00e9viter<\/h2>\n\n\n\n