Permission denied (publickey).

Précédé de `user@host:`. La liste entre parenthèses indique les méthodes que le serveur autorise encore, par exemple `(publickey,password)` ou `(publickey,gssapi-keyex,gssapi-with-mic)`.

Ce que cela signifie

La connexion SSH et la vérification de l’hôte ont réussi, mais le serveur n’a accepté aucune des clés publiques proposées par le client, et l’authentification par clé publique est la seule méthode qu’il autorise (la liste entre parenthèses). Le client n’apprend jamais pourquoi une clé a été refusée : la raison ne figure que dans le journal du serveur. Sur GitHub, GitLab et Bitbucket, le même message signifie qu’aucune de vos clés n’est enregistrée sur le compte (ou comme clé de déploiement) qui donne accès à ce dépôt.

Pourquoi cela se produit

• La bonne clé n’est pas proposée

  fréquente

  La clé n’est pas dans l’agent, ne se trouve pas à un emplacement par défaut (`~/.ssh/id_ed25519`, `id_ecdsa`, `id_rsa`) et n’est pas indiquée avec `-i` ou `IdentityFile`. Si l’agent contient de nombreuses clés, le serveur peut couper la connexion (MaxAuthTries) avant que la bonne ait été essayée.

• La clé n’est pas dans le fichier authorized_keys de cet utilisateur

  fréquente

  Installée pour un autre utilisateur ou un autre hôte, supprimée lors d’une réinstallation, ou (pour l’hébergement Git) ajoutée à un autre compte que celui qui a accès au dépôt.

• sshd ignore authorized_keys à cause des permissions

  occasionnelle

  Avec `StrictModes yes` (la valeur par défaut), un répertoire personnel, un `~/.ssh` ou un `authorized_keys` accessible en écriture au groupe ou à tous amène sshd à refuser le fichier. Le journal du serveur indique « Authentication refused: bad ownership or modes ».

• L’algorithme de signature de la clé n’est pas accepté

  occasionnelle

  Les clés RSA utilisées avec l’algorithme SHA-1 `ssh-rsa` par d’anciens clients et d’anciennes bibliothèques sont rejetées par les serveurs OpenSSH 8.8 et ultérieurs ; les clés DSA ont complètement disparu dans OpenSSH 10. Le serveur consigne « not in PubkeyAcceptedAlgorithms ».

• Mauvais nom d’utilisateur distant

  occasionnelle

  `ssh server` se connecte avec votre nom d’utilisateur local. Les images cloud attendent `ubuntu`, `ec2-user`, `admin` ; l’hébergement Git attend toujours `git@`.

Comment corriger l’erreur

1. 1.

   Voir quelles clés sont proposées

   `ssh -v` liste chaque clé proposée par le client et indique si le serveur l’a acceptée ; `ssh -G` affiche l’utilisateur et les fichiers d’identité effectifs une fois toute la configuration appliquée.

   ssh -v deploy@server.example.com 2>&1 | grep -E "Offering|Server accepts|Authentications that can continue|send_pubkey_test"
   ssh-add -l                                  # keys the agent offers
   ssh -G deploy@server.example.com | grep -E "^(user|identityfile|identitiesonly) "

2. 2.

   Fixer l’identité pour chaque hôte

   `IdentityFile` combiné à `IdentitiesOnly yes` propose exactement une clé et évite « Too many authentication failures » avec les agents qui contiennent beaucoup de clés.

   # ~/.ssh/config
   Host server.example.com
     User deploy
     IdentityFile ~/.ssh/deploy_ed25519
     IdentitiesOnly yes

3. 3.

   Corriger le côté serveur et lire son journal

   Installez la clé publique pour le bon utilisateur avec des permissions strictes, et cherchez dans le journal de sshd la raison précise du refus.

   # On the server: install the key and fix modes (sshd ignores keys in group/world-writable paths)
   install -d -m 700 ~/.ssh && cat deploy_ed25519.pub >> ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys
   sudo journalctl -u ssh --since "10 min ago" | grep -E "Authentication refused|not in PubkeyAccepted|Failed publickey"

← Parcourir toute la base de données des erreurs de signature