Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-27998

Git plugin fails to clone with ssh protected passphrase

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Resolved (View Workflow)
    • Priority: Major
    • Resolution: Duplicate
    • Component/s: git-plugin
    • Labels:
      None
    • Environment:
      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
    • Similar Issues:

      Description

      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.

        Attachments

          Issue Links

            Activity

            Hide
            markewaite Mark Waite added a comment -

            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.

            Show
            markewaite Mark Waite added a comment - 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.
            Hide
            jamie Jamie Doornbos added a comment -

            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.

            Show
            jamie Jamie Doornbos added a comment - 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.
            Hide
            markewaite Mark Waite added a comment - - edited

            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.

            Show
            markewaite Mark Waite added a comment - - edited 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.
            Hide
            markewaite Mark Waite added a comment -

            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.

            Show
            markewaite Mark Waite added a comment - 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.
            Hide
            markewaite Mark Waite added a comment -

            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.

            Show
            markewaite Mark Waite added a comment - 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.
            Hide
            dejayc 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.

            Show
            dejayc 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.
            Hide
            markewaite Mark Waite added a comment -

            Dejay Clayton comments on his investigation are in JENKINS-20879

            Show
            markewaite Mark Waite added a comment - Dejay Clayton comments on his investigation are in JENKINS-20879

              People

              • Assignee:
                ndeloof Nicolas De Loof
                Reporter:
                jamie Jamie Doornbos
              • Votes:
                0 Vote for this issue
                Watchers:
                4 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: