J'essaie de connecter Jenkins sur un dépôt Github.
Lorsque je spécifie les jenkins d'URL de dépôt, le message d'erreur suivant s'affiche:
Échec de la connexion au référentiel: La commande "git ls-remote -h [email protected]: adolfosrs/jenkins-test.git HEAD" a renvoyé le code d'état 128: stdout: stderr: La vérification de la clé de l'hôte a échoué . fatal: Impossible de lire à partir du référentiel distant . Assurez-vous d’avoir les droits d’accès corrects et le référentiel existe.
Lors de l'utilisation de HTTPS: // URL Jenkins retourne:
Échec de la connexion au référentiel: Échec de la connexion à https://github.com/adolfosrs/jenkins-test.git (status = 407)
Je pourrais cloner avec succès le repo sur la même machine que jenkins et exécuter la commande git ls-remote -h [email protected]:adolfosrs/jenkins-test.git HEAD
. J'ai donc le bon SSH sur github.
Le problème était que, d’une manière ou d’une autre, j’avais créé les fichiers ssh avec l’utilisateur root . Le propriétaire des fichiers était donc root.
La solution consistait simplement à changer le propriétaire en utilisateur jenkins.
chown jenkins id_rsa.pub
chown jenkins id_rsa
C’est un problème très délicat - même si vous connaissez le fonctionnement de https avec des certificats (OTOH si vous voyez ma solution de contournement, cela semble très logique :)
Si vous souhaitez vous connecter à un référentiel GIT via http (s) à partir de Shell, vous devez vous assurer que le certificat public est stocké (sous forme de fichier) sur votre ordinateur. Ensuite, vous ajouteriez ce certificat à votre configuration GIT
git config [--global] http.sslCAInfo "certificat"
(remplacez "certificat" par le chemin/nom complet du fichier PEM :)
Pour l’utilisation de Shell, vous pouvez également, par exemple, fournissez un '.netrc' fournissant vos informations d'identification pour la connexion au serveur http . Après cela, vous serez en mesure de faire un 'git clone https: // ...' sans aucune fourniture interactive d'informations d'identification.
Cependant, pour le service Jenkins, c'est un peu différent ... Ici, le processus jenkins doit être conscient du certificat du serveur - et il n'utilise pas les paramètres du shell (au sens du fichier de configuration global git '.gitconfig'): P
Ce que je devais faire, c’était d’ajouter un autre paramètre aux options de démarrage de Jenkins.
... -Djavax.net.ssl.trustStore = "magasin de clés" ...
(remplacez "keystore" par le chemin/nom complet, comme expliqué ci-dessous :)
Maintenant, copiez le fichier de clés de votre serveur Web contenant le certificat sur un chemin (je sais que c’est un sale bidouillage et pas exactement secure :) et y faire référence avec le paramètre '-Djavax.net.ssl.trustStore ='.
Maintenant, le service Jenkins acceptera le certificat du serveur Web fournissant le référentiel via https. Configurez l'URL du référentiel GIT comme
Notez que vous avez toujours besoin du '.netrc' sous le dossier personnel jenkins-user pour la connexion !!! Ainsi, ce que je décris doit être considéré comme une solution de contournement ... jusqu'à ce qu'un plug-in d'assistance aux informations d'identification fonctionnant correctement soit fourni. IMHO ce plugin (dans sa version actuelle 1.9.4) est buggy.
Peu importe ce que j'ai essayé: (__), je ne pouvais jamais faire en sorte que l'assistant des informations d'identification fonctionne avec Jenkins. Au mieux, j'ai pu voir quelques erreurs concernant le fichier d'assistance des informations d'identification temporaires non accessible, etc. Vous pouvez voir de nombreux bogues signalés à ce sujet. dans le Jenkins JIRA, mais pas de solution.
Donc, si quelqu'un a bien fonctionné, partagez vos connaissances ...
P.S .: Utilisation des plugins Jenkins dans les versions suivantes:
Plugin Credentials 1.9.4, Plugin client GIT 1.6.1, Jenkins GIT plugin 2.0.1
J'ai eu exactement le même problème. Voici comment j'ai résolu le problème sur Mac:
Dans notre cas, git
devait être installé sur le serveur Jenkins.
Jenkins s'exécute en tant qu'utilisateur différent et non en tant que votre identifiant de connexion habituel ..__, faites comme ceci pour résoudre le problème de ssh:
su jenkins
(Vous devrez peut-être d'abord Sudo passwd jenkins
pour pouvoir définir le mot de passe de jenkins. Je n'ai pas trouvé le nom par défaut ...)ssh-keygen
id_rsa.pub
) sur votre compte github (ou ailleurs)known_hosts
, ce qui est nécessaire. Vous pouvez maintenant supprimer le référentiel cloné si vous le souhaitez.Vérifiez avec les paramètres ci-dessous. Cela fonctionne toujours pour moi.
Configuration Jenkins:
1) Vérifier si l'exécutable git est correctement spécifié
2) Fournir un lien vers le référentiel SSH git @ blahblah
3) Sous les informations d'identification >> Sélectionnez le nom d'utilisateur et la clé d'authentification (allez sur votre serveur, Générez les clés SSH ssh-keygen ... Copiez les clés dans JENKINS_HOME /, ssh). Vous devriez pouvoir vous connecter à votre référentiel GIT à partir de Jenkins.
Sur Ubuntu, placez vos fichiers id_rsa
et id_rsa.pub
dans /var/lib/jenkins/.ssh
Faites en sorte que Jenkins les possède Sudo chown -R jenkins /var/lib/jenkins/.ssh/
Assurez-vous que la clé Jenkins est ajoutée en tant que clé de déploiement avec un accès RW dans GitHub (ou similaire) - utilisez la clé id_rsa.pub
pour cela.
Maintenant, tout devrait fonctionner avec le plugin SCM Sync.
Dans mon cas, j'ai édité le fichier known_hosts avec l'utilisateur root. Ainsi, la propriété du fichier a été modifiée en root et l'utilisateur jenkins a commencé à émettre l'erreur "[email protected]: xxxxxx/xxxx.git HEAD", qui a renvoyé le code d'état 128: stdout: stderr: la vérification de la clé d'hôte "lors du clonage de l'image git . Rétablir la propriété a résolu le problème.
Permettez-moi d'ajouter ici qu'un problème très mineur susceptible de générer ce type d'erreur est l'extension .git
manquante dans l'URL du référentiel. Assurez-vous d'entrer l'URL complète se terminant par .git
. J'utilise bitbucket, donc je clique sur "cloner" et l'URL complète est automatiquement générée pour moi. Il y a une approche similaire avec github.
Assurez-vous que la clé d'hôte RSA et l'adresse IP du serveur bitbucket sont ajoutées au fichier «hôtes connus». Le contenu devrait ressembler à
bitbucket.org,xx.xx.xx.xx ssh-rsa Host_key
N'oubliez pas de changer le propriétaire en Jenkins pour tous les fichiers dans /var/lib/jenkins/.ssh/
Cela n'est pas mentionné ici jusqu'à présent, mais cela peut également provenir de stash .. Nous avons rencontré le même problème, la cause principale de notre problème était que l'instance de stash que nous utilisons pour jenkins était en panne. Le redémarrage de Stash a résolu le problème dans notre cas.