Erreur Git: «Échec de la vérification de la clé d'hôte» lors de la connexion au référentiel distant

223

J'essaie de me connecter à un référentiel Git distant qui réside sur mon serveur Web et de le cloner sur ma machine.

J'utilise le format suivant pour ma commande:

git clone ssh://[email protected]/repository.git

Cela a bien fonctionné pour la plupart des membres de mon équipe. Habituellement, après avoir exécuté cette commande, Git demandera le mot de passe de l'utilisateur, puis exécutera le clonage. Cependant, lors de l'exécution sur une de mes machines, j'obtiens l'erreur suivante:

La vérification de la clé d'hôte a échoué.

fatal: impossible de lire à partir du référentiel distant.

Nous n'utilisons pas de clés SSH pour se connecter à ce référentiel, donc je ne sais pas pourquoi Git en recherche une sur cette machine particulière.

bootsz
la source
2
Vous êtes utilisez SSH pour se connecter à ce référentiel, remarquez comment votre URL commence parssh://
Brandon
J'ai un problème similaire . Est-ce que quelqu'un peut m'aider s'il vous plaît? Je suis coincé :(
SepSol

Réponses:

165

Vous vous connectez via le protocole SSH, comme indiqué par le ssh://préfixe sur l'URL de votre clone. En utilisant SSH, chaque hôte possède une clé. Les clients se souviennent de la clé d'hôte associée à une adresse particulière et refusent de se connecter si une clé d'hôte semble changer. Cela empêche l'homme au milieu des attaques.

La clé d'hôte de domain.com a changé. Si cela ne vous semble pas louche , supprimez l'ancienne clé de votre cache local en modifiant ${HOME}/.ssh/known_hostspour supprimer la ligne pour domain.com ou en laissant un utilitaire SSH le faire pour vous avec

ssh-keygen -R domain.com

À partir d'ici, enregistrez la clé mise à jour soit en le faisant vous-même avec

ssh-keyscan -t rsa domain.com >> ~/.ssh/known_hosts

ou, ce qui revient, laissez -le sshfaire pour vous la prochaine fois que vous vous connectez avec git fetch, git pullou git push(ou même une plaine ol » ssh domain.com) en répondant oui lorsque vous êtes invité

L'authenticité de l'hôte 'domain.com (abcd)' ne peut pas être établie.
L'empreinte digitale de la clé RSA est XX: XX: ...: XX.
Voulez-vous vraiment continuer à vous connecter (oui / non)?

La raison de cette invite est que domain.com n'appartient plus à vous known_hostsaprès l'avoir supprimé et probablement pas dans le système /etc/ssh/ssh_known_hosts, il sshn'a donc aucun moyen de savoir si l'hôte à l'autre extrémité de la connexion est vraiment domain.com. (Si la mauvaise clé est /etcentrée, une personne disposant de privilèges administratifs devra mettre à jour le fichier à l'échelle du système.)

Je vous encourage fortement à envisager également d'authentifier les utilisateurs avec des clés. De cette façon, ssh-agentpeut stocker du matériel clé pour plus de commodité (plutôt que tout le monde doit entrer son mot de passe pour chaque connexion au serveur), et les mots de passe ne passent pas sur le réseau.

Greg Bacon
la source
3
Fait amusant, l'exécution sudo ssh-keygen -R domain.compeut renommer votre known_hostsfichier existant known_hosts.oldet créer une copie qui n'est lisible que par root . ( -rw------- root root) Vous pouvez facilement le chownrenvoyer à l'utilisateur approprié, mais vous pourriez également perdre un après-midi à déboguer pourquoi git est cassé. : D
Andrew Rueckert
1
Are you sure you want to continue connecting (yes/no)?. Ne faites pas la même erreur que moi. Vous devez taper yes.
Appuyer
307

Comme je l'ai déjà répondu dans Clonage, git repo provoque une erreur - La vérification de la clé d'hôte a échoué. fatal: l'extrémité distante a raccroché de manière inattendue , ajoutez le GitHub à la liste des hôtes autorisés:

ssh-keyscan -t rsa github.com >> ~/.ssh/known_hosts

Tupy
la source
3
C'est le moyen le plus sûr, à moins d'avoir déjà la clé présente. Cela suppose que vous ne l'exécutez qu'une seule fois, pas à chaque fois que vous vous connectez au serveur.
Zenexer
Le référentiel d'ajustement privé de mon entreprise utilise ecdsa comme clé, donc si la solution ne fonctionne pas, c'est peut-être parce que l'algorithme n'est pas correct
Fendy
8
Cela devrait être la réponse acceptée. Merci d'avoir sauvé ma journée.
Keyur
travaillé pour moi aussi, je me demandais pourquoi je ne pouvais pas cloner mon propre repo
StackAttack
Quelqu'un a signalé ce message (incorrectement). De l'avis .
Wai Ha Lee
55

J'ai eu le même problème, mais en utilisant des clés SSH. D'après la réponse de Tupy, ci-dessus, j'ai compris que le problème était que le fichier known_hosts n'était pas présent ou que github.com n'était pas présent dans la liste des hôtes connus. Voici les étapes que j'ai suivies pour le résoudre -

  1. mkdir -p ~/.ssh
  2. ssh-keyscan -t rsa github.com >> ~/.ssh/known_hosts
  3. ssh-keygen -t rsa -C "user.email"
  4. ouvrez la clé publique avec cette commande $ cat ~/.ssh/id_rsa.pubet copiez-la.
  5. Ajoutez la clé id_rsa.pub à la liste des clés SSH de votre profil GitHub.
Saran
la source
1
@OJFord FYI: J'ai modifié la réponse originale d'une manière qui rend votre commentaire obsolète. TBH et avec tout le respect que je vous dois, ce n'était pas tout à fait correct en premier lieu. La touchcommande échouerait dans le cas où le ~/.sshrépertoire n'existe pas, donc l'étape 1 était toujours requise. De plus, vous n'avez pas besoin touchdu fichier avant d'utiliser la >>redirection. Il sera créé si nécessaire (mais seulement le fichier, pas le chemin complet, donc il mkdir -pest toujours nécessaire). L' -poption le fait fonctionner au cas où le répertoire existe déjà.
Tad Lispy
1
C'est le n ° 2 ssh-keyscanqui manque dans les documents Github sur l'ajout d'une nouvelle clé ssh.
Phil Andrews
1
J'avais des problèmes avec mon Dockerfilemanque d'autorisation. L'ajout de la 2e étape a résolu ce problème! Merci pour l'excellent travail
Spencer Pollock
37

Cela se produit car github n'est pas actuellement dans vos hôtes connus.

Vous devriez être invité à ajouter github à vos hôtes connus. Si cela ne s'est pas produit, vous pouvez exécuter ssh -T [email protected]à nouveau pour recevoir l'invite.

Powderham
la source
2
C'est la bonne réponse si vous n'y êtes jamais invité.
Matthias Hagemann
15

Pour moi, je viens de taper "oui" à l'invite qui demande "Êtes-vous sûr de vouloir continuer à vous connecter (oui / non)?" plutôt que d'appuyer simplement sur Entrée.

Apprenti Code
la source
Cette réponse m'a amené à réaliser que je devais cloner manuellement mon référentiel sur mon serveur de build afin de taper «oui» et que mon serveur bitbucket soit ajouté à mes known_hosts
Sashah
1
@Sashah Si tout ce dont vous avez besoin est le serveur bitbucket dans known_hosts, vous pouvez modifier le fichier manuellement. Pas besoin de cloner le dépôt si c'est la seule raison de le faire.
Code-Apprentice
7

J'ai eu le même problème sur un système nouvellement installé, mais c'était un problème udev. Il n'y avait pas de /dev/ttynœud, j'ai donc dû faire:

mknod -m 666 /dev/tty c 5 0
Geoffroy
la source
1
Cela a fonctionné pour moi car / dev / tty a été créé sous forme de fichier, très étrange! (vous devez donc le supprimer puis le recréer avec mknod)
Doomsday
@Geoffroy, j'ai supprimé / dev / tty et maintenant quand fais sudo, je fais face à cette erreur: sudo: désolé, vous devez avoir un tty pour exécuter sudo
Milad
@ xe4me Je n'ai jamais dit que vous deviez le supprimer, selon le système dont il a réellement besoin. Le redémarrage devrait le réparer.
Geoffroy
@Geoffroy, en fait le premier commentateur, a dit que je devais supprimer et recréer: d Non, le redémarrage n'a pas fonctionné, je devais dire la racine, il l'a corrigé: d
Milad
6

Si vous êtes dans un intranet de bureau (sinon dangereux) qui est toujours protégé par des pare-feu, il suffit d'avoir les lignes suivantes dans votre ~ / .ssh / config

Hôte *
StrictHostKeyChecking no
UserKnownHostsFile = / dev / null

sunil
la source
2
C'est toujours dangereux, avec nos pare-feu sans entreprise. Comment savez-vous que vous parlez au vrai github sans vérifier la clé du serveur?
Mnebuerquo
1
Dans les environnements d'entreprise, les dépôts git locaux sont principalement utilisés, jamais en open source. Dans le pire des cas, la configuration .ssh en haut du fichier peut avoir des lignes de configuration liées à l'hôte explicite github pour que ssh choisisse des correspondances plus spécifiques.
sunil
5

Ce qui a fonctionné pour moi a été d'ajouter d'abord ma clé SSH du nouvel ordinateur, j'ai suivi ces instructions de GitLab - ajouter une clé SSH . Notez que depuis que je suis sur Win10, j'ai dû faire toutes ces commandes dans Git Bash sur Windows (cela ne fonctionnait pas dans le shell cmd DOS normal).

Là encore, dans Git Bash, j'ai dû faire un git clonerepo avec lequel j'avais des problèmes, et dans mon cas, j'ai dû le cloner sous un nom différent car je l'avais déjà localement et je ne voulais pas perdre mes commits. Par exemple

git clone ssh://git@gitServerUrl/myRepo.git myRepo2

Ensuite, je suis invité à l'ajouter à la liste des hôtes connus, la question pourrait être celle-ci:

Voulez-vous vraiment continuer à vous connecter (oui / non)?

J'ai tapé "oui" et cela a finalement fonctionné, vous devriez généralement obtenir un message similaire à celui-ci:

Avertissement: Ajout permanent de «[votre lien de mise en pension]» (ECDSA) à la liste des hôtes connus.

Remarque : si vous êtes sous Windows, assurez-vous que vous utilisez Git Bash pour toutes les commandes, cela ne fonctionnait pas dans le shell cmd normal ou le powershell, je devais vraiment le faire dans Git Bash.

Enfin, j'ai supprimé le deuxième dépôt de clone ( myRepo2dans l'exemple) et je suis retourné à mon premier dépôt et j'ai finalement pu faire toutes les choses Git comme d'habitude dans mon éditeur préféré VSCode.

ghiscodage
la source
En effet, mon invite Cygwin ressemble presque exactement à mon invite git bash, mais elle ne fonctionne que dans l'invite git bash!
Josiah Yoder du
3

Si vous utilisez git pour Windows.

  • Ouvrez l'interface graphique de git.
  • Ouvrez le référentiel git local dans git GUI.
  • Ajoutez la télécommande ou appuyez sur si la télécommande existe déjà.
  • Répondez «oui» à la question de savoir si vous souhaitez continuer.

Le client GUI ajoute la clé pour vous ~/.ssh/known_hosts. Ceci est plus facile à retenir si vous ne le faites pas souvent et évite également d'avoir à utiliser la ligne de commande git (les lignes de commande Windows standard n'ont pas d' ssh-keyscanexécutable).

Julian Knight
la source
2

Lorsque le serveur distant souhaite se connecter au référentiel privé, il s'authentifie via ssh. Créez la paire de clés privée-publique avec ssh-keygen ou si vous disposez déjà de la clé publique-privée. copiez et collez la clé publique dans les paramètres du dépôt privé.

YourPrivateRepo -> Paramètres -> Clés de déploiement -> Ajouter une clé de déploiement -> Collez la clé publique.

Maintenant, le serveur distant pourrait se connecter au dépôt privé.

REMARQUE: les clés de déploiement ont uniquement accès à la lecture du référentiel. Besoin d'autoriser explicitement l'accès en écriture.

Sablonneux
la source
1

Cela signifie que votre clé d'hôte distant a été modifiée (peut être un changement de mot de passe d'hôte),

Votre terminal a suggéré d'exécuter cette commande en tant qu'utilisateur root

$ ssh-keygen -f "/root/.ssh/known_hosts" -R [www.website.net]

Vous devez supprimer ce nom d'hôte de la liste des hôtes sur votre PC / serveur. Copiez la commande suggérée et exécutez-la en tant qu'utilisateur root.

$ sudo su                                                        // Login as a root user

$ ssh-keygen -f "/root/.ssh/known_hosts" -R [www.website.net]    // Terminal suggested command execute here
Host [www.website.net]:4231 found: line 16 type ECDSA
/root/.ssh/known_hosts updated.
Original contents retained as /root/.ssh/known_hosts.old

$ exit                                                           // Exist from root user

Essayez encore, j'espère que cela fonctionne.

Jay Patel
la source
Remarque: selon votre shell, vous devrez peut-être échapper les crochets \ [et \] ou utiliser des guillemets.
Phlarx
1

Lorsqu'on lui a demandé:

Are you sure you want to continue connecting (yes/no)?

Tapez oui comme réponse

C'est ainsi que j'ai résolu mon problème. Mais si vous essayez de simplement appuyer sur le bouton Entrée, cela ne fonctionnera pas!

shutsuke
la source
0

Vous pouvez utiliser votre "git url" au format URL 'https "dans le Jenkinsfile ou où vous voulez.

git url: 'https://github.com/jglick/simple-maven-project-with-tests.git'

Nitine
la source
0

Je faisais face à la même erreur à l'intérieur de DockerFile pendant la construction alors que l'image était publique. J'ai fait peu de modifications dans Dockerfile.

 RUN git clone  https://github.com/kacole2/express-node-mongo-skeleton.git /www/nodejs

Ce serait parce que l'utilisation de la syntaxe [email protected]: ... finit par utiliser SSH pour cloner, et à l'intérieur du conteneur, votre clé privée n'est pas disponible. Vous voudrez utiliser le clone git RUN> https://github.com/edenhill/librdkafka.git à la place.

Adiii
la source
-1

J'ai eu le même problème, malheureusement j'ai utilisé l'IHM GitExtensions et j'ai oublié que j'avais écrit une phrase secrète. Avec HMI .... oubliez ça! N'entrez pas de phrase secrète lorsque vous générez votre clé!

Jerome Vacher
la source
-4

J'ai reçu ce message quand j'ai essayé git cloneun repo qui n'était pas le mien. Le correctif consistait à bifurquer puis à cloner.

fyodrs
la source