Comment corriger "Permission denied (publickey)" avec SSH

Voir ce que propose votre client

ssh -v user@server

Cherchez ces lignes vers la fin de la sortie :

Le mot entre parenthèses dans l'erreur liste les méthodes de connexion que le serveur autorise encore. (publickey) seul signifie que les mots de passe sont désactivés : une clé valide est donc le seul moyen d'entrer.

L'erreur vient de git push ou git pull ? Voir git@github.com: Permission denied (publickey).

Lire le journal du serveur

Le client n'est jamais informé de la raison pour laquelle une clé a été refusée. Seul le serveur la connaît. Si vous avez encore un moyen d'entrer, comme une autre session ou la console de l'hébergeur, lisez le journal :

sudo journalctl -u ssh -n 50     # Debian, Ubuntu
sudo journalctl -u sshd -n 50    # RHEL, Fedora, Arch
sudo tail -n 50 /var/log/auth.log   # older Debian and Ubuntu
sudo tail -n 50 /var/log/secure     # older RHEL

Si le journal ne donne aucune raison, lancez un second sshd en mode débogage sur un port libre. Il traite une connexion, affiche chaque étape, puis se termine. Le port doit être ouvert dans votre pare-feu.

sudo /usr/sbin/sshd -d -p 2222

ssh -v -p 2222 user@server

Mauvais utilisateur

Vérifiez sous quel nom vous vous connectez réellement, car une ligne User de votre configuration peut le définir :

ssh -G server | grep '^user '

Les images cloud utilisent souvent un compte fixe comme ubuntu, debian ou ec2-user, et refusent root. Une clé installée pour un compte ne fonctionne pas pour un autre, car chaque compte a son propre authorized_keys.

Pour fixer une fois pour toutes l'utilisateur et la clé d'un hôte, ajoutez User et IdentityFile dans son bloc du fichier de configuration ssh.

Mauvaise clé, ou clé absente du serveur

Comparez les empreintes. Sur votre machine :

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

Sur le serveur, ceci liste toutes les clés du fichier :

ssh-keygen -lf ~/.ssh/authorized_keys

Si l'empreinte est absente, installez la clé. Tant que la connexion par mot de passe fonctionne, une commande suffit, avec les bonnes permissions :

ssh-copy-id -i ~/.ssh/id_ed25519.pub user@server

Si le serveur n'accepte que les clés, ajoutez-la depuis la console de l'hébergeur ou une autre session, avec cet utilisateur. Mettez votre ligne .pub complète à la place de l'exemple :

mkdir -p ~/.ssh && chmod 700 ~/.ssh
echo 'ssh-ed25519 AAAA... you@laptop' >> ~/.ssh/authorized_keys
chmod 600 ~/.ssh/authorized_keys

Si la clé est là mais que votre client en propose d'autres d'abord, nommez-la et ignorez les autres :

ssh -o IdentitiesOnly=yes -i ~/.ssh/id_ed25519 user@server

Une erreur fréquente lors d'une installation à la main est une clé répartie sur deux lignes. Chaque clé doit tenir sur une seule ligne : voir le fichier authorized_keys expliqué.

Permissions et propriétaire

Avec la valeur par défaut StrictModes yes, sshd ignore authorized_keys si d'autres utilisateurs peuvent y écrire ou écrire dans les dossiers qui le contiennent. L'écriture pour le groupe sur le dossier personnel suffit à le déclencher. Sur le serveur, avec cet utilisateur :

chmod go-w ~
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys

Si vous avez créé les fichiers avec sudo, corrigez aussi le propriétaire :

sudo chown -R user:user /home/user/.ssh

Pour voir d'un coup tous les niveaux du chemin :

namei -l /home/user/.ssh/authorized_keys

Sur les systèmes où SELinux est en mode enforcing, comme RHEL et Fedora, les fichiers déplacés peuvent aussi porter la mauvaise étiquette. Réinitialisez-la avec restorecon -Rv ~/.ssh.

AuthorizedKeysFile pointe ailleurs

Votre clé peut être dans le bon fichier pour la configuration par défaut, mais pas pour ce serveur. Demandez à sshd ce qui s'applique à cet utilisateur. -C évalue aussi les blocs Match :

sudo sshd -T -C user=user,host=example.com,addr=203.0.113.10 | grep -iE '^(authorizedkeysfile|pubkeyauthentication) '

La valeur par défaut est .ssh/authorized_keys .ssh/authorized_keys2, relative au dossier personnel. Une valeur comme /etc/ssh/authorized_keys/%u signifie que la clé doit être placée là. Vérifiez aussi que pubkeyauthentication indique yes.

Ancien RSA et PubkeyAcceptedAlgorithms

OpenSSH 8.8 a désactivé par défaut la signature ssh-rsa, qui utilise SHA-1. C'est l'ancienne signature qui a été désactivée, pas les clés RSA. Une clé RSA fonctionne toujours quand les deux côtés prennent en charge rsa-sha2-256 ou rsa-sha2-512, ce qu'OpenSSH fait depuis la version 7.2.

Si un client récent rencontre un serveur trop ancien pour cela, ssh -v affiche une ligne comme no mutual signature algorithm, et la clé n'est jamais proposée. Mettre le serveur à jour est la vraie solution. D'ici là, autorisez l'ancienne signature pour cet hôte uniquement dans ~/.ssh/config :

Host oldbox
  PubkeyAcceptedAlgorithms +ssh-rsa
  HostKeyAlgorithms +ssh-rsa

Si un ancien client se connecte à un serveur récent, la même ligne va dans la configuration de sshd, et touche tous les utilisateurs de ce serveur :

PubkeyAcceptedAlgorithms +ssh-rsa

Avant OpenSSH 8.5, l'option s'appelait PubkeyAcceptedKeyTypes. Si vous le pouvez, passez à une clé ed25519 et retirez ces lignes.

Questions

Comment ajouter ma clé SSH sur le serveur ?

Lancez ssh-copy-id -i ~/.ssh/id_ed25519.pub user@server tant que la connexion par mot de passe fonctionne. Si le serveur n'accepte que les clés, ajoutez votre ligne .pub à ~/.ssh/authorized_keys depuis la console de l'hébergeur, puis lancez chmod 600 sur le fichier.

Pourquoi SSH affiche Permission denied (publickey) alors que la clé est sur le serveur ?

En général à cause des permissions : sshd ignore authorized_keys si d'autres peuvent écrire dans le répertoire personnel, dans .ssh ou dans le fichier. Vérifiez aussi que la clé est dans le fichier du compte avec lequel vous vous connectez.

Comment voir quelle clé SSH propose ?

Lancez ssh -v user@server et cherchez les lignes Offering public key. Pour n'utiliser qu'une clé, ajoutez -o IdentitiesOnly=yes et -i avec son chemin.

Les clés RSA fonctionnent-elles encore avec un OpenSSH récent ?

Oui. OpenSSH 8.8 a désactivé l'ancienne signature ssh-rsa en SHA-1, pas les clés RSA, qui fonctionnent avec rsa-sha2-256 ou rsa-sha2-512.

Sources

• ssh(1), manuel OpenBSD
• sshd(8), manuel OpenBSD
• sshd_config(5), manuel OpenBSD
• Notes de version d'OpenSSH 8.8
• Notes de version d'OpenSSH 8.5

Guides associés

• Comment générer une clé SSH ed25519
• Le fichier authorized_keys expliqué
• "git@github.com: Permission denied (publickey)" : comment le corriger
• Erreur SSH « Too many authentication failures » : comment la résoudre
• WARNING: UNPROTECTED PRIVATE KEY FILE : corriger les mauvaises permissions
• Le fichier de configuration SSH, avec des exemples

Autres guides : Clés et connexion

• Convertir une clé .ppk en OpenSSH, et inversement
• Comment désactiver la connexion par mot de passe pour SSH
• Comment utiliser une YubiKey ou une clé FIDO2 avec SSH (ed25519-sk)
• Comment ajouter une clé SSH à GitHub
• Comment retrouver une clé publique SSH à partir de la clé privée
• Clés SSH RSA ou ed25519 : laquelle choisir ?

Tous les guides