Suite de clés SSH

Les limites honnêtes

La version 1 génère des clés non chiffrées : il n’y a pas d’option de phrase secrète ici, car le KDF bcrypt d’OpenSSH pour les clés privées chiffrées relève de la version 2. Protégez le fichier téléchargé avec chmod 600 et ajoutez une phrase secrète avec ssh-keygen -p si vous en avez besoin.

La génération d’Ed25519 exige un navigateur récent. Si le vôtre ne la prend pas en charge, cette page le dit clairement et propose ECDSA P-256 à la place — elle ne falsifie jamais une clé Ed25519 et ne vous fait jamais passer discrètement à un niveau inférieur.

Ne collez jamais une clé privée dans un chat, un ticket, un message de forum ou un document partagé — pas même pour demander si elle est sûre. Une clé privée apparue dans l’un de ces endroits doit être traitée comme compromise : remplacez-la et retirez l’ancienne clé publique de chaque fichier authorized_keys.

Ce qu’est l’authentification par clé SSH — et pourquoi elle bat un mot de passe

L’authentification par clé SSH remplace un secret tapé par une preuve mathématique. Quand vous vous connectez à un serveur avec une clé, le serveur envoie à votre machine un défi aléatoire ; votre machine le signe avec la clé privée, et le serveur vérifie la signature avec la clé publique d’authorized_keys. La clé privée ne traverse jamais le réseau, donc il n’y a rien qu’un enregistreur de frappe puisse voler, rien à hameçonner et rien à deviner — un attaquant ne peut pas forcer une clé Ed25519 de 256 bits comme il peut forcer un mot de passe, parce qu’il n’y a pas de mot de passe à essayer.

Les deux moitiés ont des règles opposées. La clé publique est faite pour être copiée partout : collez-la dans authorized_keys de chaque serveur, dans votre compte d’hébergement Git, dans tout service qui l’accepte. Elle permet seulement à l’autre partie de vérifier une preuve, donc la publier ne coûte rien. La clé privée est l’inverse : celui qui la détient peut se connecter comme vous, sur chaque serveur qui fait confiance à la clé publique correspondante. C’est pourquoi elle vit dans ~/.ssh, lisible par vous seul, et pourquoi elle ne doit jamais être collée dans un chat, un ticket, un courriel ou un document partagé — dès qu’elle apparaît dans l’un de ces endroits, elle a fuité, et la seule réparation est de la remplacer partout.

Choisir une clé, vérifier les empreintes et garder les fichiers propres

En 2026, le choix par défaut est Ed25519 : une clé de 256 bits plus rapide à générer et à signer que RSA, avec une clé publique qui tient sur une seule courte ligne. ECDSA P-256 est le repli quand une politique ou un vieux système insiste sur les courbes NIST, et RSA 3072 ou 4096 n’est la réponse que lorsque l’autre partie ne peut pas du tout utiliser de courbes elliptiques — RSA 2048 est le plancher, et tout ce qui est plus petit est signalé comme faible par cette page. Le type de clé compte moins que l’hygiène qui l’entoure : une clé forte laissée dans un fichier lisible par tout le monde, ou copiée sur un ordinateur portable que vous ne possédez plus, vaut moins qu’une clé modeste bien gardée.

Les empreintes sont la façon de savoir que vous parlez à la bonne machine. La première fois que vous vous connectez à un serveur, SSH vous montre l’empreinte de la clé d’hôte du serveur et vous demande de lui faire confiance ; cette empreinte est un condensé de la clé publique du serveur, et si elle correspond à celle publiée par votre administrateur, personne n’est assis au milieu. Enregistrez-la, et SSH vous avertira bruyamment si elle change un jour. Les mêmes empreintes identifient vos propres clés : ssh-keygen -lf affiche une ligne par clé, et cette page affiche les empreintes exactement dans le même format, pour que les valeurs que vous voyez ici puissent être comparées caractère par caractère avec celles du serveur.

Les fichiers méritent un audit régulier, parce que les clés s’accumulent. Chaque ligne d’authorized_keys est une porte vers un serveur, 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 CI, une clé générée sur une machine depuis effacée. Collez le fichier dans l’onglet Inspecter et cette page compte les clés, signale les doublons, marque les types faibles et anciens, et liste les lignes qu’elle n’a pas pu analyser au lieu de les écarter silencieusement. Faites de même pour known_hosts, où les entrées hachées cachent le nom d’hôte — cette page les signale comme hachées plutôt que de prétendre qu’elles sont lisibles. Un audit de dix minutes tous les quelques mois est le travail de sécurité le moins cher qu’un propriétaire de serveur fasse jamais.

La suite, en termes simples

Questions fréquentes