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

Wrong username used for git clone with OpenSSH 7.7

XMLWordPrintable

    • Icon: Bug Bug
    • Resolution: Fixed
    • Icon: Blocker Blocker
    • git-plugin
    • None
    • Windows
      Git 2.17 (specifically) from chocolatey

      Windows VMs, Alpine Linux docker images, Debian Buster ("testing"), macOS 10.13.6, and OpenBSD 6.3 installations which use OpenSSH 7.7 (on Windows as part of Git on Windows 2.17 and Git on Windows 2.18) use the wrong username when cloning git repos with ssh (private key authentication). They're using jenkins when git is explicitly specified.

      dir("dist-utils") {
    git credentialsId: 'ssh-id-rsa', url: 'ssh://git@github.com/zeroc-ice/dist-utils.git'
}
       > git rev-parse --is-inside-work-tree # timeout=10
Fetching changes from the remote Git repository
 > git config remote.origin.url ssh://git@github.com/zeroc-ice/dist-utils.git # timeout=10
Fetching upstream changes from ssh://git@github.com/zeroc-ice/dist-utils.git
 > git --version # timeout=10
using GIT_SSH to set credentials Jenkins SSH RSA Key 
 > git fetch --tags --progress ssh://git@github.com/zeroc-ice/dist-utils.git +refs/heads/*:refs/remotes/origin/*
ERROR: Error fetching remote repo 'origin'
hudson.plugins.git.GitException: Failed to fetch from ssh://git@github.com/zeroc-ice/dist-utils.git
	at hudson.plugins.git.GitSCM.fetchFrom(GitSCM.java:862)
	at hudson.plugins.git.GitSCM.retrieveChanges(GitSCM.java:1129)
	at hudson.plugins.git.GitSCM.checkout(GitSCM.java:1160)
	at org.jenkinsci.plugins.workflow.steps.scm.SCMStep.checkout(SCMStep.java:113)
	at org.jenkinsci.plugins.workflow.steps.scm.SCMStep$StepExecutionImpl.run(SCMStep.java:85)
	at org.jenkinsci.plugins.workflow.steps.scm.SCMStep$StepExecutionImpl.run(SCMStep.java:75)
	at org.jenkinsci.plugins.workflow.steps.AbstractSynchronousNonBlockingStepExecution$1$1.call(AbstractSynchronousNonBlockingStepExecution.java:47)
	at hudson.security.ACL.impersonate(ACL.java:290)
	at org.jenkinsci.plugins.workflow.steps.AbstractSynchronousNonBlockingStepExecution$1.run(AbstractSynchronousNonBlockingStepExecution.java:44)
	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
	at java.util.concurrent.FutureTask.run(FutureTask.java:266)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
	at java.lang.Thread.run(Thread.java:748)
Caused by: hudson.plugins.git.GitException: Command "git fetch --tags --progress ssh://git@github.com/zeroc-ice/dist-utils.git +refs/heads/*:refs/remotes/origin/*" returned status code 128:
stdout: 
stderr: jenkins@github.com: 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:1996)
	at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandWithCredentials(CliGitAPIImpl.java:1715)
	at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.access$300(CliGitAPIImpl.java:72)
	at org.jenkinsci.plugins.gitclient.CliGitAPIImpl$1.execute(CliGitAPIImpl.java:405)
	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:210)
	at hudson.remoting.UserRequest.perform(UserRequest.java:53)
	at hudson.remoting.Request$2.run(Request.java:364)
	at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72)
	at java.util.concurrent.FutureTask.run(Unknown Source)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
	at hudson.remoting.Engine$1$1.run(Engine.java:94)
	at java.lang.Thread.run(Unknown Source)
	Suppressed: hudson.remoting.Channel$CallSiteStackTrace: Remote call to JNLP4-connect connection from sal.testing.zeroc.com/192.168.90.21:58772
		at hudson.remoting.Channel.attachCallSiteStackTrace(Channel.java:1737)
		at hudson.remoting.UserResponse.retrieve(UserRequest.java:313)
		at hudson.remoting.Channel.call(Channel.java:952)
		at org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler.execute(RemoteGitImpl.java:146)
		at sun.reflect.GeneratedMethodAccessor700.invoke(Unknown Source)
		at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
		at java.lang.reflect.Method.invoke(Method.java:498)
		at org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler.invoke(RemoteGitImpl.java:132)
		at com.sun.proxy.$Proxy96.execute(Unknown Source)
		at hudson.plugins.git.GitSCM.fetchFrom(GitSCM.java:860)
		at hudson.plugins.git.GitSCM.retrieveChanges(GitSCM.java:1129)
		at hudson.plugins.git.GitSCM.checkout(GitSCM.java:1160)
		at org.jenkinsci.plugins.workflow.steps.scm.SCMStep.checkout(SCMStep.java:113)
		at org.jenkinsci.plugins.workflow.steps.scm.SCMStep$StepExecutionImpl.run(SCMStep.java:85)
		at org.jenkinsci.plugins.workflow.steps.scm.SCMStep$StepExecutionImpl.run(SCMStep.java:75)
		at org.jenkinsci.plugins.workflow.steps.AbstractSynchronousNonBlockingStepExecution$1$1.call(AbstractSynchronousNonBlockingStepExecution.java:47)
		at hudson.security.ACL.impersonate(ACL.java:290)
		at org.jenkinsci.plugins.workflow.steps.AbstractSynchronousNonBlockingStepExecution$1.run(AbstractSynchronousNonBlockingStepExecution.java:44)
		at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
		at java.util.concurrent.FutureTask.run(FutureTask.java:266)
		at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
		at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
		at java.lang.Thread.run(Thread.java:748)

      Note, most importantly,

      stderr: jenkins@github.com: Permission denied (publickey).

      Running a git clone manually using an ssh agent works fine:

      sshagent(credentials: ['ssh-id-rsa']) {
  bat "git clone git@github.com:zeroc-ice/dist-utils.git dist-utils"
}

      Workarounds include:

      • Switch the username in the private key credential from the "actual user" to "git" (for example, instead of "MarkEWaite", use "git" as the credential username)
      • Switch to use username/password with https rather than a private key credential
      • Switch to use JGit as the git implementation for affected Jenkins jobs instead of command line git
      • Use a different version of OpenSSH (7.6 or earlier)

        1. BlueOceanGeneratedKeyWorkaround.png
          BlueOceanGeneratedKeyWorkaround.png
          88 kB

          [JENKINS-50573] Wrong username used for git clone with OpenSSH 7.7

          Mark Waite added a comment - - edited

          I've duplicated the problem in my environment. Alternatives include:

          1. Enable JGit in your installation and configure the job to use JGit instead of command line git
          2. Use Windows command line git 2.16.2 or earlier

          Problem is specific to OpenSSH 7.7 which is included with the Windows version of git 2.17.0. The behavior of the "-l" command line argument changed in the ssh command in OpenSSH 7.7. Previously the last argument value was used and did not override the username in the connection string ("URI"). Now the first argument value is used and it overrides the username in the connection string.

          The same problem is likely visible with OpenBSD 6.3, the first version that includes OpenSSH 7.7.

          Mark Waite added a comment - - edited I've duplicated the problem in my environment. Alternatives include: Enable JGit in your installation and configure the job to use JGit instead of command line git Use Windows command line git 2.16.2 or earlier Problem is specific to OpenSSH 7.7 which is included with the Windows version of git 2.17.0. The behavior of the "-l" command line argument changed in the ssh command in OpenSSH 7.7. Previously the last argument value was used and did not override the username in the connection string ("URI"). Now the first argument value is used and it overrides the username in the connection string. The same problem is likely visible with OpenBSD 6.3, the first version that includes OpenSSH 7.7.

          Mark Waite added a comment - - edited

          OpenSSH 7.7 changed the order of evaluation of login_name. OpenSSH 7.7 is first bundled in Git for Windows 2.17.0. OpenSSH bug 2385 describes the prior order as:

          1. user specified before @ character in hostname string
          2. login_name specified using -l switch (last value wins)
          3. User option provided as a parameter to -o switch
          4. User option in matching Host block from per-user config ~/.ssh/config
          5. User option in matching Host block from systemwide config /etc/ssh/ssh_config
          If there is nothing from above specified, username on local terminal is used.

          The OpenSSH 7.7 login_name evaluation order is:

          1. login_name specified using -l switch (first value wins)
          2. user specified before @ character in hostname string
          3. User option provided as a parametr to -o switch
          4. User option in matching Host block from per-user config ~/.ssh/config
          5. User option in matching Host block from systemwide config /etc/ssh/ssh_config
            If there is nothing from above specified, username on local terminal is used.

          OpenSSH Portable bug 2849 has been submitted to track the change.

          Johannes Schindelin of the Git for Windows project has submitted a pull request to the OpenSSH Portable project.  The OpenSSH project has closed the bug report as "Won't Fix".  Damien Miller states that the behavior change is intentional.

          I'll start the work to adjust the git client plugin and/or the git plugin to adapt to the OpenSSH behavior change.

          Mark Waite added a comment - - edited OpenSSH 7.7 changed the order of evaluation of login_name. OpenSSH 7.7 is first bundled in Git for Windows 2.17.0. OpenSSH bug 2385 describes the prior order as: 1. user specified before @ character in hostname string 2. login_name specified using -l switch (last value wins) 3. User option provided as a parameter to -o switch 4. User option in matching Host block from per-user config ~/.ssh/config 5. User option in matching Host block from systemwide config /etc/ssh/ssh_config If there is nothing from above specified, username on local terminal is used. The OpenSSH 7.7 login_name evaluation order is: login_name specified using -l switch (first value wins) user specified before @ character in hostname string User option provided as a parametr to -o switch User option in matching Host block from per-user config ~/.ssh/config User option in matching Host block from systemwide config /etc/ssh/ssh_config If there is nothing from above specified, username on local terminal is used. OpenSSH Portable bug 2849 has been submitted to track the change. Johannes Schindelin of the Git for Windows project has submitted a pull request to the OpenSSH Portable project.  The OpenSSH project has closed the bug report as "Won't Fix".  Damien Miller states that the behavior change is intentional. I'll start the work to adjust the git client plugin and/or the git plugin to adapt to the OpenSSH behavior change.

          Lee Flaherty added a comment -

          Noticed this with the Blue Ocean generated SSH key after updating a windows slave, the workaround was relatively simple but took a little digging to find. 

          I needed to locate the generated blue ocean-private-key-domain under the admin user which setup the pipeline and change the username to git


           

          Lee Flaherty added a comment - Noticed this with the Blue Ocean generated SSH key after updating a windows slave, the workaround was relatively simple but took a little digging to find.  I needed to locate the generated blue ocean-private-key-domain under the admin user which setup the pipeline and change the username to git  

          Mark Waite added a comment - - edited

          The pull request to fix this needs further interactive testing and regression testing. Download the build and install it on your machine.

          Those able to assist with either interactive testing or regression tests should report their results in the pull request.

          The workaround technique used by lflaherty is good, since it sets the username associated with the private key credential to be the same as the username that needs to be passed as the login_name argument.

          Mark Waite added a comment - - edited The pull request to fix this needs further interactive testing and regression testing. Download the build and install it on your machine. Those able to assist with either interactive testing or regression tests should report their results in the pull request . The workaround technique used by lflaherty is good, since it sets the username associated with the private key credential to be the same as the username that needs to be passed as the login_name argument.

          Mark Waite added a comment - - edited

          Debain Buster (the testing release) has updated to OpenSSH 7.7p1 and git 2.17.0. That makes this problem even more serious, since it is much more work to switch to a different git version on Linux than on Windows.

          Mark Waite added a comment - - edited Debain Buster (the testing release) has updated to OpenSSH 7.7p1 and git 2.17.0 . That makes this problem even more serious, since it is much more work to switch to a different git version on Linux than on Windows.

          SCM/JIRA link daemon added a comment -

          Code changed in jenkins
          User: Mark Waite
          Path:
          src/main/java/org/jenkinsci/plugins/gitclient/CliGitAPIImpl.java
          src/test/java/org/jenkinsci/plugins/gitclient/CredentialsTest.java
          http://jenkins-ci.org/commit/git-client-plugin/e2520d9a1a52fa210004e9a0d4cea42d97cf9fae
          Log:
          JENKINS-50573 Prefer URL username with ssh URL

          When using an ssh private key, the CliGitAPIImpl implementation previously
          passed a "-l" command line argument from the username associated with
          the ssh key. OpenSSH implementations prior to OpenSSH 7.7 would only use
          that command line argument if no username were included in the ssh URI.

          OpenSSH 7.7 changes the ssh command line argument parsing rules.
          Previously, the last user name specified would be used, including the
          user name in the URL. With OpenSSH 7.7, the first user name specified
          is used, even if a user name is specified in the URL.

          The command line:

          ssh -l jenkins git@github.com:jenkinsci/git-client-plugin.git

          uses the username 'git' with OpenSSH versions before 7.7 and uses the
          username 'jenkins' with OpenSSH 7.7.

          OpenSSH 7.7 is included in Windows Git 2.17 and in OpenBSD 6.3.

          The CredentialsTest class can test this case.

          SCM/JIRA link daemon added a comment - Code changed in jenkins User: Mark Waite Path: src/main/java/org/jenkinsci/plugins/gitclient/CliGitAPIImpl.java src/test/java/org/jenkinsci/plugins/gitclient/CredentialsTest.java http://jenkins-ci.org/commit/git-client-plugin/e2520d9a1a52fa210004e9a0d4cea42d97cf9fae Log: JENKINS-50573 Prefer URL username with ssh URL When using an ssh private key, the CliGitAPIImpl implementation previously passed a "-l" command line argument from the username associated with the ssh key. OpenSSH implementations prior to OpenSSH 7.7 would only use that command line argument if no username were included in the ssh URI. OpenSSH 7.7 changes the ssh command line argument parsing rules. Previously, the last user name specified would be used, including the user name in the URL. With OpenSSH 7.7, the first user name specified is used, even if a user name is specified in the URL. The command line: ssh -l jenkins git@github.com:jenkinsci/git-client-plugin.git uses the username 'git' with OpenSSH versions before 7.7 and uses the username 'jenkins' with OpenSSH 7.7. OpenSSH 7.7 is included in Windows Git 2.17 and in OpenBSD 6.3. The CredentialsTest class can test this case.

          Mark Waite added a comment -

          Fixed in git client plugin 2.7.2 released 12 May 2018

          Mark Waite added a comment - Fixed in git client plugin 2.7.2 released 12 May 2018

          Jonathan B added a comment - - edited

          I'm still having an issue with this with git-client 2.7.2. My pipeline job is defined as a "pipeline script from SCM" with a repository URL specified as `git@github.com@org/repo.git` but checkouts fail: `jenkins@github.com: Permission denied (publickey)`.

           

          As mentioned, this is an OpenSSH 7.7 issue. I'm running on Linux, with official Jenkins Docker images. When I use jenkins/jenkins:2.121.2-alpine (which has OpenSSH 7.7), I run into this failure. When I use jenkins/jenkins:2.121.2 (which has OpenSSH 7.4), I do not have the issue.

           

          I tried to debug this to find out what the value of `url` was when we attempt `url.getUser()`. According to logs under `jenkins.plugins.git.GitSCMFileSystem`, the value of `url` appears to be `origin`: "Fetching upstream changes from origin". [1]

           

          [1] There are two spots in https://github.com/jenkinsci/git-client-plugin/blob/315ad4e689897dedb20c900b8f32f1ce607fb32c/src/main/java/org/jenkinsci/plugins/gitclient/CliGitAPIImpl.java which log "Fetching upstream changes ...", but my stack trace includes line 405 of this file, and only has one "Fetching upstream changes ..." line, the one that interpolates the supposed URL.

          Jonathan B added a comment - - edited I'm still having an issue with this with git-client 2.7.2. My pipeline job is defined as a "pipeline script from SCM" with a repository URL specified as `git@github.com@org/repo.git` but checkouts fail: `jenkins@github.com: Permission denied (publickey)`.   As mentioned, this is an OpenSSH 7.7 issue. I'm running on Linux, with official Jenkins Docker images. When I use jenkins/jenkins:2.121.2-alpine (which has OpenSSH 7.7), I run into this failure. When I use jenkins/jenkins:2.121.2 (which has OpenSSH 7.4), I do not have the issue.   I tried to debug this to find out what the value of `url` was when we attempt `url.getUser()`. According to logs under `jenkins.plugins.git.GitSCMFileSystem`, the value of `url` appears to be `origin`: "Fetching upstream changes from origin".  [1]   [1]  There are two spots in https://github.com/jenkinsci/git-client-plugin/blob/315ad4e689897dedb20c900b8f32f1ce607fb32c/src/main/java/org/jenkinsci/plugins/gitclient/CliGitAPIImpl.java  which log "Fetching upstream changes ...", but my stack trace includes line 405 of this file, and only has one "Fetching upstream changes ..." line, the one that interpolates the supposed URL.

          Mark Waite added a comment -

          Thanks for detecting that failure mode jonathanb1. I can duplicate the failure based on your description. The problem seems to be specific to the `lightweight checkout` of a Pipeline read from SCM. With the "lightweight checkout" checked, I see this stack trace:

          hudson.plugins.git.GitException: Command "git fetch --tags --progress origin +refs/heads/JENKINS-37495:refs/remotes/origin/JENKINS-37495 --prune" returned status code 128:
stdout: 
stderr: MarkEWaite@github.com: 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:2002)
	at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandWithCredentials(CliGitAPIImpl.java:1721)
	at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.access$300(CliGitAPIImpl.java:72)
	at org.jenkinsci.plugins.gitclient.CliGitAPIImpl$1.execute(CliGitAPIImpl.java:405)
	at jenkins.plugins.git.GitSCMFileSystem$BuilderImpl.build(GitSCMFileSystem.java:351)
	at jenkins.scm.api.SCMFileSystem.of(SCMFileSystem.java:196)
	at jenkins.scm.api.SCMFileSystem.of(SCMFileSystem.java:172)
	at org.jenkinsci.plugins.workflow.cps.CpsScmFlowDefinition.create(CpsScmFlowDefinition.java:108)
	at org.jenkinsci.plugins.workflow.cps.CpsScmFlowDefinition.create(CpsScmFlowDefinition.java:67)
	at org.jenkinsci.plugins.workflow.job.WorkflowRun.run(WorkflowRun.java:303)
	at hudson.model.ResourceController.execute(ResourceController.java:97)
	at hudson.model.Executor.run(Executor.java:429)
Finished: FAILURE

          When I clear the "lightweight checkout" checkbox, then the clone completes as expected.

          Mark Waite added a comment - Thanks for detecting that failure mode jonathanb1 . I can duplicate the failure based on your description. The problem seems to be specific to the `lightweight checkout` of a Pipeline read from SCM. With the "lightweight checkout" checked, I see this stack trace: hudson.plugins.git.GitException: Command "git fetch --tags --progress origin +refs/heads/JENKINS-37495:refs/remotes/origin/JENKINS-37495 --prune" returned status code 128: stdout: stderr: MarkEWaite@github.com: 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:2002) at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandWithCredentials(CliGitAPIImpl.java:1721) at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.access$300(CliGitAPIImpl.java:72) at org.jenkinsci.plugins.gitclient.CliGitAPIImpl$1.execute(CliGitAPIImpl.java:405) at jenkins.plugins.git.GitSCMFileSystem$BuilderImpl.build(GitSCMFileSystem.java:351) at jenkins.scm.api.SCMFileSystem.of(SCMFileSystem.java:196) at jenkins.scm.api.SCMFileSystem.of(SCMFileSystem.java:172) at org.jenkinsci.plugins.workflow.cps.CpsScmFlowDefinition.create(CpsScmFlowDefinition.java:108) at org.jenkinsci.plugins.workflow.cps.CpsScmFlowDefinition.create(CpsScmFlowDefinition.java:67) at org.jenkinsci.plugins.workflow.job.WorkflowRun.run(WorkflowRun.java:303) at hudson.model.ResourceController.execute(ResourceController.java:97) at hudson.model.Executor.run(Executor.java:429) Finished: FAILURE When I clear the "lightweight checkout" checkbox, then the clone completes as expected.

          Mark Waite added a comment -

          Still an issue for Pipeline jobs which get their job definition from Git and use lightweight checkout. Stack trace looks like:

          hudson.plugins.git.GitException: Command "git fetch --tags --progress origin +refs/heads/master:refs/remotes/origin/master --prune" returned status code 128:
stdout: 
stderr: MarkEWaite@github.com: 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:2002)
	at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandWithCredentials(CliGitAPIImpl.java:1721)
	at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.access$300(CliGitAPIImpl.java:72)
	at org.jenkinsci.plugins.gitclient.CliGitAPIImpl$1.execute(CliGitAPIImpl.java:405)
	at jenkins.plugins.git.GitSCMFileSystem$BuilderImpl.build(GitSCMFileSystem.java:351)
	at jenkins.scm.api.SCMFileSystem.of(SCMFileSystem.java:196)
	at jenkins.scm.api.SCMFileSystem.of(SCMFileSystem.java:172)
	at org.jenkinsci.plugins.workflow.cps.CpsScmFlowDefinition.create(CpsScmFlowDefinition.java:108)
	at org.jenkinsci.plugins.workflow.cps.CpsScmFlowDefinition.create(CpsScmFlowDefinition.java:67)
	at org.jenkinsci.plugins.workflow.job.WorkflowRun.run(WorkflowRun.java:303)
	at hudson.model.ResourceController.execute(ResourceController.java:97)
	at hudson.model.Executor.run(Executor.java:429)
Finished: FAILURE

          Still an issue for multibranch Pipeline jobs which get their job definitions from Git. Stack trace looks like:

           > git fetch --tags --progress origin +refs/heads/*:refs/remotes/origin/* --prune
ERROR: [Thu Jul 19 22:59:55 GMT 2018] Could not fetch branches from source 9bad490a-8c8d-43e6-905a-3ff5d8591a86
hudson.plugins.git.GitException: Command "git fetch --tags --progress origin +refs/heads/*:refs/remotes/origin/* --prune" returned status code 128:
stdout: 
stderr: MarkEWaite@github.com: 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:2002)
	at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandWithCredentials(CliGitAPIImpl.java:1721)
	at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.access$300(CliGitAPIImpl.java:72)
	at org.jenkinsci.plugins.gitclient.CliGitAPIImpl$1.execute(CliGitAPIImpl.java:405)
	at jenkins.plugins.git.AbstractGitSCMSource.doRetrieve(AbstractGitSCMSource.java:351)
	at jenkins.plugins.git.AbstractGitSCMSource.retrieve(AbstractGitSCMSource.java:539)
	at jenkins.scm.api.SCMSource._retrieve(SCMSource.java:357)
	at jenkins.scm.api.SCMSource.fetch(SCMSource.java:267)
	at jenkins.branch.MultiBranchProject.computeChildren(MultiBranchProject.java:633)
	at com.cloudbees.hudson.plugins.folder.computed.ComputedFolder.updateChildren(ComputedFolder.java:276)
	at com.cloudbees.hudson.plugins.folder.computed.FolderComputation.run(FolderComputation.java:165)
	at jenkins.branch.MultiBranchProject$BranchIndexing.run(MultiBranchProject.java:1024)
	at hudson.model.ResourceController.execute(ResourceController.java:97)
	at hudson.model.Executor.run(Executor.java:429)
[Thu Jul 19 22:59:55 GMT 2018] Finished branch indexing. Indexing took 1.4 sec
FATAL: Failed to recompute children of Multibranch-Pipeline

          One workaround is to redefine the user portion of the Jenkins private key credential as the user "git" instead of the username typically used with the provider.

          A workaround for the Pipeline job (not multibranch Pipeline) is to not use lightweight checkout.

          Not an issue for Freestyle jobs.

          Mark Waite added a comment - Still an issue for Pipeline jobs which get their job definition from Git and use lightweight checkout. Stack trace looks like: hudson.plugins.git.GitException: Command "git fetch --tags --progress origin +refs/heads/master:refs/remotes/origin/master --prune" returned status code 128: stdout: stderr: MarkEWaite@github.com: 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:2002) at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandWithCredentials(CliGitAPIImpl.java:1721) at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.access$300(CliGitAPIImpl.java:72) at org.jenkinsci.plugins.gitclient.CliGitAPIImpl$1.execute(CliGitAPIImpl.java:405) at jenkins.plugins.git.GitSCMFileSystem$BuilderImpl.build(GitSCMFileSystem.java:351) at jenkins.scm.api.SCMFileSystem.of(SCMFileSystem.java:196) at jenkins.scm.api.SCMFileSystem.of(SCMFileSystem.java:172) at org.jenkinsci.plugins.workflow.cps.CpsScmFlowDefinition.create(CpsScmFlowDefinition.java:108) at org.jenkinsci.plugins.workflow.cps.CpsScmFlowDefinition.create(CpsScmFlowDefinition.java:67) at org.jenkinsci.plugins.workflow.job.WorkflowRun.run(WorkflowRun.java:303) at hudson.model.ResourceController.execute(ResourceController.java:97) at hudson.model.Executor.run(Executor.java:429) Finished: FAILURE Still an issue for multibranch Pipeline jobs which get their job definitions from Git. Stack trace looks like: > git fetch --tags --progress origin +refs/heads/*:refs/remotes/origin/* --prune ERROR: [Thu Jul 19 22:59:55 GMT 2018] Could not fetch branches from source 9bad490a-8c8d-43e6-905a-3ff5d8591a86 hudson.plugins.git.GitException: Command "git fetch --tags --progress origin +refs/heads/*:refs/remotes/origin/* --prune" returned status code 128: stdout: stderr: MarkEWaite@github.com: 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:2002) at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandWithCredentials(CliGitAPIImpl.java:1721) at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.access$300(CliGitAPIImpl.java:72) at org.jenkinsci.plugins.gitclient.CliGitAPIImpl$1.execute(CliGitAPIImpl.java:405) at jenkins.plugins.git.AbstractGitSCMSource.doRetrieve(AbstractGitSCMSource.java:351) at jenkins.plugins.git.AbstractGitSCMSource.retrieve(AbstractGitSCMSource.java:539) at jenkins.scm.api.SCMSource._retrieve(SCMSource.java:357) at jenkins.scm.api.SCMSource.fetch(SCMSource.java:267) at jenkins.branch.MultiBranchProject.computeChildren(MultiBranchProject.java:633) at com.cloudbees.hudson.plugins.folder.computed.ComputedFolder.updateChildren(ComputedFolder.java:276) at com.cloudbees.hudson.plugins.folder.computed.FolderComputation.run(FolderComputation.java:165) at jenkins.branch.MultiBranchProject$BranchIndexing.run(MultiBranchProject.java:1024) at hudson.model.ResourceController.execute(ResourceController.java:97) at hudson.model.Executor.run(Executor.java:429) [Thu Jul 19 22:59:55 GMT 2018] Finished branch indexing. Indexing took 1.4 sec FATAL: Failed to recompute children of Multibranch-Pipeline One workaround is to redefine the user portion of the Jenkins private key credential as the user "git" instead of the username typically used with the provider. A workaround for the Pipeline job (not multibranch Pipeline) is to not use lightweight checkout. Not an issue for Freestyle jobs.

          Jonathan B added a comment -

          markewaite thank you very much for confirming that you see still the issue. The lightweight checkout workaround worked in my case.

          Jonathan B added a comment - markewaite thank you very much for confirming that you see still the issue. The lightweight checkout workaround worked in my case.

          Mark Waite added a comment - - edited

          jonathanb1 a git client plugin 2.7.3 pre-release build is available. Would you be willing to test it in your environment? I'm running it in mine and have confirmed it resolves the issue.

          Mark Waite added a comment - - edited jonathanb1 a git client plugin 2.7.3 pre-release build is available. Would you be willing to test it in your environment? I'm running it in mine and have confirmed it resolves the issue.

          Norbert Lange added a comment -

          Hello, I did a quick test with the new version, and it solves the issue on my installation (docker with jenkins/jenkins:2.121.2-alpine). Thanks

          Norbert Lange added a comment - Hello, I did a quick test with the new version, and it solves the issue on my installation (docker with jenkins/jenkins:2.121.2-alpine). Thanks

          Jonathan B added a comment -

          This pre-release build also looks good on my end. Thanks!

          Jonathan B added a comment - This pre-release build also looks good on my end. Thanks!

          Mark Waite added a comment -

          Included in git client plugin 2.7.3 and git client plugin 3.0.0-beta4 released 24 July 2018.

          Mark Waite added a comment - Included in git client plugin 2.7.3 and git client plugin 3.0.0-beta4 released 24 July 2018.

          Owen Mehegan added a comment -

          I just wanted to add that MacOS 10.13.6 is also affected by this. It includes OpenSSH 7.8. Updating git-client fixes the problem on those hosts.

          Owen Mehegan added a comment - I just wanted to add that MacOS 10.13.6 is also affected by this. It includes OpenSSH 7.8. Updating git-client fixes the problem on those hosts.

            markewaite Mark Waite
            externl Joe George
            Votes:
            0 Vote for this issue
            Watchers:
            11 Start watching this issue

              Created:
              Updated:
              Resolved: