[JIRA] [git-client-plugin] (JENKINS-20879) SSH Credentials (private key with passphrase) do not work

35 views
Skip to first unread message

tom.gl@free.fr (JIRA)

unread,
May 13, 2015, 1:12:02 PM5/13/15
to jenkinsc...@googlegroups.com
Thomas de Grenier de Latour commented on Bug JENKINS-20879
 
Re: SSH Credentials (private key with passphrase) do not work

Here is an attempt at fixing polling with GitCli and a passphrase-protected SSH private key:
https://github.com/jenkinsci/git-client-plugin/pull/168
Works for me on Ubuntu 12.04.
Add Comment Add Comment
 
This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265)
Atlassian logo

tom.gl@free.fr (JIRA)

unread,
May 13, 2015, 1:16:02 PM5/13/15
to jenkinsc...@googlegroups.com
Here is an attempt at fixing polling with GitCli and a passphrase-protected SSH private key:
https://github.com/jenkinsci/git-client-plugin/pull/168
Works for me on Ubuntu 12.04 , with this patch on top of the git-client-plugin 1 . 17.1 and git-plugin 2.3.5 (and git 2.4.0 from the git-core PPA).

scm_issue_link@java.net (JIRA)

unread,
May 16, 2015, 7:34:09 AM5/16/15
to jenkinsc...@googlegroups.com

Code changed in jenkins
User: Thomas de Grenier de Latour
Path:
src/main/java/org/jenkinsci/plugins/gitclient/CliGitAPIImpl.java
http://jenkins-ci.org/commit/git-client-plugin/21bc7357e20649bf3c96ed1cd12471ea330abe5d
Log:
JENKINS-20879 - make sure $SSH_ASKPASS is not ignored

scm_issue_link@java.net (JIRA)

unread,
May 16, 2015, 7:34:10 AM5/16/15
to jenkinsc...@googlegroups.com

Code changed in jenkins
User: Mark Waite
Path:
src/main/java/org/jenkinsci/plugins/gitclient/CliGitAPIImpl.java
http://jenkins-ci.org/commit/git-client-plugin/0e67e3d4003124d98db540b86f27d0c4d1347493
Log:
Merge pull request #168 from thomasgl-orange/JENKINS-20879

JENKINS-20879 - make sure $SSH_ASKPASS is not ignored on Unix.

Does not fix the passphrase protected private keys on Windows,
just on Unix machines.

Compare: https://github.com/jenkinsci/git-client-plugin/compare/2f0cd5d3ce52...0e67e3d40031

mark.earl.waite@gmail.com (JIRA)

unread,
May 16, 2015, 7:46:02 AM5/16/15
to jenkinsc...@googlegroups.com

Thanks Thomas de Grenier de Latour for the pull request. It should be included in the next release of the git client plugin (likely either 1.17.2 or 1.18.0).

Please note that the pull request only helped in my testing on Linux machines, not on Windows. The Windows machines continue to behave incorrectly with command line git when using a passphrase protected private key. Refer to the comments in the pull request for more details on the cases tested and the test results.

mark.earl.waite@gmail.com (JIRA)

unread,
Jun 6, 2015, 5:27:03 PM6/6/15
to jenkinsc...@googlegroups.com

The git plugin and git client plugin are being tested in hopes of releasing new versions before the end of June. If you're willing to assist with the testing, please download and install a pre-release build of the git client plugin and the git plugin. Problems detected in the pre-release should be e-mailed to Mark Waite and Nicolas De Loof.

I wrote some test ideas if you would like suggestions of areas that need testing. The git plugin supports many different use cases and its automated tests only evaluate a very few of those use cases.

mark.earl.waite@gmail.com (JIRA)

unread,
Jul 18, 2015, 10:55:02 AM7/18/15
to jenkinsc...@googlegroups.com
Mark Waite resolved as Fixed
 

Included in git client plugin 1.18.0 released 18 July 2015 as fix for Unix based clients. Not clear that a fix is possible for Windows based clients.
Jenkins / Bug JENKINS-20879
Change By: Mark Waite
Status: Open Resolved
Resolution: Fixed

mark.earl.waite@gmail.com (JIRA)

unread,
Jul 27, 2015, 11:18:09 PM7/27/15
to jenkinsc...@googlegroups.com
Mark Waite closed an issue as Fixed
Change By: Mark Waite
Status: Resolved Closed

dejay@dejayclayton.com (JIRA)

unread,
Oct 1, 2015, 3:41:04 PM10/1/15
to jenkinsc...@googlegroups.com
Dejay Clayton reopened an issue
 

I'm experiencing this issue for the first time, after my coworker updated all Jenkins plugins. Keys without passwords work fine; keys with passwords no longer work.

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.
Change By: Dejay Clayton
Resolution: Fixed
Status: Closed Reopened

dejay@dejayclayton.com (JIRA)

unread,
Oct 1, 2015, 3:47:04 PM10/1/15
to jenkinsc...@googlegroups.com
Dejay Clayton edited a comment on Bug JENKINS-20879
 
Re: SSH Credentials (private key with passphrase) do not work
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.

mark.earl.waite@gmail.com (JIRA)

unread,
Oct 1, 2015, 11:19:09 PM10/1/15
to jenkinsc...@googlegroups.com

Dejay Clayton sorry to hear that it is not working for you. It will need more investigation to understand if the problem can be duplicated.

In the future, please don't quadruple my work by reopening the bug and the 3 duplicates with the same comment in each of the reopened bug reports. There are relatively few working on the plugin, and making those few people work on a bug and 3 duplicates seems wasteful.

mark.earl.waite@gmail.com (JIRA)

unread,
Oct 1, 2015, 11:22:08 PM10/1/15
to jenkinsc...@googlegroups.com
Mark Waite edited a comment on Bug JENKINS-20879
[~dejayc] sorry to hear that it is not working for you. It will need more investigation to understand if the problem can be duplicated.


In the future, please don't quadruple my work by reopening the bug and the 3 duplicates with the same comment in each of the reopened bug reports. There are relatively few working on the plugin, and making those few people work on a bug and 3 duplicates seems wasteful.


When I performed the testing, I used git client plugin 1.19.0 and git plugin 2.4.0. I do not have access to a MacOS system, so my testing was performed on CentOS 6, CentOS 7, Debian 6, Debian 7, Debian 8, and Ubuntu 14.  The testing passed on those platforms.  The testing failed on all the tested Windows platforms (Windows 7, Windows 8, Windows Server 2011).

mark.earl.waite@gmail.com (JIRA)

unread,
Oct 2, 2015, 7:49:03 AM10/2/15
to jenkinsc...@googlegroups.com
Mark Waite edited a comment on Bug JENKINS-20879
[~dejayc] sorry to hear that it is not working for you. It will need more investigation to understand if the problem can be duplicated.

In the future, please don't quadruple my work by reopening the bug and the 3 duplicates with the same comment in each of the reopened bug reports. There are relatively few working on the plugin, and making those few people work on a bug and 3 duplicates seems wasteful.

When I performed the testing, I used git client plugin 1. 19 18 .0 and git plugin 2.4.0. I do not have access to a MacOS system, so my testing was performed on CentOS 6, CentOS 7, Debian 6, Debian 7, Debian 8, and Ubuntu 14.  The testing passed on those platforms.  The testing failed on all the tested Windows platforms (Windows 7, Windows 8, Windows Server 2011).

mark.earl.waite@gmail.com (JIRA)

unread,
Oct 2, 2015, 9:57:12 AM10/2/15
to jenkinsc...@googlegroups.com

Steps I took to confirm it was working on my existing Ubuntu 14.04 x64
master (previously using git client plugin 1.18.0, then git client
plugin 1.19.0, and now using an unreleased version of the git client
plugin that is adding submodule authentication):

1. Create a new user "hasphrase"
2. Login as user "hasphrase"
3. Generate passphrase protected private key
4. Create a private git repo for that user at /var/lib/git/hasphrase/bin.git
5. Confirm other system users cannot clone that repo
6. Create multi-configuration Jenkins job attempting to use that repo, use Elastic Axis plugin and Platform Labeler plugin to run job on "windows || linux || freebsd", restrict polling to only run from linux machines
7. Confirm Jenkins job cannot read the repo (exception polling, exception building)
8. Define Jenkins credential with private key and passphrase of user "hasphrase"
9. Modify Jenkins job to use that newly defined credential
10. Confirm job can read the repo (no exception polling, linux and freebsd slaves succeed, windows slaves fail)

Steps I took to confirm it failed on a freshly constructed Docker
instance (using git client plugin 1.19.0 and git plugin 2.4.0):

1. Run my [master-with-plugins Docker instance]()
2. Define job attempting to use that repo
3. Confirm job cannot read the repo (no credential defined)
4. Define new credential with the passphrase protected private key

Exception reported while defining the credential in the Docker
instance:

Caused by: java.lang.NullPointerException
at com.cloudbees.jenkins.plugins.sshcredentials.impl.BasicSSHUserPrivateKey.getPrivateKeys(BasicSSHUserPrivateKey.java:126)
at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.createSshKeyFile(CliGitAPIImpl.java:1432)
at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandWithCredentials(CliGitAPIImpl.java:1300)
at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandWithCredentials(CliGitAPIImpl.java:1282)
at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandWithCredentials(CliGitAPIImpl.java:1273)
at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.getHeadRev(CliGitAPIImpl.java:2404)
at hudson.plugins.git.UserRemoteConfig$DescriptorImpl.doCheckUrl(UserRemoteConfig.java:156)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at org.kohsuke.stapler.Function$InstanceFunction.invoke(Function.java:298)
at org.kohsuke.stapler.Function.bindAndInvoke(Function.java:161)
at org.kohsuke.stapler.Function.bindAndInvokeAndServeResponse(Function.java:96)
at org.kohsuke.stapler.MetaClass$1.doDispatch(MetaClass.java:121)
at org.kohsuke.stapler.NameBasedDispatcher.dispatch(NameBasedDispatcher.java:53)
at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:746)
... 56 more

Additional attempts included checking that the Docker instance could
use a private key without passphrase (which it could), and that the
prompt for the host key fingerprint was not the root reason why the
job failed (it did not seem to be the root reason, since even after
the private key without passphrase worked, the private key with
passphrase was still prompting for the password).

When I copied the job which uses the passphrase protected key, the
polling log reported there was no existing build so it scheduled a
build without polling. When that job ran, it hung with a prompt in the
Docker window requesting a passphrase for a temporary key file.

Enter passphrase for key '/tmp/ssh5560754303468136093key':

Future experiments might include:

1. Define the DISPLAY environment variable for Jenkins system-wide
2. Try unreleased git client plugin on Docker instance
3. Review createSshKeyFile null pointer exception
4. Implement passphrase protected private key test in CredentialsTest

mark.earl.waite@gmail.com (JIRA)

unread,
Oct 2, 2015, 9:58:04 AM10/2/15
to jenkinsc...@googlegroups.com
Mark Waite edited a comment on Bug JENKINS-20879
Steps I took to confirm it was working on my existing Ubuntu 14.04 x64
master (previously using git client plugin 1.18.0, then git client
plugin 1.19.0, and now using an unreleased version of the git client
plugin that is adding submodule authentication):
1. #  Create a new user "hasphrase"
 2. #  Login as user "hasphrase"
 3. #  Generate passphrase protected private key
 4. #  Create a private git repo for that user at /var/lib/git/hasphrase/bin.git
 5. #  Confirm other system users cannot clone that repo
 6. #  Create multi-configuration Jenkins job attempting to use that repo, use Elastic Axis plugin and Platform Labeler plugin to run job on "windows || linux || freebsd", restrict polling to only run from linux machines
 7. #  Confirm Jenkins job cannot read the repo (exception polling, exception building)
 8. #  Define Jenkins credential with private key and passphrase of user "hasphrase"
 9. #  Modify Jenkins job to use that newly defined credential
 10. #  Confirm job can read the repo (no exception polling, linux and freebsd slaves succeed, windows slaves fail)


Steps I took to confirm it failed on a freshly constructed Docker
instance (using git client plugin 1.19.0 and git plugin 2.4.0):

1. #  Run my [master-with-plugins Docker instance]()
 2. #  Define job attempting to use that repo
 3. #  Confirm job cannot read the repo (no credential defined)
 4. #  Define new credential with the passphrase protected private key


Exception reported while defining the credential in the Docker
instance:

{code}
    Caused by: java.lang.NullPointerException
        at com.cloudbees.jenkins.plugins.sshcredentials.impl.BasicSSHUserPrivateKey.getPrivateKeys(BasicSSHUserPrivateKey.java:126)
        at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.createSshKeyFile(CliGitAPIImpl.java:1432)
        at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandWithCredentials(CliGitAPIImpl.java:1300)
        at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandWithCredentials(CliGitAPIImpl.java:1282)
        at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandWithCredentials(CliGitAPIImpl.java:1273)
        at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.getHeadRev(CliGitAPIImpl.java:2404)
        at hudson.plugins.git.UserRemoteConfig$DescriptorImpl.doCheckUrl(UserRemoteConfig.java:156)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.lang.reflect.Method.invoke(Method.java:497)
        at org.kohsuke.stapler.Function$InstanceFunction.invoke(Function.java:298)
        at org.kohsuke.stapler.Function.bindAndInvoke(Function.java:161)
        at org.kohsuke.stapler.Function.bindAndInvokeAndServeResponse(Function.java:96)
        at org.kohsuke.stapler.MetaClass$1.doDispatch(MetaClass.java:121)
        at org.kohsuke.stapler.NameBasedDispatcher.dispatch(NameBasedDispatcher.java:53)
        at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:746)
        ... 56 more
{code}

Additional attempts included checking that the Docker instance could
use a private key without passphrase (which it could), and that the
prompt for the host key fingerprint was not the root reason why the
job failed (it did not seem to be the root reason, since even after
the private key without passphrase worked, the private key with
passphrase was still prompting for the password).

When I copied the job which uses the passphrase protected key, the
polling log reported there was no existing build so it scheduled a
build without polling. When that job ran, it hung with a prompt in the
Docker window requesting a passphrase for a temporary key file.
{code}
    Enter passphrase for key '/tmp/ssh5560754303468136093key':
{code}

Future experiments might include:

 1. #  Define the DISPLAY environment variable for Jenkins system-wide
 2. #  Try unreleased git client plugin on Docker instance
 3. #  Review createSshKeyFile null pointer exception
 4. #  Implement passphrase protected private key test in CredentialsTest

mark.earl.waite@gmail.com (JIRA)

unread,
Oct 2, 2015, 9:59:09 AM10/2/15
to jenkinsc...@googlegroups.com
Mark Waite edited a comment on Bug JENKINS-20879
Steps I took to confirm it was working on my existing Ubuntu 14.04 x64
master (previously using git client plugin 1.18.0, then git client
plugin 1.19.0, and now using an unreleased version of the git client
plugin that is adding submodule authentication):

# Create a new user "hasphrase"
# Login as user "hasphrase"
# Generate passphrase protected private key
# Create a private git repo for that user at /var/lib/git/hasphrase/bin.git
# Confirm other system users cannot clone that repo
# Create multi-configuration Jenkins job attempting to use that repo, use Elastic Axis plugin and Platform Labeler plugin to run job on "windows || linux || freebsd", restrict polling to only run from linux machines
# Confirm Jenkins job cannot read the repo (exception polling, exception building)
# Define Jenkins credential with private key and passphrase of user "hasphrase"
# Modify Jenkins job to use that newly defined credential
# Confirm job can read the repo (no exception polling, linux and freebsd slaves succeed, windows slaves fail)

Steps I took to confirm it failed on a freshly constructed Docker
instance (using git client plugin 1.19.0 and git plugin 2.4.0):

# Run my [master-with-plugins Docker instance]()
# Define job attempting to use that repo
# Confirm job cannot read the repo (no credential defined)
# Define the DISPLAY environment variable for Jenkins system-wide
# Try unreleased git client plugin on Docker instance
# Review createSshKeyFile null pointer exception
# Implement passphrase protected private key test in CredentialsTest

dejay@dejayclayton.com (JIRA)

unread,
Oct 2, 2015, 3:30:03 PM10/2/15
to jenkinsc...@googlegroups.com

Mark,

Sorry for the extra work. I was following your lead, since you've duplicated your previous comment across all three open tickets. Might it make sense to close two of those tickets as duplicates?

Now I'm very confused. I've done extensive testing on one of my Jenkins instances, and the other instance I've left completely alone. Both Jenkins instances now work when connecting to GitHub with password-protected private keys, whereas yesterday, neither did. One instance is running git-client 1.17, and the other is running 1.19.

GitHub support staff proclaims that they've made no changes on their end; thus, I have no explanation for the behavior I've seen yesterday. However, now that I've followed your troubleshooting steps to verify that password-protected keys work fine with both local server paths as well as SSH paths to remote hosts, I'll definitely run those steps again if I ever see connectivity problems regarding GitHub specifically.

mark.earl.waite@gmail.com (JIRA)

unread,
Oct 3, 2015, 8:29:03 AM10/3/15
to jenkinsc...@googlegroups.com

Dejay Clayton Thanks for reporting your further results. I'm glad it started working for you. I suspect there may be some ordering dependencies which are made visible on the first connection between a slave and the ssh process of the server repository. At least that's why I think my Docker instance fails and my main Ubuntu machine succeeds. My main Ubuntu machine has already communicated with the ssh daemon on each of my internal slaves that I use for tests, while the Docker instance is seeing the ssh connection for the very first time.

I won't be able to investigate further this weekend, but hope to continue studying this further in the future.

yinzehong@qq.com (JIRA)

unread,
Oct 12, 2015, 9:24:02 PM10/12/15
to jenkinsc...@googlegroups.com

I have the same issue only when job run on slave, the Swarm plugin will show "Enter passphrase for key '/tmp/ssh6736030097350101131key'".

Jenkins : 1.6.32, git-client-plugin 1.19

mbidewel@gmail.com (JIRA)

unread,
Oct 27, 2015, 8:02:01 PM10/27/15
to jenkinsc...@googlegroups.com

If I have an SSH key with a passphrase, I get a request for the passphrase using the Git or SSH-Agent plugin on a slave. JGit works fine and the key works fine on the master.

sherpapsy@gmail.com (JIRA)

unread,
Jan 26, 2016, 11:21:03 AM1/26/16
to jenkinsc...@googlegroups.com

I was having a heck of a time using a passphrase protected key with git in Jenkins. I had an exact mirror of our production server on a VM and it worked fine, on the production box I could ssh and use git from the command line with the key and passphrase, but in Jenkins job config, I was getting output that was the same as if I had entered incorrect passphrase on the command line.

The only difference between two systems was that the passphrase on the production system had a $ in it. No other symbols, just characters and numbers and a $.

I created a new key with no symbols in the passphrase, and it works fine.

There appears to be a bug (or limitation) in Jenkins or the SSH/Git plugins where a passphrase containing a $ does not work.

I'm wondering if I should open this as a bug, not sure its affecting the person having problems here?

Cheers!

nfalco79@hotmail.com (JIRA)

unread,
Feb 8, 2016, 10:30:07 AM2/8/16
to jenkinsc...@googlegroups.com

Same problem here.
Jenkins 1.625.3
SSH Agent Plugin 1.9
SSH Credentials Plugin 1.11

I configure a GIT as SCM to our internal git server (based on gitolite). The configured credential use ssh key.
If the jenkins credential key does have a passphrase authentication work and I could download repo. If I past a ssh key passphrase and configure it then I got an error:

ERROR: Error fetching remote repo 'origin'
hudson.plugins.git.GitException: Failed to fetch from ssh://r...@git.example.com/myrepo.git
	at hudson.plugins.git.GitSCM.fetchFrom(GitSCM.java:763)
	at hudson.plugins.git.GitSCM.retrieveChanges(GitSCM.java:1012)
	at hudson.plugins.git.GitSCM.checkout(GitSCM.java:1043)
	at hudson.scm.SCM.checkout(SCM.java:485)
	at hudson.model.AbstractProject.checkout(AbstractProject.java:1275)
	at hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:610)
	at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:86)
	at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:532)
	at hudson.model.Run.execute(Run.java:1741)
	at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43)
	at hudson.model.ResourceController.execute(ResourceController.java:98)
	at hudson.model.Executor.run(Executor.java:408)
Caused by: hudson.plugins.git.GitException: Command "git fetch --tags --progress ssh://r...@git.example.com/myrepo.git +refs/heads/*:refs/remotes/origin/*" returned status code 128:
stdout: 
stderr: Permission denied (publickey).
fatal: The remote end hung up unexpectedly
	at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:1710)
	at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandWithCredentials(CliGitAPIImpl.java:1454)
	at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.access$300(CliGitAPIImpl.java:63)
	at org.jenkinsci.plugins.gitclient.CliGitAPIImpl$1.execute(CliGitAPIImpl.java:314)
	at hudson.plugins.git.GitSCM.fetchFrom(GitSCM.java:761)

mark.earl.waite@gmail.com (JIRA)

unread,
Feb 10, 2016, 12:52:07 AM2/10/16
to jenkinsc...@googlegroups.com

My attempts to create a case which will use a passphrase protected credential have consistently failed. I still don't know how others are able to use passphrase protected private keys but I am not. I add the private key as a credential, I enter the passphrase into the credential, and it does not authenticate. I even attempted installing the ssh-agent plugin and then tried enabling it for one job. Still no luck.

JENKINS-32834 includes a report from one user that a change made in git client plugin 1.19.3 broke passphrase handling for him. I reverted the problem change and released it as git client plugin 1.19.4. There definitely are users who are able to use passphrase protected rsa private keys. I'm not one of them.

mark.earl.waite@gmail.com (JIRA)

unread,
Feb 10, 2016, 1:07:01 AM2/10/16
to jenkinsc...@googlegroups.com
Mark Waite edited a comment on Bug JENKINS-20879
My attempts to create a case which will use a passphrase protected credential have consistently failed.  I still don't know how others are able to use passphrase protected private keys but I am not.  I add the private key as a credential, I enter the passphrase into the credential, and it does not authenticate.  I even attempted installing the ssh-agent plugin and then tried enabling it for one job.  Still no luck.

JENKINS-32834 includes a report from one user that a change made in git client plugin 1.19.3 broke passphrase handling for him.  I reverted the problem change and released it as git client plugin 1.19.4.  There definitely are users who are able to use passphrase protected rsa private keys. I'm not one of them.


I was able to create a job which uses a password protected private key so long as I use JGit as the git implementation.  The same job definition fails when I use command line git.

mark.earl.waite@gmail.com (JIRA)

unread,
Feb 10, 2016, 1:26:05 AM2/10/16
to jenkinsc...@googlegroups.com
Mark Waite edited a comment on Bug JENKINS-20879
My attempts to create a case which will use a passphrase protected credential have consistently failed  with command line git .  I still don't know how others are able to use passphrase protected private keys  with command line git,  but I am not.  I add the private key as a credential, I enter the passphrase into the credential, and it does not authenticate.  I even attempted installing the ssh-agent plugin and then tried enabling it for one job.  Still no luck.

JENKINS-32834 includes a report from one user that a change made in git client plugin 1.19.3 broke passphrase handling for him  (BatchMode=yes was added to the ssh arguments) .  I reverted the problem change and released it as git client plugin 1.19.4.  There definitely are users who are able to use passphrase protected rsa private keys. I'm not one of them.


I was able to create a job which uses a password protected private key so long as I use JGit as the git implementation.  The same job definition fails when I use command line git.

argrico@gmail.com (JIRA)

unread,
Feb 10, 2016, 2:51:03 AM2/10/16
to jenkinsc...@googlegroups.com
Alberto Gallardo updated an issue
 
Change By: Alberto Gallardo
Attachment: CredentialsConfig-fileOnJenkins.png

argrico@gmail.com (JIRA)

unread,
Feb 10, 2016, 2:56:04 AM2/10/16
to jenkinsc...@googlegroups.com
Alberto Gallardo commented on Bug JENKINS-20879
 
Re: SSH Credentials (private key with passphrase) do not work

I'm the reporter of

JENKINS-32834 . I'm using a file on Jenkins as private key. See . Credentials work independently of configured username.

argrico@gmail.com (JIRA)

unread,
Feb 10, 2016, 3:02:00 AM2/10/16
to jenkinsc...@googlegroups.com
Alberto Gallardo edited a comment on Bug JENKINS-20879
I'm the reporter of [JENKINS-32834]. I'm using a file on Jenkins as private key . See :

  !CredentialsConfig-fileOnJenkins.png|thumbnail! .

Note:  Credentials work independently of configured username.

Environment:
Jenkins ver. 1647
on jetty-winstone-2.9
Java oracle jdk1.7.0_79
Git: 2.4.2
Git Client: 1.19.4
ssh-credentials: 1.11

argrico@gmail.com (JIRA)

unread,
Feb 10, 2016, 3:23:04 AM2/10/16
to jenkinsc...@googlegroups.com

I still don't know how others are able to use passphrase protected private keys with command line git, but I am not. I add the private key as a credential, I enter the passphrase into the credential, and it does not authenticate.

Mark Waite

What do you mean with "command line git"? For each of the GitHub repositories I have configured, I need a different ssh key. I have followed the GitHub instructions to generate the keys, with a subtle difference: as I need different keys, I create different files:

# (In jenkins)
$sudo su -s /bin/bash - jenkins
$ssh-keygen -t rsa -b 4096 -C "tests.jenkins@ci" -f ~/.ssh/jenkins.tests.id_rsa
# Should ask for a password

I test the connection:

$ssh-agent bash -c 'ssh-add ~/.ssh/jenkins.tests.id_rsa; git -c core.askpass=true ls-remote ssh://git@github..../.../tests.git'
# Should ask for the password

This should list the remotes:

09631f7054adb54221cb3a5736c8605a36c0ad79	HEAD
174f469223c8787fcb161f34c5219d0f3df945fc	refs/heads/patch-1
09631f7054adb54221cb3a5736c8605a36c0ad79	refs/heads/test1
174f469223c8787fcb161f34c5219d0f3df945fc	refs/pull/2/head
57d3cf7fc2a2908fe1907372921a71110fb0de38	refs/pull/2/merge

Afterwards, it's only adding new credentials as shown in previous comment.

mark.earl.waite@gmail.com (JIRA)

unread,
Feb 10, 2016, 3:48:06 PM2/10/16
to jenkinsc...@googlegroups.com

What do you mean with "command line git"?

I'm able to configure and successfully run a project which uses an RSA private key which requires a passphrase, if I use the JGIt implementation. I have not been able to successfully run a project using an RSA private key which requires a passphrase if I use the command line git (default) implementation.

argrico@gmail.com (JIRA)

unread,
Feb 11, 2016, 7:28:05 AM2/11/16
to jenkinsc...@googlegroups.com

I have to admit that I wasn't familiarized with all these plugins until yesterday. After taking a look at the doc for the Git Plugin I understand your point.

First of all, my jenkins runs a git 1.7.12.4. Now, I have added some logs and dug a bit more into the git-client guts, and am even more clueless than before: it looks as if jenkins

1. set GIT_SSH=/tmp/ssh12345678901234567890.sh and SSH_ASKPASS=/tmp/pass12345678901234567890.sh to respective tmp files:

/tmp/ssh12345678901234567890.sh 
#!/bin/sh
if [ -z "${DISPLAY}" ]; then
  DISPLAY=:123.456
  export DISPLAY
fi
ssh -i "/tmp/ssh12345678901234567890key" -l "jenkins" -o StrictHostKeyChecking=no "$@"
/tmp/pass12345678901234567890 
#!/bin/sh
/bin/echo "mySecretPassword"

2. and then executed

git -c core.askpass=true ls-remote -h g...@github.mygithubserver.org:USER/tests.git HEAD # timeout=10

3. what results in git invoking

ssh -i /var/lib/jenkins/.ssh/tests.id_rsa -o StrictHostKeyChecking=no g...@github.mygithubserver.org 'git-upload-pack '\''/USER/tests.git'\'''

And this, when invoked from the command line, prompts for the test.id_rsa password, because ssh (and not git) wants to use the key. So the question is: how could this even work if the SSH_ASKPASS is never used?

I'll investigate a bit more and will report.

argrico@gmail.com (JIRA)

unread,
Feb 11, 2016, 7:35:03 AM2/11/16
to jenkinsc...@googlegroups.com

By the way, according to the git-scm book, SSH_ASKPASS is overriden by core.askpass=true.

argrico@gmail.com (JIRA)

unread,
Feb 11, 2016, 7:52:02 AM2/11/16
to jenkinsc...@googlegroups.com
Alberto Gallardo edited a comment on Bug JENKINS-20879
I have to admit that I wasn't familiarized with all these plugins until yesterday. After taking a look at the [doc for the Git Plugin|https://wiki.jenkins-ci.org/display/JENKINS/Git+Plugin#GitPlugin-WhyNotJGit] I understand your point.


First of all, my jenkins runs a git 1.7.12.4. Now, I have added some logs and dug a bit more into the git-client guts, and am even more clueless than before: it looks as if jenkins

1. set {{GIT_SSH=/tmp/ssh12345678901234567890.sh}} and {{SSH_ASKPASS=/tmp/pass12345678901234567890.sh}} to respective tmp files:
{noformat:title=/tmp/ssh12345678901234567890.sh}

#!/bin/sh
if [ -z "${DISPLAY}" ]; then
  DISPLAY=:123.456
  export DISPLAY
fi
ssh -i "/tmp/ssh12345678901234567890key" -l "jenkins" -o StrictHostKeyChecking=no "$@"
{noformat}
{noformat:title=/tmp/pass12345678901234567890}
#!/bin/sh
/bin/echo "mySecretPassword"
{noformat}

2. and then executed
{noformat}

git -c core.askpass=true ls-remote -h g...@github.mygithubserver.org:USER/tests.git HEAD # timeout=10
{noformat}


3. what results in git invoking
{noformat}

ssh -i /var/lib/jenkins/.ssh/tests.id_rsa -o StrictHostKeyChecking=no g...@github.mygithubserver.org 'git-upload-pack '\''/USER/tests.git'\'''
{noformat}

 - And this, when invoked from the command line, prompts for the {{test.id_rsa}} password, because {{ssh}} (and not {{git}}) wants to use the key. So the question is: how could this even work if the {{SSH_ASKPASS}} is never used? -

I  don ' ll investigate a bit more t know why, but my assumption about the password promt is wrong: jenkins manages somehow to invoke {{git -c core.askpass=...}},  and  will report  this in turn successfully invokes both the ssh and the pass scripts .  But I cannot get this working in a terminal (!).

argrico@gmail.com (JIRA)

unread,
Feb 11, 2016, 10:32:08 AM2/11/16
to jenkinsc...@googlegroups.com

After a few hours I could make it work from the console. A post in stackexchange pointed me in the right direction: my fault was to not realize that jenkins executes the commands without attached terminal.

If ssh needs a passphrase, it will read the passphrase from the current terminal if it was run from a terminal. If ssh does not have a terminal associated with it but DISPLAY and SSH_ASKPASS are set, it will execute the program specified by SSH_ASKPASS

@Mark Waite I could reproduce jenkins behaviour from the linux console adding setsid to the ssh invokation in GIT_SSH:

/tmp/ssh12345678901234567890.sh 
#!/bin/sh
if [ -z "${DISPLAY}" ]; then
  DISPLAY=:123.456
  export DISPLAY
fi
# setsid: create a new session dettached from the console
setsid ssh -i "/tmp/ssh12345678901234567890key" -l "jenkins" -o StrictHostKeyChecking=no "$@"

I can also confirm that the -c core.askpass=true git config is unnecessary.

harel.e@gmail.com (JIRA)

unread,
Aug 16, 2016, 2:35:03 AM8/16/16
to jenkinsc...@googlegroups.com
Harel E. commented on Bug JENKINS-20879

I had similar issue and ssh credentials. After several passphrase tests it boiled down to the $ sign.
passphrase that contained the $ sign didn't work.

Hope that helps.

Harel
This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c)
Atlassian logo

mark.earl.waite@gmail.com (JIRA)

unread,
Aug 16, 2016, 9:07:02 AM8/16/16
to jenkinsc...@googlegroups.com

Harel E. thanks for the report. It is quite valuable to know which passphrase characters have shown problems for users. I've included a passphrase with a $ sign in my test data creation script. I'll include that in the verification of any changes to the passphrase support in the git plugin and the git client plugin.

konecny.mike@gmail.com (JIRA)

unread,
Aug 16, 2016, 9:21:07 AM8/16/16
to jenkinsc...@googlegroups.com

For me, the passphrase only contained lowercase alphabetical characters, but still didn't work.

stephen.alan.connolly@gmail.com (JIRA)

unread,
Oct 20, 2016, 11:39:03 AM10/20/16
to jenkinsc...@googlegroups.com

Mark Waite

Have you made any progress on not sending Credentials instances over to remote agents

https://github.com/jenkinsci/git-plugin/blob/master/src/main/java/hudson/plugins/git/GitSCM.java#L736

mark.earl.waite@gmail.com (JIRA)

unread,
Oct 20, 2016, 11:50:04 AM10/20/16
to jenkinsc...@googlegroups.com

Stephen Connolly I have not made any progress on JENKINS-37899 or not sending credentials instances to remote agents. I'm unlikely to make any short term progress on it because I want to resolve the authentication failures in git plugin 3.0 (JENKINS-38138, JENKINS-38179, JENKINS-38194) and the submodule failures in git plugin 3.0 (JENKINS-37495).

hellomind@gmail.com (JIRA)

unread,
Mar 22, 2017, 9:06:02 PM3/22/17
to jenkinsc...@googlegroups.com

Tip: if running Jenkins inside of Docker container, don't provide -it flags, otherwise Jenkins will think it's run from a terminal and start asking for passphrase instead of using the one provided in Credentials settings.
This message was sent by Atlassian JIRA (v7.3.0#73011-sha1:3c73d0e)
Atlassian logo

mark.earl.waite@gmail.com (JIRA)

unread,
Mar 22, 2017, 9:27:02 PM3/22/17
to jenkinsc...@googlegroups.com

That's a good suggestion, though I really intend that the plugin will never prompt for a passphrase, where run with a controlling terminal or not.

mark.earl.waite@gmail.com (JIRA)

unread,
Aug 20, 2018, 8:59:03 PM8/20/18
to jenkinsc...@googlegroups.com
Mark Waite closed an issue as Fixed
 
Change By: Mark Waite
Status: Resolved Closed
This message was sent by Atlassian JIRA (v7.10.1#710002-sha1:6efc396)
Reply all
Reply to author
Forward
0 new messages