Cette erreur peut se produire lorsque vous accédez à l'URL SSH (lecture/écriture) au lieu de l'URL Git en lecture seule mais que vous n'avez pas d'accès en écriture à ce repo.
Parfois, vous souhaitez simplement cloner votre propre dépôt, par exemple pour le déployer sur un serveur. Dans ce cas, vous n'avez besoin que d'un accès en lecture seule. Mais comme c'est votre propre repo, GitHub peut afficher l'URL SSH si vous le souhaitez. Dans cette situation, si la clé publique de votre hôte distant ne figure pas dans vos clés SSH GitHub, votre accès sera refusé, ce qui devrait se produire .
Un cas équivalent est celui où vous essayez de cloner le dépôt de quelqu'un d'autre auquel vous n'avez pas accès en écriture avec l'URL SSH.
En un mot, si votre intention est de cloner uniquement un repo, utilisez l'URL HTTPS ( https://github.com/{user_name}/{project_name}.git
) au lieu de l'URL SSH ( git@github.com:{user_name}/{project_name}.git
), ce qui évite la validation (inutile) de la clé publique.
Mise à jour : GitHub affiche désormais HTTPS comme protocole par défaut, ce qui peut probablement réduire les abus possibles des URL SSH.
14 votes
Avez-vous essayé de télécharger la clé publique que vous avez générée via ssh-keygen ?
0 votes
Mon problème est que j'ai essayé de cloner à partir de
sudo
- c'est un autre utilisateur avec une autre clé publique.0 votes
Même erreur. J'ai précédemment créé une clé publique par l'intermédiaire de github, puis généré une autre paire de clés avec l'option
ssh-keygen
utilitaire. La suppression de l'ancienne clé publique dans les paramètres personnels sur github et l'ajout de ma clé id_rsa.pub générée par ssh aux clés SSH et GPG ont réglé les problèmes d'autorisation de clonage.