Créer une clé SSH sous Linux et l’utiliser en sécurité

Pour créer une clé SSH Linux, lancez ssh-keygen -t ed25519, protégez la clé privée avec une phrase secrète, puis copiez la clé publique sur le serveur avec ssh-copy-id. La connexion s’effectue ensuite avec ssh utilisateur@serveur, sans saisir le mot de passe du compte distant si la configuration est correcte.

Une clé SSH est une paire de fichiers qui remplace l’authentification par mot de passe pour une connexion distante. Ce tutoriel montre comment générer une clé SSH, installer la clé publique dans authorized_keys, corriger les permissions et vérifier la première connexion avant de renforcer la configuration du serveur.

Comment fonctionne une clé SSH sous Linux ?

Une clé SSH est un mécanisme d’authentification asymétrique composé d’une clé privée, conservée secrète sur votre ordinateur, et d’une clé publique, déposée sur le serveur distant. Le serveur vérifie que votre client SSH possède bien la clé privée associée, sans que cette clé privée circule sur le réseau.

La clé publique autorise une connexion, tandis que la clé privée prouve votre identité. Copier le fichier public sur un serveur est normal ; envoyer le fichier privé par e-mail, messagerie ou dépôt Git est une erreur de sécurité.

Élément	Emplacement habituel	Rôle	À partager ?
Clé privée	~/.ssh/id_ed25519	Authentifie votre ordinateur	Non, jamais
Clé publique	~/.ssh/id_ed25519.pub	Autorise votre clé sur le serveur	Oui, uniquement vers les serveurs concernés
Liste des clés autorisées	~/.ssh/authorized_keys sur le serveur	Contient les clés publiques acceptées	Administrée sur le serveur

Une connexion SSH sans mot de passe ne signifie pas une connexion sans contrôle : la phrase secrète protège la clé privée si le poste est perdu ou compromis.

Prérequis avant de créer une paire de clés SSH

La procédure suppose que le client OpenSSH est disponible sur votre machine Linux, que vous connaissez le nom d’utilisateur du serveur et que le serveur accepte encore une connexion SSH par mot de passe. La commande ssh -V permet de vérifier la présence du client SSH et d’afficher sa version.

Préparez les informations nécessaires avant d’ouvrir le terminal. Une adresse IP, un nom de domaine ou un alias réseau insuffisant entraîne souvent une erreur attribuée à tort à la clé SSH.

• Le nom d’utilisateur du compte distant, par exemple alice.
• L’adresse du serveur, par exemple serveur.exemple.net ou une adresse IP.
• Le port SSH si le serveur n’utilise pas le port standard.
• Le mot de passe actuel du compte distant, utile pour le premier déploiement avec ssh-copy-id.
• Un accès administrateur au serveur si vous comptez ensuite modifier la configuration de sshd.

Les commandes décrites reposent sur OpenSSH, présent sur de nombreuses distributions Linux. Les noms de paquets et les outils d’installation peuvent varier selon Debian, Ubuntu, Fedora, Manjaro ou d’autres distributions ; la documentation de votre distribution reste le bon repère si la commande ssh est absente. Pour préparer un poste de travail, consultez aussi ce guide pour comprendre et utiliser Manjaro Linux.

Comment créer une clé SSH Linux étape par étape ?

Pour générer une clé SSH sous Linux, créez une paire Ed25519 avec ssh-keygen, choisissez un nom de fichier explicite et saisissez une phrase secrète. La commande crée deux fichiers dans ~/.ssh/ : un fichier privé sans extension et un fichier public portant l’extension .pub.

La génération de la clé doit se faire sur l’ordinateur depuis lequel vous vous connecterez au serveur. Une clé créée directement sur le serveur ne remplit pas le même rôle et complique inutilement la séparation entre client et machine distante.

Étape 1 : vérifier le dossier SSH local

Ouvrez un terminal et affichez le contenu du dossier utilisé par OpenSSH. Le répertoire ~/.ssh appartient à votre compte utilisateur et sert à stocker les clés, les fichiers de configuration et les empreintes des serveurs déjà rencontrés.

ls -la ~/.ssh

Le résultat attendu est soit une liste de fichiers existants, soit un message indiquant que le dossier n’existe pas encore. L’absence du dossier n’empêche pas la suite : ssh-keygen peut le créer lors de la génération.

Étape 2 : générer une paire Ed25519

Exécutez la commande suivante pour créer une clé Ed25519 dédiée à votre accès serveur. L’option -f fixe un nom explicite, ce qui évite d’écraser une clé existante et facilite la gestion de plusieurs environnements.

ssh-keygen -t ed25519 -f ~/.ssh/id_ed25519_serveur -C "acces-serveur"

À l’invite Enter passphrase, saisissez une phrase secrète longue et mémorisable. Le résultat attendu est la création de ~/.ssh/id_ed25519_serveur et de ~/.ssh/id_ed25519_serveur.pub.

Étape 3 : vérifier les fichiers créés

Contrôlez la présence des deux fichiers avant de passer au serveur. Le fichier sans extension est la clé privée ; le fichier terminé par .pub est la clé publique à déployer.

ls -l ~/.ssh/id_ed25519_serveur*

Ne copiez pas le fichier privé dans le presse-papiers, sur un serveur ou dans un outil de partage. Une clé RSA de 4096 bits reste une alternative utile lorsque la compatibilité Ed25519 pose problème ; dans ce cas, remplacez la commande par ssh-keygen -t rsa -b 4096 -f ~/.ssh/id_rsa_serveur.

Comment ajouter la clé publique sur un serveur distant ?

La méthode la plus simple consiste à utiliser ssh-copy-id, qui ajoute la clé publique au fichier ~/.ssh/authorized_keys du compte distant. Cette première opération demande généralement le mot de passe du compte serveur, car l’authentification par clé n’est pas encore active.

La commande doit viser le compte distant qui doit recevoir l’autorisation de connexion. Une clé déposée dans le répertoire personnel d’un autre utilisateur ne permettra pas de vous connecter avec votre compte habituel.

Étape 4 : copier la clé avec ssh-copy-id

Remplacez alice par votre utilisateur distant et serveur.exemple.net par l’adresse réelle du serveur. L’option -i indique précisément le fichier public à installer.

1. Exécutez la commande de copie depuis votre poste Linux.

   ssh-copy-id -i ~/.ssh/id_ed25519_serveur.pub [email protected]

2. Saisissez le mot de passe actuel du compte distant lorsque SSH le demande.
3. Attendez le message confirmant l’ajout de la clé publique.
4. Ne fermez pas encore la session ou l’accès par mot de passe : testez d’abord la clé.

Le résultat attendu est une nouvelle ligne dans ~/.ssh/authorized_keys sur le serveur. La page de manuel OpenSSH consacrée à ssh-copy-id détaille les options disponibles selon les installations.

Étape 5 : ajouter la clé manuellement si ssh-copy-id manque

La copie manuelle est utile lorsque ssh-copy-id n’est pas installé ou lorsque vous gérez le serveur depuis une console d’administration. Affichez d’abord la clé publique locale, puis copiez une ligne complète, sans retour à la ligne ajouté au milieu.

cat ~/.ssh/id_ed25519_serveur.pub

Sur le serveur, connecté avec le bon utilisateur, créez le dossier si nécessaire puis ajoutez la ligne publique dans authorized_keys. Le résultat attendu est un fichier lisible uniquement par le compte concerné.

mkdir -p ~/.ssh
chmod 700 ~/.ssh
nano ~/.ssh/authorized_keys
chmod 600 ~/.ssh/authorized_keys

Le fichier authorized_keys contient des clés publiques. Il ne doit jamais contenir une clé privée ni une phrase secrète.

Étape 6 : se connecter avec la clé SSH et vérifier le résultat

Testez la connexion dans un nouveau terminal afin de garder votre session actuelle disponible en cas d’erreur. La commande SSH utilise souvent automatiquement une clé standard, mais l’option -i évite toute ambiguïté lorsque vous avez choisi un nom de fichier personnalisé.

Exécutez la commande suivante et observez le comportement. Le résultat attendu est une connexion au serveur sans demande du mot de passe du compte distant ; une demande de phrase secrète est normale si la clé privée est protégée.

ssh -i ~/.ssh/id_ed25519_serveur [email protected]

Pour un serveur accessible sur un port différent, ajoutez l’option -p. Le numéro de port doit correspondre à la configuration réelle du serveur.

ssh -i ~/.ssh/id_ed25519_serveur -p 2222 [email protected]

Configurer plusieurs clés et simplifier les connexions

Le fichier ~/.ssh/config associe un alias à un hôte, un utilisateur, un port et une clé précise. Cette configuration est pratique lorsque vous utilisez plusieurs serveurs ou plusieurs clés, car elle évite de répéter une longue commande et réduit le risque de sélectionner la mauvaise identité.

Créez ou modifiez ~/.ssh/config, puis limitez ses permissions. Le résultat attendu est une connexion possible avec un alias court.

nano ~/.ssh/config

Host mon-serveur
    HostName serveur.exemple.net
    User alice
    IdentityFile ~/.ssh/id_ed25519_serveur
    Port 22

chmod 600 ~/.ssh/config
ssh mon-serveur

Le fichier de configuration permet aussi de séparer clairement les usages personnels, professionnels et administratifs. Cette logique de vérification des paramètres s’applique à d’autres accès numériques : le même réflexe aide, par exemple, à résoudre un problème de connexion sans confondre identifiant, serveur et méthode d’authentification.

Utiliser ssh-agent pour éviter de ressaisir la phrase secrète

ssh-agent conserve temporairement la clé déverrouillée dans la session utilisateur afin d’éviter une saisie répétée de la phrase secrète. L’agent ne supprime pas l’intérêt de la passphrase : il limite seulement le nombre de saisies pendant une session active.

Démarrez l’agent si votre environnement de bureau ne le lance pas déjà, puis ajoutez la clé privée. Le résultat attendu est une demande de phrase secrète unique, suivie de connexions SSH sans nouvelle demande pendant la session.

eval "$(ssh-agent -s)"
ssh-add ~/.ssh/id_ed25519_serveur

La commande suivante affiche les identités chargées dans l’agent. Pour retirer une clé précise, utilisez ssh-add -d ~/.ssh/id_ed25519_serveur.

ssh-add -l

Erreurs fréquentes lors d’une connexion SSH par clé

Une erreur SSH ne prouve pas que la clé est mauvaise. Le mécanisme dépend du bon fichier, du bon utilisateur distant, des permissions et de la configuration du service SSH. Le mode verbeux ssh -v montre les étapes de négociation et aide à localiser le blocage sans modifier le serveur au hasard.

• Le serveur demande encore le mot de passe : vérifiez que la clé publique est bien présente dans le authorized_keys du bon compte. Lancez ssh -i ~/.ssh/id_ed25519_serveur [email protected] pour forcer l’identité attendue.
• Erreur « Permission denied (publickey) » : contrôlez le nom d’utilisateur, la clé ciblée et les droits de ~/.ssh. Le dossier doit être en 700, les clés privées et authorized_keys en 600.
• Erreur « UNPROTECTED PRIVATE KEY FILE » : réduisez les droits de la clé privée avec chmod 600 ~/.ssh/id_ed25519_serveur. OpenSSH refuse volontairement une clé privée accessible à d’autres utilisateurs.
• La connexion cible le mauvais port : ajoutez -p ou corrigez l’entrée du fichier ~/.ssh/config. Une clé valide ne peut pas être testée contre un service inaccessible.
• Une ancienne clé est proposée : utilisez -i ou un alias configuré. Plusieurs clés locales peuvent conduire SSH à essayer des identités dans un ordre non souhaité.

La commande de diagnostic suivante augmente les détails affichés sans changer la configuration. Recherchez les lignes mentionnant Offering public key, puis vérifiez si le serveur accepte ou refuse la clé proposée.

ssh -v -i ~/.ssh/id_ed25519_serveur [email protected]

Sécuriser la clé privée et le serveur après le test

Une fois la connexion par clé testée avec succès, protégez les fichiers locaux et envisagez de désactiver l’authentification par mot de passe sur le serveur. Cette dernière mesure réduit une surface d’attaque courante, mais elle peut vous bloquer si la clé n’a pas été validée dans une seconde session indépendante.

Ne désactivez les mots de passe qu’après avoir ouvert et vérifié une connexion SSH par clé distincte. Gardez la session administrateur actuelle ouverte pendant le test afin de pouvoir corriger rapidement une erreur de configuration.

Étape 7 : appliquer les permissions locales

Les permissions strictes empêchent d’autres comptes locaux de lire la clé privée. Exécutez les commandes suivantes sur votre poste, puis vérifiez que le propriétaire est bien votre utilisateur Linux.

chmod 700 ~/.ssh
chmod 600 ~/.ssh/id_ed25519_serveur
chmod 644 ~/.ssh/id_ed25519_serveur.pub

Étape 8 : désactiver le mot de passe avec prudence

Sur le serveur, modifiez la configuration du démon SSH uniquement après votre test concluant. Dans /etc/ssh/sshd_config, ajoutez ou modifiez la directive suivante, puis rechargez le service selon la documentation de votre distribution.

PasswordAuthentication no

Le nom du service et la commande de rechargement diffèrent selon les distributions et les installations. Consultez la documentation OpenSSH et celle de votre système avant d’appliquer le changement ; le manuel de sshd_config décrit la directive PasswordAuthentication et ses effets.

Comparer Ed25519, RSA 4096 et le mot de passe

Ed25519 et RSA 4096 sont deux choix réels pour créer une paire de clés SSH, alors qu’un mot de passe seul constitue une autre méthode d’authentification. Le choix dépend surtout de la compatibilité du serveur et des outils avec lesquels vous devez travailler, pas d’un effet de mode.

Option	Usage conseillé	Limite principale
Ed25519	Nouveaux déploiements compatibles avec OpenSSH	Peut poser problème sur des systèmes très anciens
RSA 4096	Compatibilité avec des environnements plus anciens	Clés plus volumineuses qu’Ed25519
Mot de passe seul	Accès temporaire ou environnement sans clé configurée	Exposé aux tentatives répétées sur les services accessibles

Ed25519 constitue le choix pratique pour une nouvelle clé SSH lorsque la compatibilité est confirmée. RSA 4096 reste une alternative pertinente pour un serveur ancien ou une contrainte logicielle documentée. Les commandes et les formats pris en charge sont décrits dans la documentation officielle ssh-keygen.

Questions fréquentes sur les clés SSH Linux

Où sont stockées les clés SSH sous Linux ?

Les clés SSH sont généralement stockées dans le dossier ~/.ssh/ du compte utilisateur. Une clé privée peut s’appeler id_ed25519 ou porter un nom personnalisé, tandis que la clé publique associée termine par .pub.

Quelle clé faut-il copier sur le serveur ?

Copiez uniquement la clé publique, par exemple id_ed25519_serveur.pub. La clé privée correspondante doit rester sur votre ordinateur et ne doit jamais être déposée dans authorized_keys.

Peut-on utiliser une même clé SSH sur plusieurs serveurs ?

Une même clé publique peut être ajoutée à plusieurs serveurs si les accès appartiennent au même périmètre de confiance. Créer une clé par usage ou par environnement facilite toutefois la révocation si une clé doit être remplacée.

Pourquoi SSH demande-t-il encore ma phrase secrète ?

La phrase secrète protège votre clé privée, pas le compte distant. Pour éviter de la ressaisir pendant une session, chargez la clé dans ssh-agent avec la commande ssh-add.

Comment supprimer l’accès d’une clé SSH à un serveur ?

Supprimez la ligne correspondant à la clé publique dans le fichier ~/.ssh/authorized_keys du compte distant. La suppression de la clé publique sur le serveur révoque l’accès associé, sans effacer nécessairement la clé privée locale.