{"id":147,"date":"2026-06-14T16:26:46","date_gmt":"2026-06-14T16:26:46","guid":{"rendered":"https:\/\/shattered.io\/fr\/2026\/06\/14\/cle-ssh-ssh-keygen\/"},"modified":"2026-06-14T16:28:12","modified_gmt":"2026-06-14T16:28:12","slug":"cle-ssh-ssh-keygen","status":"publish","type":"post","link":"https:\/\/shattered.io\/fr\/2026\/06\/14\/cle-ssh-ssh-keygen\/","title":{"rendered":"Cl\u00e9 SSH : connexion sans mot de passe, 12 \u00e9tapes [2026]"},"content":{"rendered":"\n

Le mot de passe SSH est le maillon faible de presque tous les serveurs Linux expos\u00e9s sur Internet. Les robots d’attaque par force brute frappent le port 22 en continu, et un seul identifiant devin\u00e9 ouvre l’acc\u00e8s complet \u00e0 la machine. L’authentification par cl\u00e9 SSH<\/strong> supprime ce risque : au lieu d’un secret partag\u00e9 que l’on tape, vous pr\u00e9sentez une preuve cryptographique qu’un serveur ne peut ni deviner ni rejouer. Ce tutoriel vous guide en 12 \u00e9tapes pour g\u00e9n\u00e9rer une cl\u00e9 SSH moderne avec ssh-keygen<\/code>, la d\u00e9ployer sur vos serveurs, d\u00e9sactiver compl\u00e8tement les mots de passe et durcir le d\u00e9mon SSH selon les recommandations de l’ANSSI et de Mozilla.<\/p>\n\n\n\n

Comptez environ 30 minutes pour la configuration de base, et 60 minutes si vous ajoutez le durcissement serveur et une cl\u00e9 mat\u00e9rielle FIDO2. Toutes les commandes ont \u00e9t\u00e9 test\u00e9es sur Ubuntu 26.04 LTS et Debian 13 \u00ab Trixie \u00bb avec OpenSSH 10.x, mais elles s’appliquent \u00e0 macOS, Windows 11 (OpenSSH int\u00e9gr\u00e9) et toute distribution Linux r\u00e9cente.<\/p>\n\n\n\n

Pourquoi abandonner les mots de passe SSH en 2026<\/h2>\n\n\n\n

Un mot de passe, m\u00eame long, reste un secret r\u00e9utilisable. S’il fuite via un keylogger, un d\u00e9p\u00f4t Git public ou une attaque par dictionnaire, l’attaquant obtient un acc\u00e8s direct. Une cl\u00e9 SSH<\/strong> fonctionne diff\u00e9remment. Vous g\u00e9n\u00e9rez une paire math\u00e9matiquement li\u00e9e : une cl\u00e9 priv\u00e9e qui ne quitte jamais votre poste, et une cl\u00e9 publique que vous distribuez librement. Le serveur stocke la cl\u00e9 publique et lance un d\u00e9fi cryptographique \u00e0 chaque connexion. Seul le d\u00e9tenteur de la cl\u00e9 priv\u00e9e peut y r\u00e9pondre. Aucun secret r\u00e9utilisable ne transite sur le r\u00e9seau.<\/p>\n\n\n\n

L’\u00e9cart de s\u00e9curit\u00e9 est mesurable. Une cl\u00e9 Ed25519 offre un niveau de r\u00e9sistance d’environ 128 bits, l’\u00e9quivalent d’un mot de passe al\u00e9atoire d’une trentaine de caract\u00e8res que personne ne pourrait m\u00e9moriser ni saisir. Les serveurs publics subissent des milliers de tentatives d’authentification par mot de passe chaque jour. En d\u00e9sactivant PasswordAuthentication<\/code>, vous rendez ces attaques structurellement impossibles : il n’y a plus rien \u00e0 deviner.<\/p>\n\n\n\n

Les cl\u00e9s SSH apportent aussi du confort op\u00e9rationnel. Une fois la cl\u00e9 charg\u00e9e dans ssh-agent<\/code>, vous ne tapez plus rien pour vous connecter. Vous automatisez les d\u00e9ploiements, les sauvegardes via rsync<\/code> et les pipelines CI\/CD sans coller de mot de passe dans un script. Et contrairement \u00e0 un mot de passe partag\u00e9, chaque cl\u00e9 est nominative : vous r\u00e9voquez l’acc\u00e8s d’un d\u00e9veloppeur en supprimant une seule ligne du fichier authorized_keys<\/code>, sans changer le secret de toute l’\u00e9quipe.<\/p>\n\n\n\n

L’ANSSI, l’agence nationale fran\u00e7aise de cybers\u00e9curit\u00e9, recommande de longue date l’authentification par cl\u00e9 publique pour l’administration des syst\u00e8mes, et de proscrire l’acc\u00e8s direct du compte root. Les r\u00e9f\u00e9rentiels d’h\u00e9bergeurs europ\u00e9ens vont dans le m\u00eame sens : OVHcloud, Scaleway et Hetzner proposent tous le d\u00e9p\u00f4t d’une cl\u00e9 publique d\u00e8s la cr\u00e9ation d’une instance, pr\u00e9cis\u00e9ment pour \u00e9viter la phase \u00e0 risque o\u00f9 le serveur n’accepte qu’un mot de passe. Adopter les cl\u00e9s SSH n’est donc pas une coquetterie d’expert, c’est la configuration attendue d’un serveur de production en 2026.<\/p>\n\n\n\n

Pour aller plus loin sur la protection du port 22 contre les attaques r\u00e9siduelles, notre tutoriel Fail2ban pour prot\u00e9ger SSH<\/a> compl\u00e8te parfaitement cette approche par cl\u00e9s. Les deux se combinent : la cl\u00e9 SSH supprime l’authentification par mot de passe, et Fail2ban bannit les adresses IP qui multiplient les sondages, ce qui all\u00e8ge vos journaux.<\/p>\n\n\n\n

Comment fonctionne l’authentification par cl\u00e9 SSH<\/h2>\n\n\n\n

L’authentification par cl\u00e9 SSH<\/strong> repose sur la cryptographie asym\u00e9trique. La cl\u00e9 priv\u00e9e et la cl\u00e9 publique forment un couple indissociable. Ce qu’une cl\u00e9 signe, l’autre le v\u00e9rifie, mais on ne peut pas reconstruire la cl\u00e9 priv\u00e9e \u00e0 partir de la cl\u00e9 publique en un temps raisonnable. C’est cette asym\u00e9trie qui permet de publier la cl\u00e9 publique sans aucun risque.<\/p>\n\n\n\n

Voici le d\u00e9roul\u00e9 d’une connexion. Votre client SSH contacte le serveur et annonce qu’il souhaite s’authentifier avec une cl\u00e9. Le serveur consulte le fichier ~\/.ssh\/authorized_keys<\/code> de l’utilisateur cibl\u00e9 pour v\u00e9rifier qu’il conna\u00eet la cl\u00e9 publique correspondante. Si oui, un \u00e9change de d\u00e9fi-r\u00e9ponse a lieu : le serveur s’assure, via une signature num\u00e9rique, que le client d\u00e9tient bien la cl\u00e9 priv\u00e9e associ\u00e9e. Aucun moment de cet \u00e9change ne r\u00e9v\u00e8le la cl\u00e9 priv\u00e9e, et chaque session \u00e9tablit ses propres cl\u00e9s de chiffrement \u00e9ph\u00e9m\u00e8res.<\/p>\n\n\n\n

Un second m\u00e9canisme prot\u00e8ge l’autre sens de la relation : la cl\u00e9 d’h\u00f4te du serveur. Lors de votre toute premi\u00e8re connexion, le client affiche l’empreinte de la cl\u00e9 d’h\u00f4te et l’enregistre dans ~\/.ssh\/known_hosts<\/code>. Ce mod\u00e8le, appel\u00e9 \u00ab confiance \u00e0 la premi\u00e8re utilisation \u00bb (TOFU), garantit qu’aux connexions suivantes vous parlez bien au m\u00eame serveur. Si l’empreinte change sans raison, OpenSSH refuse net la connexion : c’est sa protection int\u00e9gr\u00e9e contre les attaques de l’intercepteur. V\u00e9rifiez toujours l’empreinte affich\u00e9e \u00e0 la premi\u00e8re connexion aupr\u00e8s de votre h\u00e9bergeur, qui la publie g\u00e9n\u00e9ralement dans son panneau de gestion.<\/p>\n\n\n\n

Pourquoi Ed25519 plut\u00f4t que RSA<\/h3>\n\n\n\n

OpenSSH propose plusieurs algorithmes, mais en 2026 le choix par d\u00e9faut recommand\u00e9 est Ed25519<\/strong>. Cet algorithme de signature s’appuie sur la courbe elliptique Curve25519, con\u00e7ue par Daniel J. Bernstein. Il produit des cl\u00e9s de seulement 256 bits, soit une cl\u00e9 publique d’environ 68 caract\u00e8res, l\u00e0 o\u00f9 une cl\u00e9 RSA \u00e9quivalente exige 3072 ou 4096 bits. Ed25519 signe et v\u00e9rifie plus vite, r\u00e9siste aux attaques par canaux auxiliaires par conception, et son impl\u00e9mentation laisse peu de place aux erreurs de configuration.<\/p>\n\n\n\n

RSA 4096 bits reste un choix valable pour les syst\u00e8mes anciens qui ne comprennent pas Ed25519, mais il devient l’exception. ECDSA souffre de la m\u00e9fiance autour des courbes NIST et d’une d\u00e9pendance critique \u00e0 la qualit\u00e9 de l’al\u00e9a lors de la signature. Quant \u00e0 DSA, OpenSSH 10.0 (avril 2025) a d\u00e9finitivement retir\u00e9 sa prise en charge : ne g\u00e9n\u00e9rez plus jamais de cl\u00e9 DSA. Notre r\u00e8gle simple : Ed25519 partout, RSA 4096 uniquement en cas d’incompatibilit\u00e9 av\u00e9r\u00e9e.<\/p>\n\n\n\n

Pr\u00e9requis et versions logicielles<\/h2>\n\n\n\n

Avant de g\u00e9n\u00e9rer votre premi\u00e8re cl\u00e9 SSH<\/strong>, v\u00e9rifiez que votre environnement r\u00e9unit les \u00e9l\u00e9ments suivants. Le tableau pr\u00e9cise les versions utilis\u00e9es pour valider ce tutoriel en juin 2026.<\/p>\n\n\n\n

\u00c9l\u00e9ment<\/th>Version test\u00e9e<\/th>R\u00f4le<\/th><\/tr><\/thead>
OpenSSH (client et serveur)<\/td>10.x<\/td>G\u00e9n\u00e9ration de cl\u00e9s, connexion, d\u00e9mon sshd<\/td><\/tr>
Ubuntu Server<\/td>26.04 LTS<\/td>Serveur de d\u00e9monstration<\/td><\/tr>
Debian stable<\/td>13 \u00ab Trixie \u00bb<\/td>Alternative serveur<\/td><\/tr>
Noyau Linux<\/td>7.0<\/td>Base d’Ubuntu 26.04 LTS<\/td><\/tr>
Poste client<\/td>Linux, macOS 15+, Windows 11<\/td>L\u00e0 o\u00f9 r\u00e9side votre cl\u00e9 priv\u00e9e<\/td><\/tr>
Acc\u00e8s initial<\/td>mot de passe ou console<\/td>N\u00e9cessaire pour d\u00e9ployer la premi\u00e8re cl\u00e9<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

Vous avez besoin d’un compte utilisateur sur le serveur cible et d’un acc\u00e8s initial pour y d\u00e9poser votre cl\u00e9 publique, que ce soit par mot de passe temporaire, par console du fournisseur cloud ou par une cl\u00e9 d\u00e9j\u00e0 en place. Sur Windows 11, OpenSSH est inclus mais parfois d\u00e9sactiv\u00e9 : activez la fonctionnalit\u00e9 \u00ab Client OpenSSH \u00bb dans les param\u00e8tres optionnels. Sur macOS, le client est pr\u00e9sent nativement dans le Terminal.<\/p>\n\n\n\n

\u00c9tape 1 : V\u00e9rifier OpenSSH et sa version<\/h2>\n\n\n\n

Commencez par confirmer qu’OpenSSH est install\u00e9 et suffisamment r\u00e9cent pour g\u00e9rer Ed25519. Ouvrez un terminal sur votre poste client et lancez la commande suivante.<\/p>\n\n\n\n

ssh -V\n# Sortie attendue (exemple) :\n# OpenSSH_10.0p1, OpenSSL 3.5.0 1 Apr 2026<\/code><\/pre>\n\n\n\n
Toute version OpenSSH 6.5 ou sup\u00e9rieure prend en charge Ed25519, donc n’importe quel syst\u00e8me de 2026 convient largement. Si la commande renvoie une erreur sur Linux, installez le paquet avec sudo apt install openssh-client<\/code>. C\u00f4t\u00e9 serveur, v\u00e9rifiez que le d\u00e9mon est pr\u00e9sent avec sudo systemctl status ssh<\/code> sur Debian et Ubuntu (le service s’appelle parfois sshd<\/code> sur d’autres distributions).<\/p>\n\n\n\n
Profitez-en pour lister les cl\u00e9s d\u00e9j\u00e0 pr\u00e9sentes sur votre poste, afin de ne pas \u00e9craser une paire existante \u00e0 l’\u00e9tape suivante.<\/p>\n\n\n\n
ls -al ~\/.ssh\n# Cherchez des fichiers comme id_ed25519, id_ed25519.pub,\n# id_rsa, id_rsa.pub. Le suffixe .pub designe la cle publique.<\/code><\/pre>\n\n\n\n
\u00c9tape 2 : G\u00e9n\u00e9rer une paire de cl\u00e9s Ed25519<\/h2>\n\n\n\n
Le c\u0153ur du tutoriel. La commande ssh-keygen<\/code> cr\u00e9e votre paire de cl\u00e9s. Utilisez l’algorithme Ed25519, ajoutez un commentaire identifiant et renforcez la d\u00e9rivation de la phrase secr\u00e8te avec l’option -a<\/code>.<\/p>\n\n\n\n
ssh-keygen -t ed25519 -a 100 -C \"sam@poste-bureau-2026\"\n\n# -t ed25519  : type d'algorithme (recommande)\n# -a 100      : 100 tours de derivation KDF pour proteger la cle privee\n# -C \"...\"    : commentaire libre, utile pour identifier la cle<\/code><\/pre>\n\n\n\n
Le programme vous pose deux questions. La premi\u00e8re porte sur l’emplacement du fichier : acceptez la valeur par d\u00e9faut ~\/.ssh\/id_ed25519<\/code> en appuyant sur Entr\u00e9e, sauf si vous g\u00e9rez plusieurs cl\u00e9s (voir l’\u00e9tape 11). La seconde demande une phrase secr\u00e8te<\/strong>. Saisissez-en une, robuste et m\u00e9morisable. Elle chiffre la cl\u00e9 priv\u00e9e sur le disque : si votre ordinateur est vol\u00e9, le voleur ne pourra pas utiliser la cl\u00e9 sans cette phrase.<\/p>\n\n\n\n
Generating public\/private ed25519 key pair.\nEnter file in which to save the key (\/home\/sam\/.ssh\/id_ed25519):\nEnter passphrase (empty for no passphrase):\nEnter same passphrase again:\nYour identification has been saved in \/home\/sam\/.ssh\/id_ed25519\nYour public key has been saved in \/home\/sam\/.ssh\/id_ed25519.pub\nThe key fingerprint is:\nSHA256:8Hq2k...exemple...9fJ sam@poste-bureau-2026<\/code><\/pre>\n\n\n\n
L’image \u00ab randomart \u00bb affich\u00e9e \u00e0 la fin est une repr\u00e9sentation visuelle de l’empreinte. Elle aide \u00e0 rep\u00e9rer d’un coup d’\u0153il un changement de cl\u00e9 inattendu. Ne sautez jamais l’\u00e9tape de la phrase secr\u00e8te sur un poste de travail : une cl\u00e9 priv\u00e9e sans phrase secr\u00e8te \u00e9quivaut \u00e0 un mot de passe \u00e9crit en clair sur votre disque.<\/p>\n\n\n\n
\u00c9tape 3 : Comprendre les fichiers g\u00e9n\u00e9r\u00e9s<\/h2>\n\n\n\n
ssh-keygen<\/code> a cr\u00e9\u00e9 deux fichiers dans ~\/.ssh<\/code>. Comprendre leur r\u00f4le \u00e9vite la plupart des erreurs de d\u00e9butant, notamment le partage accidentel de la cl\u00e9 priv\u00e9e.<\/p>\n\n\n\n