Authentifier le référentiel privé Jenkins CI for Github

J’aimerais que Jenkins récupère automatiquement les données de mon repository privé hébergé sur Github. Mais je n’ai aucune idée de la manière d’accomplir cette tâche. J’ai essayé la documentation, générant ssh-key pour l’utilisateur jenkins et tout ce que je peux voir est: “impossible de cloner le repo”. J’ai vérifié les URL – elles sont valides.

Des indices, peut-être que vous connaissez des documents / blogs / quoi que ce soit qui décrivent ce genre de choses?

Le support de GitHub pour les clés de déploiement est peut-être ce que vous recherchez? Pour citer cette page:

Quand dois-je utiliser une clé de déploiement?

Simple, lorsque vous avez un serveur qui doit accéder à un seul repository privé. Cette clé est jointe directement au référentiel et non à un compte utilisateur personnel.

Si c’est ce que vous essayez déjà et que cela ne fonctionne pas, vous voudrez peut-être mettre à jour votre question avec plus de détails sur les URL utilisées, les noms et l’emplacement des fichiers de clés, etc.


Maintenant pour la partie technique: Comment utiliser votre clé SSH avec Jenkins?

Si vous avez, par exemple, un utilisateur jenkins unix, vous pouvez stocker votre clé de déploiement dans ~/.ssh/id_rsa . Lorsque Jenkins essaie de cloner le repository via ssh, il essaiera d’utiliser cette clé.

Dans certaines configurations, vous ne pouvez pas exécuter Jenkins en tant que compte utilisateur et vous ne pouvez pas non plus utiliser l’emplacement de la clé ssh par défaut ~/.ssh/id_rsa . Dans de tels cas, vous pouvez créer une clé à un emplacement différent, par exemple ~/.ssh/deploy_key , et configurer ssh pour l’utiliser avec une entrée dans ~/.ssh/config :

 Host github-deploy-myproject HostName github.com User git IdentityFile ~/.ssh/deploy_key IdentitiesOnly yes 

Comme vous vous authentifiez tous dans tous les référentiels Github en utilisant git@github.com et que vous ne voulez pas que la clé ci-dessus soit utilisée pour toutes vos connexions à Github, nous avons créé un hôte alias github-deploy-myproject . Votre URL de clone devient maintenant

 git clone github-deploy-myproject:myuser/myproject 

et c’est aussi ce que vous mettez comme URL de repository dans Jenkins.

(Notez que vous ne devez pas mettre ssh: // en tête pour que cela fonctionne).

Une chose qui a fonctionné pour moi est de s’assurer que github.com trouve dans ~jenkins/.ssh/known_hosts .

Si vous avez besoin de Jenkins pour accéder à plus d’un projet, vous devrez:
1. append une clé publique à un compte utilisateur github
2. ajoutez cet utilisateur en tant que propriétaire (pour accéder à tous les projets) ou en tant que collaborateur dans chaque projet.

De nombreuses clés publiques pour un utilisateur système ne fonctionneront pas car GitHub trouvera la première clé de déploiement correspondante et renverra une erreur telle que “ERREUR: autorisation à l’utilisateur / repo2 refusée à l’utilisateur / repo1”

http://help.github.com/ssh-issues/

Jenkins crée un utilisateur Jenkins sur le système. La clé ssh doit être générée pour l’utilisateur Jenkins. Voici les étapes:

 sudo su jenkins -s /bin/bash cd ~ mkdir .ssh // may already exist cd .ssh ssh-keygen 

Vous pouvez maintenant créer des informations d’identification Jenkins à l’aide de la clé SSH Sur le tableau de bord Jenkins Ajouter des informations d’identification

sélectionnez cette option

Clé privée: du maître Jenkins ~ / .ssh

J’ai eu un problème similaire avec gitlab. Il s’est avéré que j’avais restreint les utilisateurs autorisés à se connecter via ssh. Cela n’affectera pas les utilisateurs de github, mais si des personnes se retrouvent ici pour des problèmes avec gitlab (et autres), veillez à append git au paramètre AllowUsers dans /etc/ssh/sshd_config :

 # Authentication: LoginGraceTime 120 PermitRootLogin no SsortingctModes yes AllowUsers batman git 

Une alternative à la réponse de sergey_mo est de créer plusieurs clés ssh sur le serveur jenkins.

(Bien que comme le premier commentateur de la réponse de sergey_mo ait dit, cela pourrait finir par être plus douloureux que de gérer une seule paire de clés.)