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

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://username@domain.com/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.

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.

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

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.

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 git@github.comà nouveau pour recevoir l'invite.

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.

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

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

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.

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).

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.

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.

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!

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'

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 git@github.com: ... 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.

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é!

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.