Pour moi, les solutions proposées par d'autres donnaient encore l'erreur suivante pendant go get
git@gl.nimi24.com: Autorisation refusée (publickey). fatal: impossible de lire à partir du référentiel distant. Veuillez vous assurer que vous disposez des droits d'accès appropriés et que le référentiel existe.
Ce qu'exigeait cette solution
Comme indiqué par d'autres:
git config --global url."git@github.com:".insteadOf "https://github.com/"
Suppression de la phrase de passe de ma ./ssh/id_rsa
clé qui a été utilisée pour authentifier la connexion au référentiel. Cela peut être fait en entrant un mot de passe vide lorsque vous y êtes invité en réponse à:
ssh-keygen -p
Pourquoi cela fonctionne
Ce n'est pas une jolie solution de contournement car il est toujours préférable d'avoir une phrase de passe sur votre clé privée, mais cela causait des problèmes quelque part dans OpenSSH.
go get
utilise en interne git, qui utilise openssh pour ouvrir la connexion. OpenSSH prend les certificats nécessaires pour l'authentification de .ssh/id_rsa
. Lors de l'exécution de commandes git à partir de la ligne de commande, un agent peut se charger d'ouvrir le fichier id_rsa pour vous afin que vous n'ayez pas à spécifier la phrase de passe à chaque fois, mais lorsqu'il est exécuté dans le ventre de go get, cela n'a pas fonctionné dans mon Cas. OpenSSH veut alors vous demander un mot de passe mais comme ce n'est pas possible en raison de la façon dont il a été appelé, il imprime dans son journal de débogage:
read_passphrase: impossible d'ouvrir / dev / tty: aucun périphérique ou adresse de ce type
Et échoue tout simplement. Si vous supprimez la phrase de passe du fichier de clé, OpenSSH accédera à votre clé sans cette invite et cela fonctionnera
Cela peut être dû au fait que Go récupère des modules simultanément et ouvre plusieurs connexions SSH à Github en même temps (comme décrit dans cet article ). Ceci est quelque peu soutenu par le fait que le journal de débogage d'OpenSSH a montré que la connexion initiale au référentiel a réussi, mais l'a réessayé plus tard pour une raison quelconque et cette fois a choisi de demander une phrase de passe.
Cependant, la solution d'utiliser le multiplexage de connexion SSH telle que proposée dans l'article mentionné ne fonctionnait pas pour moi. Pour mémoire, l'auteur a suggéré d'ajouter la configuration de collowing au fichier de configuration ssh pour l'hôte concerné:
ControlMaster auto
ControlPersist 3600
ControlPath ~/.ssh/%r@%h:%p
Mais comme indiqué, pour moi cela n'a pas fonctionné, peut-être que je l'ai mal fait
GOPRIVATE
également. par exempleexport GOPRIVATE="github.com/steelx/that-private-repo"