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

ssh-agent ssh keys override git SCM ssh keys with same username

      When using different SSH keys (even with the same username, like git) with multiple repos, then the correct key is used for corresponding repo and everything works fine.

       

      If the username of the SSH key (key 1) used in Git SCM checkout matches the username of the SSH key (key 2) used in ssh-agent, git checkout gets broken.

      When one removes SSH key (key 2) with same username from ssh-agent, git checkouts work.

       

      This is the error first scenario renders:

      08:57:55 Cloning the remote Git repository
      08:57:55 Cloning repository git@github.com:example/my-super-repo.git
      08:57:55  > git init /home/jenkins/jenkins_root/workspace/my-super-repo-deploy # timeout=10
      08:57:55 Fetching upstream changes from git@github.com:example/my-super-repo.git
      08:57:55  > git --version # timeout=10
      08:57:55 using GIT_SSH to set credentials jenkins/my-super-repo
      08:57:55  > git fetch --tags --progress git@github.com:example/my-super-repo.git +refs/heads/:refs/remotes/origin/
      08:57:56 ERROR: Error cloning remote repo 'origin'
      08:57:56 hudson.plugins.git.GitException: Command "git fetch --tags --progress git@github.com:example/my-super-repo.git +refs/heads/:refs/remotes/origin/" returned status code 128:
      08:57:56 stdout:
      08:57:56 stderr: ERROR: Repository not found.
      08:57:56 fatal: Could not read from remote repository.
      08:57:56
      08:57:56 Please make sure you have the correct access rights
      08:57:56 and the repository exists.
      08:57:56
      08:57:56        at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:1903)
      08:57:56        at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandWithCredentials(CliGitAPIImpl.java:1622)
      08:57:56        at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.access$300(CliGitAPIImpl.java:71)
      08:57:56        at org.jenkinsci.plugins.gitclient.CliGitAPIImpl$1.execute(CliGitAPIImpl.java:348)
      08:57:56        at org.jenkinsci.plugins.gitclient.CliGitAPIImpl$2.execute(CliGitAPIImpl.java:545)
      08:57:56        at org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler$1.call(RemoteGitImpl.java:153)
      08:57:56        at org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler$1.call(RemoteGitImpl.java:146)
      08:57:56        at hudson.remoting.UserRequest.perform(UserRequest.java:181)
      08:57:56        at hudson.remoting.UserRequest.perform(UserRequest.java:52)
      08:57:56        at hudson.remoting.Request$2.run(Request.java:336)
      08:57:56        at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:68)
      08:57:56        at java.util.concurrent.FutureTask.run(FutureTask.java:266)
      08:57:56        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
      08:57:56        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
      08:57:56        at java.lang.Thread.run(Thread.java:745)
      08:57:56        at ......remote call to jenkins-slave01-test(Native Method)
      08:57:56        at hudson.remoting.Channel.attachCallSiteStackTrace(Channel.java:1554)
      08:57:56        at hudson.remoting.UserResponse.retrieve(UserRequest.java:281)
      08:57:56        at hudson.remoting.Channel.call(Channel.java:839)
      08:57:56        at org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler.execute(RemoteGitImpl.java:146)
      08:57:56        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
      08:57:56        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
      08:57:56        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
      08:57:56        at java.lang.reflect.Method.invoke(Method.java:498)
      08:57:56        at org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler.invoke(RemoteGitImpl.java:132)
      08:57:56        at com.sun.proxy.$Proxy127.execute(Unknown Source)
      08:57:56        at hudson.plugins.git.GitSCM.retrieveChanges(GitSCM.java:1070)
      08:57:56        at hudson.plugins.git.GitSCM.checkout(GitSCM.java:1110)
      08:57:56        at hudson.scm.SCM.checkout(SCM.java:495)
      08:57:56        at hudson.model.AbstractProject.checkout(AbstractProject.java:1212)
      08:57:56        at hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:566)
      08:57:56        at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:86)
      08:57:56        at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:491)
      08:57:56        at hudson.model.Run.execute(Run.java:1737)
      08:57:56        at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43)
      08:57:56        at hudson.model.ResourceController.execute(ResourceController.java:97)
      08:57:56        at hudson.model.Executor.run(Executor.java:419)
      

       

      I presume that ssh-agent somehow screws up git SCM plugin credentials.

      Since github uses hardcoded username "git" for every github repo, this causes a problem if you need ssh-agent to log in to git@oneof.yourservers.com ...

          [JENKINS-47261] ssh-agent ssh keys override git SCM ssh keys with same username

          Mark Waite added a comment -

          I believe this is the intended behavior.  If ssh agent is being used, it should override the keys.

          Mark Waite added a comment - I believe this is the intended behavior.  If ssh agent is being used, it should override the keys.

          Jakov Sosic added a comment -

          markewaite but that doesn't make much sense. Why do the usernames collide if we specifically select which key should be used for checkout for a certain repo?

           

          Also, job config screen doesn't show error being unable to contact git repo - so, at least the config screen is using the correct key in this case.

          Jakov Sosic added a comment - markewaite but that doesn't make much sense. Why do the usernames collide if we specifically select which key should be used for checkout for a certain repo?   Also, job config screen doesn't show error being unable to contact git repo - so, at least the config screen is using the correct key in this case.

          Mark Waite added a comment -

          I believe that once ssh-agent is invoked, it places variables into the environment which tell later ssh processes to consult the ssh agent for keys.  Command line git uses an ssh process and that ssh process honors the settings of ssh-agent.

          I believe that the config screen is running in the context of the Jenknis process on the master, while the git checkout is running in the context of the workspace on the agent performing the build.

          I think you're correct that it is a bug, since your expectations of behavior were not met and the job behavior is inconsistent with the configuration screen behavior.  Either of those would be enough to persuade me it is a bug.  It is not a bug I intend to fix, but it is a bug.

          Mark Waite added a comment - I believe that once ssh-agent is invoked, it places variables into the environment which tell later ssh processes to consult the ssh agent for keys.  Command line git uses an ssh process and that ssh process honors the settings of ssh-agent. I believe that the config screen is running in the context of the Jenknis process on the master, while the git checkout is running in the context of the workspace on the agent performing the build. I think you're correct that it is a bug, since your expectations of behavior were not met and the job behavior is inconsistent with the configuration screen behavior.  Either of those would be enough to persuade me it is a bug.  It is not a bug I intend to fix, but it is a bug.

            Unassigned Unassigned
            jsosic Jakov Sosic
            Votes:
            1 Vote for this issue
            Watchers:
            3 Start watching this issue

              Created:
              Updated: