Clone d'un repo git échoue dans un script

a marqué ce sujet comme résolu.

Bonjour!

J’ai un script qui se lance une fois que vagrant a fini de configurer Ubuntu. Dans celui-ci, je demande de cloner deux repositories mais git échoue avec le message d’erreur suivant :

1
2
3
4
5
6
Cloning into 'frontend'...
Host key verification failed.
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.

Alors que en SSH et en faisant le clone manuellement, je n’ai aucun soucis, du coup je ne comprend vraiment pas pourquoi il refuse dans le script. Sachant que je désactive la vérification des clés :

1
2
echo -e "Host *" >> /home/vagrant/.ssh/config
echo -e "\tStrictHostKeyChecking no" >> /home/vagrant/.ssh/config

avant de faire mes git clone afin d’éviter le message suivant :

1
2
3
The authenticity of host '0.0.0.1' can't be established.
RSA key fingerprint is <>.
Are you sure you want to continue connecting (yes/no)?

Auriez-vous une solution ? Merci !

Salut,

Quand tu dis que en SSH et en faisant le clone manuellement tu n’as aucun soucis, comment tu fais pour cloner manuellement ? Tu le fais en utilisant ton login habituel ?

Le script qui se charge de cloner les dépôts depuis vagrant, y’a de forte chance qu’il soit exécuté depuis l’utilisateur « vagrant ». Cela veut dire que tu dois générer les clefs publiques/privées pour cet utilisateur aussi, elles doivent être présente’s dans /home/vagrant/.ssh/ (id_rsa.pub et id_rsa) et le serveur Git doit posséder la clef publique.

Parce que ce que te dis l’erreur, c’est un problème de droits, notamment que la vérification des clefs à échouée.

+0 -0

Salut,

Sachant que je désactive la vérification des clés :

Ceci ne désactive pas la vérification des clés, mais de l’hôte. La vérification est faite par le serveur, tu ne peux pas la désactiver depuis le client : Le serveur connaît la clé publique et il demande au client une preuve qu’il possède la clé privée (sans réellement transmettre la clé privée).

Quand tu dis que en SSH et en faisant le clone manuellement tu n’as aucun soucis, comment tu fais pour cloner manuellement ? Tu le fais en utilisant ton login habituel ?

Juste vagrant ssh et je rentre ma commande immédiatement, rien de plus.

Le script qui se charge de cloner les dépôts depuis vagrant, y’a de forte chance qu’il soit exécuté depuis l’utilisateur « vagrant ». Cela veut dire que tu dois générer les clefs publiques/privées pour cet utilisateur aussi, et elles doivent être présente’s dans /home/vagrant/.ssh/ (id_rsa.pub et id_rsa)

En fait, c’est un peu plus compliqué. On un a dépôt ’vagrant’ qui contient le vagrantfile et le fichier configure qui me sert à configurer tout l’environnement de développement. En suite deux projets, ’backend’ et ’frontend’ qui sont sur deux depo séparés. Tous les repo sont sur un serveur privé où l’on s’y connecte avec sa clé ssh ou le mot de passe.

Afin d’évité de s’embêter à devoir ajouter la clé d’un dev à chaque fois qu’il initialise le projet, on a crée une clé RSA que l’on ajouté au serveur et dans le dépo vagrant. Celle-ci est copié dans le dossier /home/vagrant/.ssh pendant la configuration. Voici à quoi ça ressemble :

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
echo -e "\n--- Copying ssh keys ---\n"
cp /vagrant/id_rsa /home/vagrant/.ssh/id_rsa
cp /vagrant/id_rsa.pub /home/vagrant/.ssh/id_rsa.pub

chown vagrant:vagrant /home/vagrant/.ssh/id_rsa /home/vagrant/.ssh/id_rsa.pub
chmod 600 /home/vagrant/.ssh/id_rsa
chmod 644 /home/vagrant/.ssh/id_rsa.pub

echo -e "Host *" >> /home/vagrant/.ssh/config
echo -e "\tStrictHostKeyChecking no" >> /home/vagrant/.ssh/config

Et les git clone du script échouent tous. Alors que si je fais vagrant ssh et je lance git clone <mon_dépo> ça fonctionne sans problème alors que c’est la même commande que dans le script… > Salut,

Ceci ne désactive pas la vérification des clés, mais de l’hôte. La vérification est faite par le serveur, tu ne peux pas la désactiver depuis le client : Le serveur connaît la clé publique et il demande au client une preuve qu’il possède la clé privée (sans réellement transmettre la clé privée).

Oui je me suis mal exprimé, mais j’ai bien compris ce que ça faisait ;)

+0 -0

OK, mais on ne peut pas partager des dossiers proprement entre l’hôte et la VM avec Vagrant ? Je connais pas bien Vagrant mais j’utilise beaucoup Docker d’une manière équivalente, et copier une clé SSH privée vers le conteneur pour cloner le dépot, c’est clairement pas une bonne idée.

+0 -0

(Docker aussi est relativement multiplateforme)

Mais du coup, pourquoi tu veut utiliser Git dans ta VM ? Moi, je n’utilise Git que sur mon hôte, et je partage le dossier (ou des parties du dossier) du dépot avec les conteneurs. Comme ça je n’ai pas à transférer des clés SSH aux conteneurs ni à installer Git dans les conteneurs. Tu devrais pouvoir faire exactement la même chose avec Vagrant, non ?

+0 -0

Parce que ça demanderait d’écrire un script pour initialiser l’environnement pour OS X, un pour Windows… On est plusieurs à développer sur ce projet dont beaucoup de personne qui n’ont pas envie de s’amuser à configurer tout l’environnement. C’est pour ça que je me prend la tête avec Vagrant, qui a un avantage par rapport à docker : il est plus simple à utiliser sous Windows. J’y arrivais sans problème avant quand on avait pas besoin de ces git clone, mais là je bloque.

Ouais mais d’expérience je n’ai jamais vu quelqu’un utiliser Git dans une VM comme tu veut le faire et je ne vois pas l’intérêt d’utiliser Git comme ça. Déjà, il y a des tas de clients Git différents (l’officiel en ligne de commande, GitHub Desktop, GitKraken, ungit, …) et même avec l’officiel en ligne de commande, normalement chacun le configure pour qu’il utilise l’éditeur de son choix (qui n’est pas configuré dans la VM). Puis je penses que tu risques de mal à faire tourner un client Git graphique dans une VM.

Normalement, Windows ou pas Windows, c’est toujours beaucoup plus simple d’installer Git directement sur l’hôte et de simplement partager de dossier du projet à la VM. Et si tu travailles avec des gens qui débutent, je pense que c’est même mieux pour eux parce que tu peux leur faire profiter de clients graphiques assez intuitifs comme GitHub Desktop.

+0 -0
Connectez-vous pour pouvoir poster un message.
Connexion

Pas encore membre ?

Créez un compte en une minute pour profiter pleinement de toutes les fonctionnalités de Zeste de Savoir. Ici, tout est gratuit et sans publicité.
Créer un compte