-
Bug
-
Resolution: Duplicate
-
Major
-
None
-
Jenkins 1.598
Linux 2.6.32-431.5.1.el6.x86_64
CentOS release 6.5 (Final)
Plugins:
Attached file saved from pluginManager/api/xml?tree=plugins[shortName,version]&pretty
I have a private key set up in the global credentials (named sls). I have the SCM for a test project set up to download code from a springloops git project. See attached log of the failure to connect to git.
Fetching the repo with command line git works fine with the same key. If I install an SSH agent on the exact same build, it allows the fetch to work. See the other attached log for that.
I have used jenkins and git in a different environment with no problems. The only difference I've noticed here is the non-standard port of 1234. Is it possible git plugin is not identifying the port?
Setting the priority to major since use of SSH agent is a workaround but requires extra configuration and build overhead.
- duplicates
-
-
- Closed
-
- is duplicated by
-
-
- Closed
-
[JENKINS-27998] Git plugin fails to clone with ssh protected passphrase
The credentials for the original key do have a passphrase attached; the SSH agent plugin is using it correctly. But it looks like the git plugin is not.
I tested a key with no passphrase and confirmed that the git plugin does work in that case.
Is it possible to fix this? It seems like a security flaw to have to always use keys with no passphrase.
It is possible to fix that. Someone would need to add support for passphrase protected ssh keys to the git plugin authentication, or if it is implemented and not working, they would need to fix the bug. Pull requests with automated tests are welcomed.
Regarding your comment about it being a security flaw, I don't see how entering the passphrase into a web form in Jenkins is any more secure than using an ssh key with no passphrase. In both cases, there is enough information stored in Jenkins to use the credential, without any additional prompting.
Git client plugin pull request 168 has been accepted into the git client plugin builds for 1.18.0 and beyond. It allows private keys protected by a passphrase on Linux (and likely on other Unix variants). It does not allow private keys protected by a passphrase on Windows.
I have no estimate on the timeline for delivery of git client plugin 1.18.0 because that plugin version needs a matching release of the git plugin, and that git plugin release needs significant testing before it is released.
Included in git client plugin 1.18.0 released 18 July 2015 for Unix based clients. Not clear if a fix for Windows based clients is possible.
Dejay Clayton
added a comment - I'm experiencing this issue for the first time, after my coworker updated all Jenkins plugins. git-client was upgraded to v1.18.0. I'm not sure what version was previously installed.
Keys without passwords work fine; keys with passwords no longer work.
If I log into the shell account for the Jenkins tomcat user, I see the following message echoed to the screen whenever Jenkins attempts to verify the Git credentials:
"Enter passphrase for key '/home/tomcat/tomcat/temp/ssh8175827570904316216key':
This problem persists in git-client versions 1.18 and 1.19. I'm not sure what version was installed when passwords seemed to work properly.
I'm using Jenkins 1.622 on Ubuntu 14.04.3 LTS, and Jenkins 1.617 on Yosemite. My repositories are hosted on GitHub.
Dejay Clayton
added a comment - I'm experiencing this issue for the first time, after my coworker updated all Jenkins plugins. git-client was upgraded to v1.18.0. I'm not sure what version was previously installed.
Keys without passwords work fine; keys with passwords no longer work.
If I log into the shell account for the Jenkins tomcat user, I see the following message echoed to the screen whenever Jenkins attempts to verify the Git credentials:
"Enter passphrase for key '/home/tomcat/tomcat/temp/ssh8175827570904316216key':
This problem persists in git-client versions 1.18 and 1.19. I'm not sure what version was installed when passwords seemed to work properly.
I'm using Jenkins 1.622 on Ubuntu 14.04.3 LTS, and Jenkins 1.617 on Yosemite. My repositories are hosted on GitHub.
The git plugin definitely supports a non-standard port as part of the ssh protocol specification. I regularly test that ssh://mwaite@wheezy64b:45022/var/lib/git/mwaite/bin.git (an ssh protected private repo on my machine named "wheezy64b") can be retrieved with the git client plugin automated tests.
If the ssh agent allows you to fetch, then it may be that you have an ssh passphrase configured on that ssh key. I believe that if a passphrase is configured on the ssh key, then the only way to make the git client use that passphrase is through the ssh agent.
You might also try the "Advanced" button in the credentials plugin to see if it will allow you to enter the passphrase, but my recollection is that didn't allow the plugin to use the passphrase.