Les clés SSH expliquées
L’authentification par clé SSH est la façon de se connecter à un serveur sans mot de passe : au lieu de taper un secret que le serveur peut vérifier, votre ordinateur prouve qu’il détient une clé privée en signant un défi envoyé par le serveur, et le serveur vérifie la signature avec la clé publique qu’il a déjà archivée. La clé privée ne traverse jamais le réseau, donc il n’y a rien à intercepter, rien à hameçonner et rien à deviner. Cet article explique comment fonctionnent les deux moitiés d’une paire de clés, quel type de clé choisir en 2026, comment les empreintes arrêtent un intermédiaire lors de votre première connexion, comment garder authorized_keys et known_hosts propres, et exactement quoi faire quand une clé fuit. Pour générer, inspecter ou convertir une clé dans votre navigateur, utilisez la Suite de clés SSH, et pour vérifier les mots de passe que vous utilisez encore, la Vérification de fuite de mot de passe.
Ce qu’est l’authentification par clé SSH
Chaque connexion est une question posée par le serveur — êtes-vous bien la personne que vous prétendez être ? — et un mot de passe y répond en remettant le secret lui-même. C’est la faiblesse de tout l’arrangement : le secret voyage, il peut être écouté, il peut être rejoué, et il peut être deviné, tentative après tentative, jusqu’à tomber. L’authentification par clé SSH change la réponse. Au lieu d’envoyer le secret, votre ordinateur signe un défi aléatoire du serveur avec une clé privée qui ne quitte jamais votre machine, et le serveur vérifie la signature avec la clé publique stockée dans votre fichier authorized_keys. La preuve est nouvelle à chaque fois, parce que le défi est aléatoire ; le secret n’apparaît jamais sur le câble, donc un écouteur n’apprend rien qu’il puisse réutiliser, et il n’y a pas de mot de passe à deviner, parce qu’aucun mot de passe n’est en jeu.
L’idée est plus ancienne que l’internet moderne — la cryptographie à clé publique date des années 1970 — mais SSH en a fait la façon quotidienne d’atteindre un serveur, et le protocole la porte depuis. Quand vous exécutez ssh utilisateur@serveur, le client et le serveur conviennent d’une session, le serveur présente un défi lié à votre compte, et votre agent SSH le signe avec la clé privée, généralement après que vous avez déverrouillé la clé une fois avec une phrase secrète. Si la signature est vérifiée, vous entrez. Rien dans l’échange ne dépend d’un secret partagé que le serveur connaîtrait aussi, et c’est pourquoi une brèche du serveur n’expose pas vos identifiants : le serveur ne détient que des clés publiques, et une clé publique est inutile pour se connecter. Cette asymétrie — le serveur peut vérifier mais ne peut pas se faire passer pour vous — est tout l’argument de sécurité des clés, et c’est aussi la raison pour laquelle perdre le contrôle de la moitié privée est la seule défaillance qui compte.
La clé publique et la clé privée
Une paire de clés, ce sont deux moitiés aux règles opposées, et la plupart des erreurs SSH viennent de les traiter de la même façon. La clé publique est faite pour être copiée partout : collez-la dans authorized_keys de chaque serveur que vous utilisez, dans votre compte d’hébergement Git, dans tout service qui accepte les clés SSH. Elle peut être publiée dans un dépôt public, imprimée sur une diapositive ou envoyée par courriel à un administrateur, parce que tout ce qu’elle permet à quiconque, c’est de vérifier une signature. Connaître votre clé publique ne donne à un attaquant rien pour se connecter, de la même façon que connaître votre numéro de maison ne donne à personne la clé de votre porte. La moitié publique est une serrure, pas une clé, et les serrures sont faites pour être vues.
La clé privée est la clé elle-même, et sa règle est exactement l’inverse : elle ne quitte jamais votre machine, vous seul pouvez la lire, et elle ne doit jamais être collée dans un chat, un ticket, un courriel, un message de forum ou un document partagé — pas même pour demander si elle est sûre. Celui qui la détient peut se connecter comme vous sur chaque serveur qui fait confiance à la clé publique correspondante, sans invite de mot de passe ni second facteur sur le chemin, à moins que vous en ayez configuré un. Sur le disque, elle vit dans ~/.ssh, protégée par les permissions de fichier — chmod 600, lecture et écriture du propriétaire seulement — et idéalement par une phrase secrète, qui chiffre le fichier pour qu’une copie volée reste inutile sans les mots qui la déverrouillent. La phrase secrète ne fait pas partie de la clé ; c’est un cadenas sur la boîte où repose la clé. Perdez la boîte et le cadenas est la seule chose entre le voleur et vos serveurs, et c’est pourquoi une clé privée sans phrase secrète ne doit jamais quitter une machine que vous contrôlez entièrement.
Ed25519 contre ECDSA et RSA : laquelle choisir en 2026
En 2026, la réponse par défaut est Ed25519, et c’est le choix par défaut que génère ce site. Ed25519 est une clé à courbe elliptique de 256 bits : elle se génère en une fraction de seconde, signe rapidement et produit une clé publique qui tient sur une seule courte ligne. Elle est prise en charge par OpenSSH depuis 2014 et par tous les serveurs et clients actuels, et sa sécurité repose sur une courbe conçue ouvertement, sans constantes suspectes. Il n’y a aucune raison pratique de choisir autre chose pour une nouvelle clé, à moins que quelque chose dans votre environnement vous y force. Si vous ne retenez qu’une recommandation de cet article, que ce soit celle-ci : générez Ed25519, définissez une phrase secrète et passez à autre chose.
Les autres types existent pour les exceptions. ECDSA sur les courbes NIST P-256 ou P-384 est le bon choix là où la politique exige des courbes NIST — certains environnements réglementés et d’anciens jetons matériels les spécifient — et c’est un bon repli si un navigateur ou un appareil ne peut pas générer Ed25519. RSA reste le repli universel : RSA 2048 est le minimum qui vaille la peine, RSA 3072 ou 4096 le choix quand l’autre partie ne peut pas du tout utiliser de courbes elliptiques, ce qui aujourd’hui signifie surtout des systèmes très anciens et quelques appareils embarqués. Tout ce qui est inférieur à RSA 2048 — RSA 1024, DSA, ssh-dss — est de l’ancien monde et doit être retiré : la Suite de clés SSH le signale comme faible pour exactement cette raison. La taille de la clé n’est pas tout, cependant : une clé RSA de 4096 bits copiée sur un ordinateur portable que vous ne possédez plus vaut moins qu’une clé Ed25519 de 256 bits bien gardée, parce que le mode de défaillance des clés SSH n’est presque jamais les mathématiques. C’est le fichier.
Les empreintes et la première connexion
La première fois que vous vous connectez à un serveur, SSH vous montre quelque chose qui ressemble à une chaîne aléatoire de caractères et vous demande si vous lui faites confiance : 256 SHA256:M8zvXkwyrGfPUmaHSSdA1aFQkH8AVSRycOxaZHru7dQ. Cette chaîne est l’empreinte de la clé d’hôte du serveur — un condensé de la clé publique du serveur — et c’est la seule chose entre vous et un intermédiaire. Si l’empreinte correspond à celle publiée par votre administrateur, ou à celle que vous avez vérifiée par un canal séparé, alors la machine qui répond est bien le serveur que vous vouliez atteindre. Si elle ne correspond pas, arrêtez-vous : quelqu’un peut être en train d’intercepter la connexion, ou le serveur a pu être reconstruit avec une nouvelle clé, et dans tous les cas le geste sûr est de vérifier avant de taper yes. Cette invite est SSH à son travail le plus important, et les gens qui s’attirent des ennuis sont ceux qui s’entraînent à taper yes sans la lire.
Vous pouvez vérifier une empreinte avant même de vous connecter, avec ssh-keygen -lf, qui affiche une ligne par clé : la taille en bits, l’empreinte, le commentaire et le type de clé entre crochets, par exemple 256 SHA256:… [email protected] (ED25519). La Suite de clés SSH affiche les empreintes exactement dans ce format, pour qu’une valeur vue dans le navigateur puisse être comparée caractère par caractère avec ce que montre le serveur. Une fois que vous acceptez une clé d’hôte, SSH l’enregistre dans ~/.ssh/known_hosts et vous avertit bruyamment — en refusant de se connecter — si elle change un jour. Cet avertissement n’est pas une gêne à contourner avec une option ; c’est l’alarme qui sonne. La seule exception de routine est un serveur légitimement reconstruit, auquel cas l’administrateur aurait dû publier la nouvelle empreinte à l’avance, et vous retirez l’ancienne entrée avec ssh-keygen -R nomdhôte avant de vous reconnecter.
L’hygiène d’authorized_keys et de known_hosts
Chaque ligne du fichier authorized_keys d’un serveur est une porte, et les portes restent ouvertes longtemps après le départ de la personne qui en avait besoin. L’ordinateur portable d’un prestataire, une tâche d’intégration continue, une clé générée sur une machine depuis effacée, un collègue qui a changé d’équipe il y a deux ans — chacune est une ligne qui fonctionne encore, et chacune est un identifiant que vous ne surveillez plus. L’audit est simple et vaut la peine tous les quelques mois : copiez le fichier, collez-le dans l’onglet Inspecter de la Suite de clés SSH et regardez ce qui revient. Les doublons — la même clé publique deux fois — signifient que quelqu’un a collé une clé à nouveau au lieu de vérifier, et doivent être réduits à une ligne. Les entrées faibles — RSA en dessous de 2048, DSA, ssh-dss — doivent être retirées et remplacées. Et toute ligne dont le commentaire nomme une personne, une machine ou un usage que vous ne reconnaissez plus doit être traitée comme une porte à fermer jusqu’à ce que son propriétaire puisse la réclamer.
known_hosts mérite la même attention de l’autre côté. Il enregistre la clé d’hôte de chaque serveur auquel vous vous êtes connecté, et SSH vérifie chaque nouvelle connexion avec lui. Certaines entrées sont hachées — |1| suivi de base64 — ce qui masque le nom d’hôte, une fonction de confidentialité pour les ordinateurs portables qui pourraient être perdus ou inspectés ; la Suite de clés SSH signale ces entrées comme hachées plutôt que de prétendre qu’elles sont lisibles, parce qu’une entrée hachée ne peut pas être vérifiée contre une empreinte publiée, seulement digne de confiance comme déjà acceptée. Le fichier lui-même est aussi une preuve : un known_hosts plein de serveurs que vous n’utilisez plus est une carte des endroits où vos identifiants sont passés, et l’élaguer ne coûte rien. Ensemble, les deux fichiers sont l’enregistrement complet de votre confiance SSH dans les deux directions — qui peut se connecter comme vous, et à quelles machines vous faites confiance pour être elles-mêmes — et les deux pourrissent silencieusement si personne ne regarde.
Quand une clé fuit — et la note sur la phrase secrète
Une clé compromise n’est pas un mystère à élucider d’abord et sur lequel agir ensuite ; c’est une clé à remplacer, et l’ordre des opérations est court. Générez une nouvelle paire de clés. Retirez l’ancienne clé publique d’authorized_keys sur chaque serveur et chaque service — vos serveurs, votre hébergement Git, vos pipelines de déploiement, partout où la clé a été installée. Puis vérifiez ce que l’ancienne clé pouvait atteindre et cherchez tout ce qui est hors de place : de nouvelles lignes dans authorized_keys que vous n’avez pas ajoutées, des connexions à des heures où vous ne travailliez pas, des processus inconnus. Si vous trouvez quelque chose, traitez-le comme une brèche, pas comme une frayeur, et enquêtez à partir de là. Ce qu’il ne faut pas faire, c’est supprimer l’ancienne clé privée de votre ordinateur portable et considérer le travail comme fait : supprimer votre copie ne fait rien aux copies qui ont fuité, et la clé publique toujours assise dans authorized_keys reste une porte qui fonctionne.
Une phrase secrète ne change pas cette liste, mais elle change l’urgence avec laquelle vous l’exécutez. Une clé protégée par une phrase secrète qui fuit sous forme de fichier reste un problème — un attaquant peut essayer de deviner la phrase hors ligne, à vitesse machine — mais une phrase forte vous achète le temps de tourner avant que la devinette réussisse. Une clé non chiffrée n’achète aucun temps, et c’est pourquoi ce site est franc sur ce que produit son générateur : la version 1 génère des clés non chiffrées, sans option de phrase secrète, parce que le KDF bcrypt d’OpenSSH pour les clés privées chiffrées relève de la version 2. Si vous générez une clé ici, protégez le fichier avec chmod 600 et ajoutez une phrase secrète sur votre propre machine avec ssh-keygen -p — cela prend dix secondes, cela convertit le fichier sur place, et c’est l’habitude la plus précieuse de tout cet article. Générez la clé, définissez la phrase secrète, installez seulement la moitié publique, auditez les fichiers deux fois par an et vérifiez chaque empreinte avant de lui faire confiance : c’est toute la discipline, et elle tient sur une fiche.