« Permission denied (publickey) » avec SSH : l'interpréter grâce à ssh -v

Ce que c'est

Le client OpenSSH affiche user@host: Permission denied (publickey). lorsque toutes les méthodes d'authentification que le serveur était disposé à essayer ont été rejetées. Les noms de méthodes entre parenthèses indiquent simplement ce que le serveur a proposé de tenter, et non ce qui a effectivement échoué pour une raison précise ; le message ne dit rien de la clé essayée ni de la raison de l'échec.

Pourquoi c'est important

Le message est volontairement générique (en dire plus aiderait un attaquant à énumérer des noms d'utilisateur ou des clés valides). Tenter de corriger le problème au hasard fait donc perdre du temps : la cause réelle fait partie d'un petit nombre de possibilités, et ssh -v la désigne directement, sans passer par l'essai-erreur.

Comment l'appliquer

• Commencer par le diagnostic en mode verbeux : ssh -v (ou -vvv pour plus de détails) montre précisément quelles clés le client a proposées, dans quel ordre, et comment le serveur a réagi à chacune ("Offering public key", "Server accepts key", "Authentications that can continue"). Lire cette trace avant de modifier la moindre configuration.
• Causes courantes, de la correction la moins invasive à la plus invasive :
  1. Mauvais nom d'utilisateur distant : connexion avec le nom de son compte local alors que le serveur attend un autre nom (par ex. ec2-user, git). Passer -l user ou corriger l'entrée User dans le bloc Host concerné.
  2. La bonne clé existe sur le disque, mais elle ne figure pas parmi celles proposées. Par défaut, ssh essaie les clés d'un agent et celles des noms de fichiers par défaut ; il faut lui indiquer explicitement la bonne avec -i path/to/key, associé à IdentitiesOnly yes (documenté dans ssh_config(5)). Ainsi, ssh n'envoie pas en plus au serveur des clés sans rapport, au risque d'atteindre la limite de tentatives du serveur avant la bonne clé.
  3. Permissions côté serveur : sshd_config(5) documente StrictModes, qui conduit sshd à refuser l'authentification si le répertoire personnel, ~/.ssh ou authorized_keys sont modifiables par un autre utilisateur que leur propriétaire. Vérifier et corriger le propriétaire et les droits (généralement 700 pour ~/.ssh, 600 pour authorized_keys) depuis le serveur, en s'appuyant sur son propre journal d'authentification pour confirmer que c'est bien la cause.
  4. Depuis OpenSSH 8.8, le client et le serveur n'utilisent plus par défaut les signatures RSA avec SHA-1 (l'algorithme ssh-rsa), d'après les notes de version d'OpenSSH 8.8. Les clés RSA elles-mêmes continuent de fonctionner via rsa-sha2-256/512, pris en charge depuis OpenSSH 7.2 ; les échecs apparaissent lorsqu'une extrémité est en 8.8 ou plus récent et que l'autre ne parle que ssh-rsa (serveurs très anciens, appliances, anciennes bibliothèques SSH). Il est préférable de mettre à jour cette extrémité ou de passer à une clé ed25519 ; ce n'est qu'en solution provisoire, et au prix d'un affaiblissement de la sécurité, qu'on réactive l'algorithme pour cet unique hôte avec PubkeyAcceptedAlgorithms +ssh-rsa (nom utilisé depuis OpenSSH 8.5) dans un bloc Host, et non de façon globale.
• Ce qui n'est pas une solution : réessayer à répétition, ou copier une clé privée de manière non sécurisée d'une machine à l'autre au lieu de provisionner une clé adaptée ou d'utiliser le transfert d'agent.

Pièges

• Chercher une correction côté client alors que la cause réelle tient aux permissions d'authorized_keys côté serveur, que seuls les journaux du serveur révèlent.
• Supposer qu'une clé « fonctionne toujours » parce qu'elle fonctionnait hier, alors qu'une mise à jour d'OpenSSH d'un côté ou de l'autre a changé du jour au lendemain les algorithmes acceptés.