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. Après avoir exécuté cette commande, Git demande généralement le mot de passe de l'utilisateur, puis exécute le clonage. Toutefois, lors de l'exécution sur l'une de mes machines, l'erreur suivante apparaît:
La vérification de la clé de l'hôte a échoué.
fatal: Impossible de lire à distance dépôt.
Nous n'utilisons pas de clés SSH pour se connecter à ce référentiel, je ne comprends donc pas pourquoi Git en recherche un sur cet ordinateur.
Vous vous connectez via le protocole SSH. En utilisant SSH, chaque hôte a 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é de l'hôte pour domain.com a été modifiée. Si cela ne vous semble pas louche , vous pouvez supprimer l'ancienne clé de votre cache local à l'aide de
$ ssh-keygen -R domain.com
Je vous encourage fortement à envisager que les utilisateurs s'authentifient également avec des clés. De cette manière, ssh-agent
peut stocker le matériel de clé pour plus de commodité (au lieu que tout le monde ait à entrer son mot de passe pour chaque connexion au serveur), les mots de passe ne passant pas par le réseau.
Comme je l'ai déjà répondu dans Le clonage du dépôt git provoque une erreur - La vérification de la clé de l'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 découvert que le problème venait du fichier known_hosts non présent ou de github.com absent de la liste des hôtes connus. Voici les étapes que j'ai suivies pour le résoudre -
mkdir -p ~/.ssh
ssh-keyscan -t rsa github.com >> ~/.ssh/known_hosts
ssh-keygen -t rsa -C "user.email"
Cela se produit car github ne se trouve 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]
pour recevoir à nouveau l'invite.
Pour moi, il me suffisait de taper "oui" à l'invite avec la question "Voulez-vous vraiment continuer à vous connecter (oui/non)?" plutôt que de simplement appuyer sur Entrée.
J'ai eu le même problème sur un système nouvellement installé, mais c'était un problème d'UDev. Il n'y avait pas de noeud /dev/tty
, donc je devais faire:
mknod -m 666 /dev/tty c 5 0
Si vous êtes dans un bureau intranet (sinon dangereux) qui est toujours protégé par un pare-feu, indiquez simplement les lignes suivantes dans votre ~/.ssh/config
Hôte *
StrictHostKeyChecking no
UserKnownHostsFile =/dev/null
Ce qui a fonctionné pour moi a été d’abord d’ajouter ma clé SSH du nouvel ordinateur, puis de suivre les instructions de GitLab - add SSH key . Notez que depuis que je suis sur Win10, je devais faire toutes ces commandes dans Git Bash sous Windows (cela ne fonctionnait pas dans le shell DOS classique).
Encore une fois dans Git Bash, je devais faire un git clone
du repo avec lequel j'avais des problèmes, et dans mon cas, je devais 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, j'ai reçu l'invite pour l'ajouter à la liste des hôtes connus, la question pourrait être celle-ci:
Êtes-vous sûr de vouloir continuer à vous connecter (oui/non)?
J'ai tapé "oui" et cela a finalement fonctionné, vous devriez normalement recevoir un message semblable à ceci:
Avertissement: Ajout permanent de '[votre lien référentiel]' (ECDSA) à la liste des hôtes connus.
Note: si vous êtes sous Windows, assurez-vous que vous utilisez Git Bash pour toutes les commandes, cela ne fonctionnait pas dans cmd Shell ou powershell classique, je devais vraiment le faire dans Git Bash.
Enfin, j'ai supprimé le deuxième référentiel de clonage (myRepo2
dans l'exemple) et je suis retourné à mon premier référentiel. Je pouvais enfin faire tout le travail de Git comme d'habitude dans mon éditeur préféré, le VSCode.
Si vous utilisez git pour Windows.
Le client graphique ajoute la clé pour vous à ~/.ssh/known_hosts
. Ceci est plus facile à retenir si vous ne le faites pas souvent et évite également l’utilisation de la ligne de commande git (les lignes de commande Windows standard n’ont pas l’exécutable ssh-keyscan
.
Lorsque demandé:
Are you sure you want to continue connecting (yes/no)?
Tapez oui comme réponse
C'est comme ça que j'ai résolu mon problème. Mais si vous essayez simplement d'appuyer sur le bouton Entrée, cela ne fonctionnera pas!
Lorsque le serveur distant souhaite se connecter au référentiel privé, il s'authentifie via ssh. Créez la paire clé privée-publique avec ssh-keygen ou si vous avez déjà la clé publique-privée. copier et coller la clé publique dans les paramètres du référentiel privé.
YourPrivateRepo -> Paramètres -> Déployer les clés -> Ajouter la clé de déploiement -> Coller la clé publique.
Maintenant, le serveur distant pourrait se connecter au référentiel privé.
REMARQUE: Les clés de déploiement ont un accès uniquement pour la lecture du référentiel. Besoin d'autoriser explicitement l'accès en écriture.
Cela signifie que la clé de votre hôte distant a été changée
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 ordinateur/serveur. Copiez cette 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, espérons que cela fonctionne.
J'ai eu le même problème, malheureusement, j'ai utilisé l'IHM GitExtensions et j'ai oublié d'avoir écrit un mot de passe complexe . Ne saisissez pas de phrase secrète lorsque vous générez votre clé!
J'étais confronté à la même erreur dans DockerFile lors de la création de l'image 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
Cela serait dû au fait que l'utilisation de la syntaxe [email protected]: ... aboutit à l'utilisation de SSH pour cloner et qu'à l'intérieur du conteneur, votre clé privée n'est pas> disponible. Vous voudrez utiliser RUN git clone> https://github.com/edenhill/librdkafka.git à la place.
Vous pouvez utiliser votre "URL git" au format "https" dans le fichier Jenkins ou à l'endroit souhaité.
git url: 'https://github.com/jglick/simple-maven-project-with-tests.git'