web-dev-qa-db-fra.com

Jenkins: quel est le format correct pour la clé privée dans les informations d'identification

Je crée un travail sous Jenkins 2.152 fonctionnant sous Windows Server 2016 et devant être extrait d'un dépôt Git hébergé sur bitbucket.org . . Lorsque j'essaie d'utiliser la même clé privée avec Jenkins, je reçois un message d'erreur.

Failed to connect to repository : Command "git.exe ls-remote -h 
[email protected]:mygroup/myrepo HEAD" returned status code 128:
stdout: 
stderr: Load key 
"C:\\Users\\JE~1\\AppData\\Local\\Temp\\ssh2142299850576289882.key": invalid format 
[email protected]: Permission denied (publickey). 
fatal: Could not read from remote repository.

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

Les informations d'identification sont configurées comme

 scope: Global
 user: git
 Private Key -> Enter Directly -> copy and past - generated by ssh-keygen -t rsa in gitbash
 Passphrase: empty
 ID: empty
 description: bitbucket.org

J'ai remarqué que sur un autre serveur Windows Jenkins, la clé privée comporte un nombre différent de caractères par ligne.

Quelqu'un sait-il quel est le format attendu de la clé privée dans les informations d'identification Jenkins? Ou peut-être qu'il y a autre chose que je pourrais vérifier.

Toute aide est grandement appréciée.

gitjenkinssshbitbucket
4
Bart C

Vérifiez la version de Git pour Windows que vous utilisez: Démarrage 2.19.2 , il est livré avec OpenSSH v7.9p1 (à partir de 7.7 auparavant)

Et ... openssh 7.8 vient de changer le format par défaut de ssh-keygen, d’un PEM classique à 64 caractères, à un format OPENSSH de 70 caractères!

Seul ssh-keygen -m PEM -t rsa -P "" -f afile générerait l'ancien format (-m PEM)

ssh-keygen(1):

écrire des clés privées au format OpenSSH par défaut au lieu d'utiliser le format PEM d'OpenSSL. 

Le format OpenSSH, pris en charge dans les versions OpenSSH depuis 2014 et décrit dans le fichier PROTOCOL.key de la distribution source, offre une protection considérablement améliorée contre les tentatives de mot de passe hors connexion et prend en charge les commentaires de clé dans les clés privées.
Si nécessaire, il est possible d'écrire d'anciennes clés de style PEM en ajoutant "-m PEM" aux arguments de ssh-keygen lors de la génération ou de la mise à jour d'une clé.

5
VonC

J'ai également reçu ce message d'erreur et découvert que les informations d'identification Jenkins doivent être une clé secrète RSA, et non une clé publique. Ci-dessous, voici mes étapes pour configurer Jenkins pour cloner à partir de bitbucket:

  1. Ajouter des informations d'identification dans les informations d'identification Jenkins
   Kind: SSH username and private key
   Scope: Global
   Username: <my username in bitbucket>
   Private key: <Enter directly>
         -----BEGIN RSA PRIVATE KEY-----
         ......
         -----END RSA PRIVATE KEY-----
  1. Créez un travail et configurez le chemin du référentiel et les informations d'identification comme suit:

 enter image description here

1
Houcheng

En fin de compte, je ne pouvais pas trouver un moyen de faire fonctionner le collage de clés privées sur les informations d'identification Jenkins.

Bien que cela puisse être bien connu pour beaucoup, j'ai quand même décidé de mettre la solution de contournement au-dessous.

Voici ce que j'ai fait comme solution de contournement pour extraire mes référentiels privés de Bitbucket.org:

  1. Connectez-vous à votre hôte Windows en tant qu'utilisateur qui exécute le service Jenkins. Dans mon cas, Jenkins Service fonctionne en tant qu'utilisateur dédié car je devais accéder aux partages réseau avec des privilèges d'écriture limités à cet utilisateur uniquement.
  2. Ouvrez Git-bash et générez des clés SSH avec la commande ssh-keygen acceptant toutes les valeurs par défaut.
  3. Dans Jenkins, entrez l'URL du référentiel git en tant que [email protected]: nom_équipe/nom_po et laissez les informations d'identification en tant que None.

De cette façon, Git et SSH pourront trouver les clés SSH à l’emplacement par défaut, c:\Users\username.ssh \

J'espère que ça aide quelqu'un.

1
Bart C