I have an OS X slave.

      The Jenkins job is configured to connect to the git repository using a private key.

      Most of the times when fetching git changes the GIT_SSH is used:

      [EnvInject] - Loading node environment variables.
      Building remotely on MobileDaily in workspace /opt/dailybuild/jenkins/workspace/Dev MerchantApp iOS
       > git rev-parse --is-inside-work-tree # timeout=10
      Fetching changes from the remote Git repository
       > git config remote.origin.url git@bitbucket.org:vo/demo-merchant-ios.git # timeout=10
      Fetching upstream changes from git@bitbucket.org:vo/demo-merchant-ios.git
       > git --version # timeout=10
      using GIT_SSH to set credentials
       > git fetch --tags --progress git@bitbucket.org:vo/demo-merchant-ios.git +refs/heads/*:refs/remotes/origin/*
      

      But after some time, it is not used anymore, and git fetching fails:

      [EnvInject] - Loading node environment variables.
      Building remotely on MobileDaily in workspace /opt/dailybuild/jenkins/workspace/Dev MerchantApp iOS
       > git rev-parse --is-inside-work-tree # timeout=10
      Fetching changes from the remote Git repository
       > git config remote.origin.url git@bitbucket.org:vo/demo-merchant-ios.git # timeout=10
      Cleaning workspace
       > git rev-parse --verify HEAD # timeout=10
      Resetting working tree
       > git reset --hard # timeout=10
       > git clean -fdx # timeout=10
      Fetching upstream changes from git@bitbucket.org:vo/demo-merchant-ios.git
       > git --version # timeout=10
       > git fetch --tags --progress git@bitbucket.org:vo/demo-merchant-ios.git +refs/heads/*:refs/remotes/origin/*
      FATAL: Failed to fetch from git@bitbucket.org:vo/demo-merchant-ios.git
      hudson.plugins.git.GitException: Failed to fetch from git@bitbucket.org:vo/demo-merchant-ios.git
      	at hudson.plugins.git.GitSCM.fetchFrom(GitSCM.java:627)
      	at hudson.plugins.git.GitSCM.retrieveChanges(GitSCM.java:865)
      	at hudson.plugins.git.GitSCM.checkout(GitSCM.java:890)
      	at hudson.model.AbstractProject.checkout(AbstractProject.java:1411)
      	at hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:652)
      	at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:88)
      	at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:561)
      	at hudson.model.Run.execute(Run.java:1665)
      	at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46)
      	at hudson.model.ResourceController.execute(ResourceController.java:88)
      	at hudson.model.Executor.run(Executor.java:246)
      Caused by: hudson.plugins.git.GitException: Command "git fetch --tags --progress git@bitbucket.org:vo/demo-merchant-ios.git +refs/heads/*:refs/remotes/origin/*" returned status code 128:
      stdout: 
      stderr: Permission denied (publickey).
      fatal: Could not read from remote repository.
      
      Please make sure you have the correct access rights
      and the repository exists.
      
      	at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:1437)
      	at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandWithCredentials(CliGitAPIImpl.java:1225)
      	at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.access$300(CliGitAPIImpl.java:87)
      	at org.jenkinsci.plugins.gitclient.CliGitAPIImpl$1.execute(CliGitAPIImpl.java:282)
      	at org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler$1.call(RemoteGitImpl.java:153)
      	at org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler$1.call(RemoteGitImpl.java:146)
      	at hudson.remoting.UserRequest.perform(UserRequest.java:118)
      	at hudson.remoting.UserRequest.perform(UserRequest.java:48)
      	at hudson.remoting.Request$2.run(Request.java:328)
      	at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72)
      	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
      	at java.util.concurrent.FutureTask.run(FutureTask.java:166)
      	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
      	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
      	at java.lang.Thread.run(Thread.java:724)
      
      

      The only solution I have found is:
      Disconnecting and reconnecting the Slave.
      Most of the times it helps, but not always.

          [JENKINS-25172] GIT_SSH not always used for git fetch

          Mark Waite added a comment -

          Can you provide any further isolation of the problem?

          For example, does it only happen with bitbucket URLs, or does it also happen with other secured URLs?

          What Java version are you running on the master?

          What Java version are you running on the slave?

          Can you duplicate the problem on any other operating system besides OS X?

          Are there cases where the problem does not occur, and if so, are there interesting or surprising differences between the failure modes and the success cases?

          Mark Waite added a comment - Can you provide any further isolation of the problem? For example, does it only happen with bitbucket URLs, or does it also happen with other secured URLs? What Java version are you running on the master? What Java version are you running on the slave? Can you duplicate the problem on any other operating system besides OS X? Are there cases where the problem does not occur, and if so, are there interesting or surprising differences between the failure modes and the success cases?

          Master:
          Windows OS

          Jenkins 1.532.3
          Java 1.7.0_25
          git plugin 2.2.5
          git client plugin 1.10.2

          Salve:
          Mac OS X 10.9.5
          Java 1.7.0_25-b15
          SSH connection

          > For example, does it only happen with bitbucket URLs, or does it also happen with other secured URLs?
          It happened and with other providers.

          > Can you duplicate the problem on any other operating system besides OS X?
          No, but I configured a job to run on a windows slave, it will use the same repository. I will monitor it.

          > Are there cases where the problem does not occur, and if so, are there interesting or surprising differences between the failure modes and the success cases?
          The only difference I noticed is that when it fails the message "using GIT_SSH to set credentials" is not present in the logs.

          Nicolae Ghimbovschi added a comment - Master: Windows OS Jenkins 1.532.3 Java 1.7.0_25 git plugin 2.2.5 git client plugin 1.10.2 Salve: Mac OS X 10.9.5 Java 1.7.0_25-b15 SSH connection > For example, does it only happen with bitbucket URLs, or does it also happen with other secured URLs? It happened and with other providers. > Can you duplicate the problem on any other operating system besides OS X? No, but I configured a job to run on a windows slave, it will use the same repository. I will monitor it. > Are there cases where the problem does not occur, and if so, are there interesting or surprising differences between the failure modes and the success cases? The only difference I noticed is that when it fails the message "using GIT_SSH to set credentials" is not present in the logs.

          I seem to have a similar problem. The plugin seems to fail to use GIT_SSH when a "Recursively update submodules" is used. So basically, the parent module is checked out correctly then I get the following failure for for submodule checkout. Note I can use hte plugin to directly check the submodule out (hence the crednetials are correct) :
          > /usr/bin/git submodule update --init --recursive
          FATAL: Command "/usr/bin/git submodule update --init --recursive" returned status code 1:
          stdout: Initialized empty Git repository in /export/Apps/srater_recognizer.15.1/SRaterHome/SRater/ASR_Files/files/ELTeach/expunct/.git/

          ...
          stderr: Permission denied (publickey).
          fatal: The remote end hung up unexpectedly
          Clone of 'ssh://git@xxx:7999/foo/bar.git' into submodule path 'Foo/bar' failed

          hudson.plugins.git.GitException: Command "/usr/bin/git submodule update --init --recursive" returned status code 1:
          stdout: Initialized empty Git repository in /somewhere/.git/

          stderr: Permission denied (publickey).
          fatal: The remote end hung up unexpectedly
          Clone of 'ssh://git@xxx:7999/foo/bar.git' into submodule path 'Foo/bar' failed

          robert mundkowsky added a comment - I seem to have a similar problem. The plugin seems to fail to use GIT_SSH when a "Recursively update submodules" is used. So basically, the parent module is checked out correctly then I get the following failure for for submodule checkout. Note I can use hte plugin to directly check the submodule out (hence the crednetials are correct) : > /usr/bin/git submodule update --init --recursive FATAL: Command "/usr/bin/git submodule update --init --recursive" returned status code 1: stdout: Initialized empty Git repository in /export/Apps/srater_recognizer.15.1/SRaterHome/SRater/ASR_Files/files/ELTeach/expunct/.git/ ... stderr: Permission denied (publickey). fatal: The remote end hung up unexpectedly Clone of 'ssh://git@xxx:7999/foo/bar.git' into submodule path 'Foo/bar' failed hudson.plugins.git.GitException: Command "/usr/bin/git submodule update --init --recursive" returned status code 1: stdout: Initialized empty Git repository in /somewhere/.git/ stderr: Permission denied (publickey). fatal: The remote end hung up unexpectedly Clone of 'ssh://git@xxx:7999/foo/bar.git' into submodule path 'Foo/bar' failed

          Mark Waite added a comment - - edited

          rmundkowsky I think your case is more like JENKINS-20941. I interpreted this bug report as not involving submodules, and failing sometimes when it passed at other times. The case you're describing is that submodules never use credentials to perform their update. That is described in JENKINS-20941 (and as far as I know, is still a bug or a known limitation).

          Mark Waite added a comment - - edited rmundkowsky I think your case is more like JENKINS-20941 . I interpreted this bug report as not involving submodules, and failing sometimes when it passed at other times. The case you're describing is that submodules never use credentials to perform their update. That is described in JENKINS-20941 (and as far as I know, is still a bug or a known limitation).

          robert mundkowsky added a comment - - edited

          I agree, JENKINS-20941 is closer match for the error I am seeing. I would note, that I thought they had fixed JENKINS-20941 since there was a Pull Request, but after reading the Pull Request, seems the fix was not complete.

          robert mundkowsky added a comment - - edited I agree, JENKINS-20941 is closer match for the error I am seeing. I would note, that I thought they had fixed JENKINS-20941 since there was a Pull Request, but after reading the Pull Request, seems the fix was not complete.

          With the latest LTS jenkins this does not happen any more. I'll close this bug.

          Nicolae Ghimbovschi added a comment - With the latest LTS jenkins this does not happen any more. I'll close this bug.

          It is does not reproduce in the latest LTS jenkins

          Nicolae Ghimbovschi added a comment - It is does not reproduce in the latest LTS jenkins

          which LTS version corrects this?

          robert mundkowsky added a comment - which LTS version corrects this?

          Jenkins ver. 1.580.1

          Nicolae Ghimbovschi added a comment - Jenkins ver. 1.580.1

          thanks! I just tried Jenkins 1.591 with Git Plugin 2.2.6 and it works.

          robert mundkowsky added a comment - thanks! I just tried Jenkins 1.591 with Git Plugin 2.2.6 and it works.

            ndeloof Nicolas De Loof
            xfreebird Nicolae Ghimbovschi
            Votes:
            1 Vote for this issue
            Watchers:
            5 Start watching this issue

              Created:
              Updated:
              Resolved: