Linux / Commande ssh-keygen : créer une paire de clés et vérifier l’empreinte

ssh-keygen crée une paire de clés SSH et permet d’en afficher l’empreinte. Conservez la clé privée sur votre poste et ne transmettez au serveur que la clé publique correspondante. Choisissez un nouveau nom de fichier et une phrase secrète adaptée : remplacer une ancienne clé peut supprimer votre moyen d’accès aux comptes qui lui font confiance.

Distinguer clé privée, clé publique et autorisation

SSH signifie Secure Shell. Dans l’authentification par clé publique, le client produit une signature avec la clé privée et le serveur la vérifie grâce à la clé publique autorisée pour le compte. La clé privée n’est pas envoyée au serveur pour cette vérification.

La génération ne crée aucun droit de connexion à elle seule. Il faut que l’administrateur ou le mécanisme autorisé de gestion du serveur enregistre la bonne clé publique pour le bon compte. La clé d’utilisateur ainsi créée est différente de la clé d’hôte qui permet au client de vérifier l’identité du serveur.

Le suffixe .pub est une convention utile, pas une protection cryptographique : renommer un fichier privé avec ce suffixe ne le rend pas public. Identifiez toujours le fichier par son rôle, pas seulement par son nom.

Créer une nouvelle paire Ed25519

Les exemples concernent OpenSSH. Vérifiez ssh -V et man ssh-keygen, puis la politique du client et du serveur pour le type de clé autorisé. L’option -t explicite le type, ici ed25519.

Si ~/.ssh n’existe pas, créez le répertoire avant de générer la clé. Sous Linux, ce dossier doit rester sous votre contrôle ; des permissions 700 limitent son accès à votre compte. Examinez ensuite les deux noms prévus et choisissez un autre nom si l’un existe déjà.

ssh-keygen -t ed25519 -f ~/.ssh/id_ed25519_work -C 'user@example.com'

-f fixe le nom de la clé privée ; le programme crée normalement aussi le fichier avec .pub ajouté. -C fournit le commentaire de gestion, ici une adresse fictive à remplacer par une étiquette appropriée. Il n’est pas nécessaire que ce commentaire corresponde au nom de connexion distant.

1. Confirmez que le chemin de sortie est nouveau et que le répertoire parent existe. Si une demande d’écrasement apparaît, arrêtez et vérifiez les fichiers existants.
2. À la demande Enter passphrase, saisissez une phrase secrète suffisamment robuste et non réutilisée selon votre politique. Les caractères peuvent ne pas s’afficher.
3. Confirmez la phrase secrète lorsque le programme la redemande, puis relevez les chemins des fichiers générés.
4. Vérifiez la clé publique et son empreinte avant tout enregistrement sur un serveur.

La phrase secrète protège le fichier privé au repos ; elle ne remplace pas la protection de la session ni des sauvegardes. Évitez de la placer dans des arguments visibles ou dans l’historique d’un shell. Pour un usage automatisé, choisissez un mécanisme de gestion de clés conforme à votre environnement plutôt que de supprimer cette protection par habitude.

Lire l’empreinte et retrouver la clé publique

ssh-keygen -lf ~/.ssh/id_ed25519_work.pub

Exemple de format, avec empreinte abrégée et non utilisable pour une comparaison réelle :

256 SHA256:... user@example.com (ED25519)

256 indique la taille affichée pour cette clé Ed25519, SHA256: introduit son empreinte et le texte final indique le type. Pour comparer, utilisez la même méthode d’empreinte et la valeur complète. Le commentaire peut aider à repérer une clé, mais deux commentaires identiques ne prouvent pas que les clés sont identiques.

Si le fichier public est perdu et que la clé privée reste disponible :

ssh-keygen -y -f ~/.ssh/id_ed25519_work

-y écrit la clé publique sur la sortie standard, sans publier le contenu privé. La phrase secrète du fichier peut être demandée. Cette commande ne recrée pas une clé privée perdue à partir d’une clé publique et ne rétablit pas une phrase secrète oubliée.

Pour enregistrer ensuite cette sortie dans un nouveau fichier public, vérifiez son chemin avant toute redirection : le shell peut écraser un fichier existant. Le commentaire du fichier public régénéré peut différer ; comparez le type et les données de clé ou leur empreinte, pas uniquement l’étiquette.

Protéger la clé et gérer un remplacement

Sous Linux, une clé privée appartient à son utilisateur et ne doit pas être lisible par d’autres comptes ; un mode 600 est une configuration habituelle. Vérifiez aussi les droits du répertoire et des copies de sauvegarde. Des permissions locales correctes ne protègent pas une copie privée déjà envoyée ailleurs.

Un changement de phrase secrète avec -p modifie la protection du fichier privé, pas l’autorisation de la clé sur les serveurs. Si la clé privée a été compromise, changer seulement sa phrase secrète ne révoque pas les copies déjà prises. Il faut retirer la clé publique compromise des comptes concernés et déployer une nouvelle paire selon la procédure prévue.

Si la phrase secrète est perdue, ssh-keygen ne peut pas la récupérer à partir du fichier. Utilisez un accès administratif de secours pour autoriser une nouvelle clé. Pour une rotation planifiée, vérifiez le nouvel accès dans une autre session avant de retirer l’ancien, et conservez les moyens de retour autorisés jusqu’à validation.

Transmettez uniquement la vraie clé publique au mécanisme d’enregistrement du serveur. La connexion SSH avec choix d’identité et vérification de l’hôte explique comment utiliser ensuite le fichier privé local. Le manuel officiel ssh-keygen détaille les opérations de génération, d’empreinte et de gestion des fichiers.