Corriger l’erreur SSH de clé publique sous Linux : guide complet

L’erreur SSH Permission denied (publickey) se corrige en vérifiant quatre points : le bon utilisateur distant, la clé privée réellement proposée, les droits du dossier .ssh et la présence de la clé publique dans authorized_keys. Le message indique que le serveur a refusé l’authentification par clé publique, pas qu’il est forcément inaccessible.

Ce tutoriel explique comment corriger une erreur SSH de clé publique sous Linux sans affaiblir la sécurité du poste ou du serveur. La méthode part du test de connexion, contrôle l’agent SSH, les permissions SSH Linux, la configuration du client et les journaux du serveur lorsque vous disposez d’un accès d’administration.

Que signifie l’erreur SSH Permission denied publickey ?

L’erreur SSH Permission denied (publickey) signifie que le serveur SSH a reçu une tentative de connexion, mais n’a pas validé la clé publique associée à la clé privée présentée par le client. L’authentification SSH par clé publique est un mécanisme fondé sur une paire : une clé privée locale et une clé publique autorisée à distance. La résolution consiste donc à vérifier la correspondance entre ces deux éléments.

Un problème de clé SSH sous Linux peut provenir d’un nom d’utilisateur incorrect, d’une clé privée SSH non reconnue, d’un fichier authorized_keys absent ou mal placé, de permissions trop ouvertes, ou encore d’une configuration qui sélectionne une autre clé. Un message lié à l’identité ou à l’empreinte d’un hôte est différent : il intervient avant l’authentification et demande une vérification de l’identité du serveur.

Le message « Permission denied (publickey) » est un refus d’authentification : commencez par observer la clé réellement proposée, plutôt que de modifier la configuration au hasard.

Comment corriger une connexion SSH refusée : les étapes à suivre

Pour corriger une connexion SSH refusée, testez d’abord la commande exacte, identifiez l’utilisateur distant, chargez la bonne clé privée dans ssh-agent, puis vérifiez que sa clé publique est autorisée sur le serveur. Cette séquence évite de changer des permissions ou des paramètres serveur avant d’avoir isolé la cause.

Étape 1 : vérifier l’utilisateur, l’hôte et le port

Commencez par reprendre la commande de connexion et contrôlez chaque élément. Une connexion vers un serveur Linux suit généralement cette forme :

ssh utilisateur@nom-du-serveur

Le nom avant @ est le compte Linux distant, pas votre nom local. Si le serveur utilise un port non standard, ajoutez l’option -p avec le port qui vous a été communiqué. Une clé correcte ne permet pas de se connecter à un compte qui ne possède pas cette clé dans son fichier authorized_keys.

GitHub constitue un cas particulier fréquent : la connexion SSH doit utiliser l’utilisateur git, même si votre identifiant GitHub est différent. Le test recommandé par la documentation GitHub sur les erreurs SSH est :

ssh -T [email protected]

Étape 2 : rechercher la clé privée disponible sur le poste Linux

Listez le contenu du dossier SSH local avant de générer une nouvelle paire. Les noms courants sont id_ed25519, id_rsa ou un nom personnalisé choisi à la création.

ls -la ~/.ssh

Une clé privée est le fichier sans suffixe .pub. Le fichier portant le suffixe .pub est sa clé publique. Ne copiez jamais la clé privée sur un serveur, dans un ticket d’assistance ou dans un dépôt Git.

Étape 3 : démarrer ssh-agent et charger la bonne clé

L’agent SSH est un processus local qui conserve les clés privées utilisables durant votre session. Démarrez-le, puis ajoutez explicitement la clé à utiliser :

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

Adaptez le nom du fichier à votre installation. Vérifiez ensuite les clés actuellement chargées et leurs empreintes :

ssh-add -l -E sha256

La présence de l’empreinte de votre clé confirme que l’agent SSH peut la proposer. Si la commande indique qu’aucune identité n’est chargée, la connexion ne peut pas utiliser cette clé via l’agent.

Étape 4 : forcer temporairement la sélection d’une clé SSH

Lorsque plusieurs clés sont présentes, demandez au client SSH d’utiliser un fichier précis. Cette commande ne modifie aucune configuration permanente :

ssh -i ~/.ssh/id_ed25519 utilisateur@nom-du-serveur

Si cette commande fonctionne alors que la commande simple échoue, le problème se situe probablement dans la sélection de clé du client SSH ou dans l’agent. Le test avec -i est utile parce qu’il sépare la question de la clé correcte de celle de la configuration automatique.

Étape 5 : vérifier la clé publique sur le serveur distant

Le serveur Linux doit contenir la clé publique correspondante dans le fichier ~/.ssh/authorized_keys du compte ciblé. L’accès à ce fichier exige une autre voie d’administration fonctionnelle : console du fournisseur, accès physique, session déjà ouverte ou intervention d’un administrateur habilité.

Comparez la clé publique locale avec une ligne du fichier distant, sans exposer la clé privée. La commande suivante affiche la clé publique locale :

cat ~/.ssh/id_ed25519.pub

Ajoutez cette ligne entière, sur une seule ligne, dans authorized_keys du bon compte distant. Une clé ajoutée au compte admin ne donnera pas accès au compte deploy, même sur le même serveur.

Quels droits appliquer au dossier .ssh et aux fichiers de clé ?

Les permissions SSH Linux protègent les fichiers qui participent à l’authentification. OpenSSH peut ignorer une clé privée ou un fichier distant lorsqu’il considère que les droits ou le propriétaire rendent le fichier modifiable par des utilisateurs non autorisés. Les droits recommandés côté client sont simples : le dossier ~/.ssh en 700, la clé privée en 600 et la clé publique en 644.

Élément à contrôler	Droit recommandé	Commande de vérification	Risque si le réglage est incorrect
Dossier ~/.ssh	700	ls -ld ~/.ssh	OpenSSH peut refuser d’utiliser les fichiers associés.
Clé privée	600	ls -l ~/.ssh/id_ed25519	La clé privée peut être rejetée si elle est trop exposée.
Clé publique	644	ls -l ~/.ssh/id_ed25519.pub	Le fichier devient moins lisible ou incohérent avec l’usage attendu.

Corrigez uniquement les éléments appartenant à votre compte local. Les commandes suivantes visent l’exemple id_ed25519 :

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

Le propriétaire compte autant que le mode. Sur le serveur, le dossier personnel, le dossier .ssh et le fichier authorized_keys doivent appartenir au compte auquel vous tentez de vous connecter. Consultez la documentation de votre distribution ou la documentation OpenSSH sur StrictModes avant de modifier les droits d’un compte de service.

Ne rendez pas un dossier SSH accessible à tous pour « faire disparaître » l’erreur : des droits plus larges peuvent précisément provoquer le refus et réduisent la protection des clés.

Comment utiliser le diagnostic SSH détaillé ?

Le diagnostic SSH détaillé s’obtient avec l’option -v. La commande montre les clés essayées, les fichiers de configuration lus et la réponse du serveur. Utilisez-la sur une connexion de test, puis conservez seulement les lignes utiles si vous devez demander de l’aide : les journaux peuvent révéler des noms d’hôtes, des comptes ou des chemins locaux.

ssh -v utilisateur@nom-du-serveur

Pour GitHub, le test détaillé documenté est :

ssh -vT [email protected]

Recherchez notamment une ligne indiquant qu’une identité est proposée, puis une réponse de refus. Une ligne du type Offering public key montre que le client soumet une clé ; elle ne prouve pas que le serveur contient la clé publique correspondante. Une absence de clé proposée oriente plutôt vers ssh-agent, le chemin de clé ou la configuration du client.

• La clé n’apparaît jamais dans les lignes de diagnostic : chargez-la avec ssh-add ou indiquez-la avec -i.
• La clé est proposée puis refusée : contrôlez l’utilisateur distant, la clé présente dans authorized_keys et les droits côté serveur.
• Un autre fichier de clé est proposé : examinez ~/.ssh/config et les clés déjà chargées dans l’agent.

Les utilisateurs qui découvrent une distribution ou un terminal Linux peuvent aussi retrouver les repères de base dans ce guide pour prendre en main Manjaro Linux. Les commandes SSH restent comparables sur la plupart des distributions utilisant OpenSSH.

Configurer le client SSH pour sélectionner une clé précise

Le fichier ~/.ssh/config est un fichier de configuration du client SSH qui associe un alias d’hôte, un utilisateur et une clé privée. Il devient utile quand plusieurs serveurs ou plusieurs identités sont utilisés depuis le même poste. Une entrée ciblée évite que SSH essaie une longue liste de clés sans rapport avec le serveur demandé.

Host mon-serveur
    HostName nom-du-serveur
    User utilisateur
    IdentityFile ~/.ssh/id_ed25519
    IdentitiesOnly yes

Avec cet exemple, la commande ssh mon-serveur utilise le compte et la clé définis dans le bloc. Vérifiez soigneusement le chemin placé après IdentityFile. Le paramètre IdentitiesOnly yes est pertinent lorsque vous voulez empêcher le client de proposer d’autres clés chargées dans l’agent.

Évitez d’exécuter habituellement Git ou SSH avec sudo. Une commande lancée avec élévation de privilèges peut utiliser un autre dossier personnel et un autre environnement SSH, donc d’autres clés que celles de votre session utilisateur.

Quelle méthode choisir pour sélectionner une clé SSH ?

Trois méthodes réelles permettent de sélectionner une clé SSH sous Linux : l’option ponctuelle -i, l’agent ssh-agent et le fichier ~/.ssh/config. La meilleure option dépend de la fréquence de connexion et du nombre de serveurs concernés. Une configuration explicite réduit les ambiguïtés ; un test ponctuel réduit les modifications durables.

Méthode	Usage adapté	Avantage	Limite
ssh -i chemin/clé	Test ou connexion occasionnelle	Force une clé sans modifier de fichier.	La commande devient plus longue à répéter.
ssh-agent et ssh-add	Session de travail active	Évite de préciser la clé à chaque commande.	La clé doit être chargée dans l’agent concerné.
~/.ssh/config	Plusieurs serveurs ou identités	Centralise l’hôte, l’utilisateur et la clé.	Une erreur de chemin affecte les connexions associées.

Pour un dépôt GitHub, utilisez l’URL SSH fournie par le dépôt et l’utilisateur git. Pour un serveur Linux personnel ou professionnel, utilisez le compte réellement créé sur ce serveur. Une confusion entre ces deux contextes est une cause classique d’erreur SSH Permission denied publickey.

Erreurs fréquentes lors d’une authentification SSH par clé publique

La plupart des échecs viennent d’un détail vérifiable, pas d’une défaillance générale de SSH. Les erreurs suivantes méritent un contrôle précis avant toute modification de sshd_config ou redémarrage du service distant.

• Utiliser le mauvais compte distant : la clé publique est stockée par utilisateur. Vérifiez le nom placé avant @.
• Copier une clé publique tronquée : une ligne incomplète ou coupée dans authorized_keys ne correspond plus à la clé privée locale.
• Modifier les permissions de façon excessive : évitez les droits ouverts pour tous sur .ssh, les clés et les fichiers d’autorisation.
• Confondre clé privée et clé publique : le fichier sans .pub reste privé ; le fichier .pub est celui à autoriser sur le serveur.
• Publier un journal de diagnostic brut : retirez les adresses réelles, noms de compte, chemins sensibles et toute donnée confidentielle avant partage.

Si la clé privée est perdue et qu’aucun autre accès n’est disponible, la solution n’est pas de contourner SSH : créez une nouvelle paire, puis faites ajouter sa clé publique par un administrateur ou via la console d’administration du serveur. La commande suivante crée une nouvelle clé RSA de 4 096 bits si ce format est requis par votre environnement :

ssh-keygen -t rsa -b 4096 -C "[email protected]"

Le choix du format de clé peut dépendre de la politique technique du service distant. Vérifiez les exigences du serveur ou de la plateforme avant de remplacer une clé existante.

Sources utiles à consulter

La documentation officielle reste le meilleur repère lorsqu’une configuration particulière, une version d’OpenSSH ou un fournisseur d’hébergement intervient. Les étapes ci-dessous permettent de prolonger le diagnostic sans appliquer de réglage non vérifié.

• Documentation GitHub : erreur Permission denied publickey → test GitHub, utilisateur git et contrôle de l’agent SSH.
• Manuel OpenSSH du client ssh → options -i, -v, fichiers de configuration et comportement du client.
• Manuel OpenSSH de sshd_config → paramètres serveur et vérification stricte des modes de fichiers.

Une connexion refusée peut aussi concerner une messagerie ou un outil web lorsque les identifiants, le compte et la méthode d’accès ne correspondent pas. Les mêmes réflexes de vérification sont détaillés dans ce guide pour résoudre un problème de connexion, même si SSH utilise un mécanisme d’authentification distinct.

Questions fréquentes sur les erreurs de clé SSH

Pourquoi SSH refuse-t-il ma clé publique ?

SSH refuse une clé publique lorsque le serveur ne reconnaît pas la clé proposée, quand elle est associée à un autre compte distant ou lorsque les droits et propriétaires des fichiers empêchent son utilisation. Le mode verbeux ssh -v aide à distinguer une clé non proposée d’une clé proposée puis rejetée.

Où placer la clé publique sur un serveur Linux ?

La clé publique doit être ajoutée dans le fichier ~/.ssh/authorized_keys du compte Linux auquel vous voulez vous connecter. Le dossier personnel et le fichier doivent appartenir à ce compte, pas nécessairement au compte administrateur du serveur.

Comment savoir quelle clé SSH est utilisée ?

Exécutez ssh -v utilisateur@nom-du-serveur et cherchez les lignes indiquant qu’une clé est proposée. Vous pouvez aussi forcer une clé avec ssh -i ~/.ssh/nom-de-la-clé utilisateur@nom-du-serveur afin de tester une identité précise.

Faut-il modifier sshd_config pour corriger Permission denied publickey ?

La modification de sshd_config n’est pas la première étape. Contrôlez avant tout le compte, la paire de clés, authorized_keys, les permissions et le diagnostic client ; une modification serveur non maîtrisée peut bloquer un accès existant ou réduire la sécurité.

Peut-on corriger une connexion SSH refusée sans accès au serveur ?

Vous pouvez vérifier le client Linux, l’agent SSH, la clé locale et la commande utilisée sans accès au serveur. En revanche, l’ajout ou la correction de la clé dans authorized_keys exige une voie d’administration distante légitime, comme une console fournisseur ou l’intervention du responsable du serveur.