SSH et GitHub : corriger Permission denied (publickey)

GitHub n’a accepté aucune clé proposée par SSH. Les exemples concernent GitHub.com avec OpenSSH ; pour GitHub Enterprise, adaptez le domaine.

Vérifier le dépôt et le client

Dans le dépôt concerné :

git remote -v
git config --show-origin --get core.sshCommand
ssh -V
ssh -vT git@github.com

L’absence de sortie pour core.sshCommand est normale si aucun client n’est configuré à ce niveau. Vérifiez aussi une éventuelle variable GIT_SSH_COMMAND ou la configuration SSH de votre outil Git.

L’URL SSH ressemble à git@github.com:PROPRIETAIRE/DEPOT.git. L’utilisateur de connexion est git, pas votre pseudonyme GitHub. Si l’URL commence par https://, Git utilise HTTPS : ce diagnostic SSH ne s’applique pas à cette URL.

Au premier contact, comparez l’empreinte du serveur aux empreintes officielles GitHub avant d’accepter. Une alerte de clé d’hôte modifiée demande une vérification séparée ; ne la masquez pas en désactivant ce contrôle.

Comprendre le diagnostic

Dans ssh -vT, cherchez Offering public key, puis l’acceptation ou le refus de la clé. Les traces peuvent exposer des chemins, des comptes et des adresses : relisez-les avant de les partager.

ssh-add -l

Cette commande liste les empreintes chargées dans l’agent. The agent has no identities signifie que l’agent est joignable mais vide ; Could not open a connection to your authentication agent indique qu’il n’est pas accessible depuis ce terminal.

macOS et Linux

Dans Bash ou Zsh, si aucun agent n’est accessible :

eval "$(ssh-agent -s)"

Ce nouvel agent concerne la session et ne remplace pas forcément celui du bureau. Chargez ensuite votre clé existante :

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

Adaptez le chemin au nom de votre clé. Si OpenSSH refuse ses permissions :

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

Ces commandes supposent que les fichiers vous appartiennent. N’exécutez pas Git avec sudo pour résoudre l’authentification : cela peut utiliser les clés d’un autre utilisateur.

Windows

Dans PowerShell, vérifiez le client et l’agent OpenSSH Windows :

Get-Command ssh
Get-Service ssh-agent

Si vous choisissez l’agent Windows et que son service est désactivé, activez-le dans PowerShell administrateur :

Set-Service -Name ssh-agent -StartupType Manual
Start-Service ssh-agent

Puis, dans votre terminal utilisateur habituel :

ssh-add "$env:USERPROFILE\.ssh\id_ed25519"
ssh-keygen -lf "$env:USERPROFILE\.ssh\id_ed25519.pub"

Git for Windows, OpenSSH Windows et WSL peuvent utiliser des clients, répertoires et agents différents. Vérifiez que Git utilise celui que vous venez de configurer. Dans Git Bash ou WSL, suivez les commandes du shell Unix correspondant. N’appliquez pas chmod à l’aveugle à une clé gérée par les permissions Windows.

Enregistrer la bonne clé dans GitHub

Ouvrez Settings → SSH and GPG keys sur le compte attendu. Ajoutez le contenu du fichier public, celui qui se termine par .pub, comme clé d’authentification. Comparez son empreinte avec celle affichée par ssh-keygen -lf.

Si vous n’avez aucune clé, créez-en une avec ssh-keygen -t ed25519 -C "votre-email@example.com" et une phrase secrète. Choisissez un chemin libre : ne remplacez pas une clé existante. Le fichier sans .pub est privé et ne doit jamais être transmis.

Pour tester une clé précise sans proposer toutes celles de l’agent :

ssh -T -o IdentitiesOnly=yes -i ~/.ssh/id_ed25519 git@github.com

Avec plusieurs comptes GitHub, utilisez des alias distincts dans le fichier utilisateur ~/.ssh/config :

Host github-travail
  HostName github.com
  User git
  IdentityFile ~/.ssh/id_ed25519_travail
  IdentitiesOnly yes

Cet exemple suppose que la clé id_ed25519_travail existe et est enregistrée sur le compte professionnel. L’URL du dépôt doit utiliser l’alias : git@github-travail:PROPRIETAIRE/DEPOT.git. Pour corriger une URL existante, utilisez git remote set-url origin URL_DU_DEPOT avec l’URL exacte.

Vérifier l’accès final

ssh -T git@github.com
git ls-remote origin

Avec l’alias précédent, testez plutôt ssh -T git@github-travail. GitHub confirme l’authentification avec le nom du compte ; il ne fournit pas de shell et ce test peut sortir avec le code 1 même en cas de succès.

Si SSH fonctionne mais que git ls-remote origin échoue, vérifiez le compte annoncé, l’URL, les droits sur le dépôt et, pour une organisation utilisant SAML SSO, l’autorisation de la clé. Un dépôt vide peut ne produire aucune référence : l’absence d’erreur compte aussi.