it-swarm.com.de

Jenkins: Welches ist das richtige Format für den privaten Schlüssel in Credentials?

Ich erstelle einen Job in Jenkins 2.152, der unter Windows Server 2016 ausgeführt wird und von einem auf bitbucket.org gehosteten Git-Repo ausgeführt werden muss Wenn ich versuche, den gleichen privaten Schlüssel mit Jenkins zu verwenden, erhalte ich eine Fehlermeldung.

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.

Die Anmeldeinformationen sind als eingerichtet

 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

Ich habe festgestellt, dass auf einem anderen Windows Jenkins-Server der private Schlüssel eine andere Anzahl von Zeichen pro Zeile hat

Weiß jemand, welches das erwartete Format des privaten Schlüssels in Jenkins-Berechtigungsnachweisen ist? Oder vielleicht gibt es noch etwas, das ich überprüfen könnte.

Jede Hilfe wird sehr geschätzt.

4
Bart C

Überprüfen Sie die Version von Git für Windows, die Sie verwenden: ab 2.19.2 , es kommt mit OpenSSH v7.9p1 (ab 7.7 vor)

Und ... openssh 7.8 hat gerade das standardmäßige ssh-keygen-Format geändert, von einem klassischen PEM 64-Zeichen auf ein OPENSSH mit 70 Zeichen!

Nur ssh-keygen -m PEM -t rsa -P "" -f afile Würde das alte Format erzeugen (-m PEM)

ssh-keygen(1):

standardmäßig werden private Schlüssel im OpenSSH-Format geschrieben, anstatt das PEM-Format von OpenSSL zu verwenden.

Das OpenSSH-Format, das in OpenSSH-Versionen seit 2014 unterstützt wird und in der Datei PROTOCOL.key In der Quelldistribution beschrieben ist, bietet einen wesentlich besseren Schutz gegen das Erraten von Offline-Passwörtern und unterstützt Schlüsselkommentare in privaten Schlüsseln.
Bei Bedarf können alte Schlüssel im PEM-Stil geschrieben werden, indem "-m PEM" Zu den Argumenten von ssh-keygen hinzugefügt wird, wenn ein Schlüssel generiert oder aktualisiert wird.

9
VonC

Ich erhielt auch diese Fehlermeldung und fand schließlich heraus, dass der Jenkins-Berechtigungsnachweis der RSA-Geheimschlüssel und nicht der öffentliche Schlüssel sein sollte. Im Folgenden sind meine Schritte zum Konfigurieren von Jenkins für das Klonen von Bitbucket aufgeführt:

  1. Fügen Sie Anmeldeinformationen in Jenkins-Anmeldeinformationen hinzu
   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. Erstellen Sie einen Job und konfigurieren Sie den Repository-Pfad und die Berechtigungsnachweise wie folgt:

 enter image description here

1
Houcheng

Am Ende konnte ich keine Möglichkeit finden, private Schlüssel in Jenkins Anmeldeinformationen einzufügen.

Obwohl es für viele allgemein bekannt ist, entschied ich mich, die Problemumgehung trotzdem unterzuschreiben.

Folgendes habe ich als Workaround getan, um meine privaten Repositories von Bitbucket.org zu ziehen:

  1. Melden Sie sich bei Ihrem Windows-Host als Benutzer an, der den Jenkins-Dienst ausführt. In meinem Fall wird Jenkins Service als dedizierter Benutzer ausgeführt, da auf Netzwerkfreigaben mit Schreibberechtigungen nur für diesen Benutzer zugegriffen werden muss.
  2. Öffnen Sie Git-bash und generieren Sie SSH-Schlüssel mit dem Befehl ssh-keygen, der alle Standardeinstellungen akzeptiert
  3. Geben Sie in Jenkins die git repo-URL als [email protected] ein: team_name/repo_name und belassen Sie die Berechtigungsnachweise als None.

Auf diese Weise können Git und SSH SSH-Schlüssel am Standardspeicherort finden, normalerweise c:\Users\username.ssh \.

Hoffe das hilft jemandem.

1
Bart C

Irgendwie habe ich es wieder zum Laufen gebracht, aber die tatsächlichen Schritte zur Behebung des Problems sind unklar.

was ich getan habe, ist, den SSH-Schlüssel erneut zu generieren und alles an seinen Standardspeicherort zu setzen. Laden Sie den öffentlichen Schlüssel erneut hoch, ersetzen Sie den privaten Schlüssel im Berechtigungsnachweis, und der Vorgang beginnt.

0
Panda World