[JIRA] [git-client-plugin] (JENKINS-20356) Git CLI cannot clone on Windows using GIT_SSH to set credentials when running as a service

0 views
Skip to first unread message

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

unread,
May 21, 2015, 6:11:07 PM5/21/15
to jenkinsc...@googlegroups.com
Mark Waite assigned an issue to Unassigned
 
Jenkins / Bug JENKINS-20356
Git CLI cannot clone on Windows using GIT_SSH to set credentials when running as a service
Change By: Mark Waite
Assignee: Mark Waite
Add Comment Add Comment
 
This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265)
Atlassian logo

horn.drew@gmail.com (JIRA)

unread,
Sep 20, 2015, 9:24:03 PM9/20/15
to jenkinsc...@googlegroups.com
Drew Horn commented on Bug JENKINS-20356
 
Re: Git CLI cannot clone on Windows using GIT_SSH to set credentials when running as a service

I'm seeing the same issue where the clone fails due to permissions even when the proper SSH key is set for the project. The same project buliding on os x or linux works fine. I think GIT_SSH can't set the ssh key properly before trying to clone on the windows box:

ERROR: Error cloning remote repo 'origin'
hudson.plugins.git.GitException: Command "C:\Program Files\Git\cmd\git -c core.askpass=true fetch --tags --progress g...@github.com:<github_repo> +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.

Versions:

Git version: 2.5.3
Jenkins 1.6.129
Git Plugin 2.4.0
Windows 10 (build-agent – agent installed as windows service)

I'll follow up if I find a workaround.

horn.drew@gmail.com (JIRA)

unread,
Sep 20, 2015, 11:03:02 PM9/20/15
to jenkinsc...@googlegroups.com
Drew Horn edited a comment on Bug JENKINS-20356
I'm seeing the same issue where the clone fails due to permissions even when the proper SSH key is set for the project. The *same* project buliding on os x or linux works fine. I think GIT_SSH can't set the ssh key properly before trying to clone on the windows box:

{noformat}

ERROR: Error cloning remote repo 'origin'
hudson.plugins.git.GitException: Command "C:\Program Files\Git\cmd\git -c core.askpass=true fetch --tags --progress g...@github.com:<github_repo> +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.
{noformat}



Versions:

Git version: 2.5.3
Jenkins 1.6.129
Git Plugin 2.4.0
Windows 10 (build-agent -- agent installed as windows service)


I'll follow up if I find a workaround.



**UPDATE** - I had to work around this by just deleting the SSH Credential in Jenkins and just setting a public/private key for the windows box to use (in ~/.ssh) for all builds. Not ideal as using different SSH keys for building different projects in different git repos is ideal. Perhaps an environment variable isn't being set before trying to run git? Unsure.

horn.drew@gmail.com (JIRA)

unread,
Sep 20, 2015, 11:04:01 PM9/20/15
to jenkinsc...@googlegroups.com
Drew Horn edited a comment on Bug JENKINS-20356
I'm seeing the same issue where the clone fails due to permissions even when the proper SSH key is set for the project. The *same* project buliding on os x or linux works fine. I think GIT_SSH can't set the ssh key properly before trying to clone on the windows box:

{noformat}
ERROR: Error cloning remote repo 'origin'
hudson.plugins.git.GitException: Command "C:\Program Files\Git\cmd\git -c core.askpass=true fetch --tags --progress g...@github.com:<github_repo> +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.
{noformat}


Versions:

Git version: 2.5.3
Jenkins 1.6.129
Git Plugin 2.4.0
Windows 10 (build-agent -- agent installed as windows service)

I'll follow up if I find a workaround.


**UPDATE** - I had to work around this by just deleting the SSH Credential in Jenkins and just setting a public/private key  for  on  the windows  box to use  slave itself  (in ~/.ssh)  which will be used  for all builds. Not ideal as using different SSH keys for building different projects in different git repos is ideal. Perhaps an environment variable isn't being set before trying to run git? Unsure.

ryan@sensics.com (JIRA)

unread,
Feb 9, 2016, 5:13:01 PM2/9/16
to jenkinsc...@googlegroups.com

I may be experiencing this in what I reported in https://issues.jenkins-ci.org/browse/JENKINS-20941?focusedCommentId=247772&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-247772

There, I have a private github repo, with SSH credentials set, specified as g...@github.com:sensics/abcde.git , which I think cloned fine on its own. It has submodules specified, in the same format, for which the same credential should work, in the repo, and the additional submodule behaviors added to the config, but the "access rights" error as seen above occurs for the submodules.

taynesheim_5@msn.com (JIRA)

unread,
Mar 16, 2016, 3:55:02 PM3/16/16
to jenkinsc...@googlegroups.com

Ryan Pavlik: Hey Ryan, so I was having the same issue you were having regarding https://issues.jenkins-ci.org/browse/JENKINS-20941.
So it turns out that Jenkins uses the systemprofile as its default user when it runs. So in order to get this to work I needed to copy my .ssh into the home directory of the systemprofile which for me resides at C:\Windows\system32\config\systemprofile.
But for your specific machine you can run the echo %USERPROFILE$ cmd in a Jenkins job to confirm what that directory is.

matthauck (JIRA)

unread,
Jun 15, 2016, 7:25:02 PM6/15/16
to jenkinsc...@googlegroups.com

Still seeing this myself, using `g...@github.com:...` style repo name. I have a multi-platform matrix job that works just fine on linuxes, but fails to checkout the code from windows. I copied out the temp files that get created by the git client plugin to do the GIT_SSH and SSH_ASKPASS magic, and ran it on a command line as a logged in user to get jenkins out of the way, and it appears to totally ignore SSH_ASKPASS. I got prompted every time... This is on git-for-windows 2.9.0. Maybe I should try an older version where this used to work?
This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c)
Atlassian logo

matthauck (JIRA)

unread,
Jun 15, 2016, 7:27:02 PM6/15/16
to jenkinsc...@googlegroups.com

And unfortunately, putting the private key on the windows box is not sufficient to override this issue for windows – since the credentials in the jenkins job set the GIT_SSH stuff and overrides whatever it already has locally. So, we'd have to copy the private key to every build node then. This would not be good...

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

unread,
Jun 15, 2016, 9:54:02 PM6/15/16
to jenkinsc...@googlegroups.com

Matt Hauck you might also try to evaluate the git plugin beta and the git client beta that are available from the experimental update center.

matthauck (JIRA)

unread,
Jun 16, 2016, 12:44:04 AM6/16/16
to jenkinsc...@googlegroups.com

I believe this PR solves the issue I am having with windows and GIT_SSH: https://github.com/jenkinsci/git-client-plugin/pull/207

matthauck (JIRA)

unread,
Jun 16, 2016, 1:53:02 AM6/16/16
to jenkinsc...@googlegroups.com
Matt Hauck edited a comment on Bug JENKINS-20356
I believe this This PR solves the issue I am having with windows and GIT_SSH: https://github.com/jenkinsci/git-client-plugin/pull/207

scm_issue_link@java.net (JIRA)

unread,
Feb 26, 2017, 11:12:05 PM2/26/17
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/9c12a007c5a029f92a132b54bf04b5ae31462f2c
Log:
Merge pull request #207 from matthauck/windows-askpass

JENKINS-20356 Fix SSH_ASKPASS on windows

Compare: https://github.com/jenkinsci/git-client-plugin/compare/f52e3e8f2406...9c12a007c5a0

scm_issue_link@java.net (JIRA)

unread,
Feb 26, 2017, 11:12:06 PM2/26/17
to jenkinsc...@googlegroups.com

Code changed in jenkins
User: Matt Hauck
Path:
src/main/java/org/jenkinsci/plugins/gitclient/CliGitAPIImpl.java
http://jenkins-ci.org/commit/git-client-plugin/8297db9579996906c8ddfabc470e322951771b84
Log:


JENKINS-20356 Fix SSH_ASKPASS on windows

The SSH_ASKPASS script was being setup improperly on windows since
it was echoing quotes as well as the actual echo command itself
since `@echo off` was not being specified.

matthauck (JIRA)

unread,
Feb 28, 2017, 8:03:04 PM2/28/17
to jenkinsc...@googlegroups.com

This can probably be marked as Resolved fixed now?

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

unread,
Feb 28, 2017, 8:13:03 PM2/28/17
to jenkinsc...@googlegroups.com

I haven't yet been able to verify that the change in git-client-plugin 2.3.0 is enough to resolve it, but yes, if you've confirmed with git-client-plugin 2.3.0 that it now works as expected on Windows when running as a service, then you could mark it resolved.

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

unread,
Nov 28, 2019, 12:00:05 PM11/28/19
to jenkinsc...@googlegroups.com

Assumed resolved after two years with no further comments. The ssh-slaves plugin now includes instructions to allow recent Windows versions to use the Windows OpenSSH service to run agents.
This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f)
Atlassian logo

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

unread,
Nov 28, 2019, 12:01:06 PM11/28/19
to jenkinsc...@googlegroups.com
Mark Waite closed an issue as Fixed
 
Change By: Mark Waite
Status: Open Closed
Resolution: Fixed

ilatypov@yahoo.ca (JIRA)

unread,
Mar 24, 2020, 11:30:03 PM3/24/20
to jenkinsc...@googlegroups.com
Ilguiz Latypov commented on Bug JENKINS-20356
 
Re: Git CLI cannot clone on Windows using GIT_SSH to set credentials when running as a service

For those stumbling on this ticket searching for a similar error saying "permission denied", this may result from (domain) administrators installing Bit9 Parity CarbonBlack to white-list the commands allowed on the machine.
This message was sent by Atlassian Jira (v7.13.12#713012-sha1:6e07c38)
Atlassian logo

wei.yao1992@gmail.com (JIRA)

unread,
Mar 25, 2020, 4:39:06 PM3/25/20
to jenkinsc...@googlegroups.com
yao wei commented on Bug JENKINS-20356

Ilguiz Latypov Could you be more specific? How to know if it's the Bit9 Parity CarbonBlack causes the problem? It would be much helpful if you could share the link about "permission denied", thanks.

One of the machines in my domain is failing because of this reason, the other machine works fine. 

ilatypov@yahoo.ca (JIRA)

unread,
Mar 25, 2020, 5:21:03 PM3/25/20
to jenkinsc...@googlegroups.com

The proof was found in Event Viewer / Windows Logs / Application in a message from Source "Cb Protection Agent Notifier".

Notification displayed for target "d:\jenkins\workspace\DIR\PROJ@tmp\jenkins-gitclient-ssh196668178943043519.bat" and process "c:\program files\git\mingw64\bin\git.exe".

Cb Protection blocked an attempt by git.exe to run jenkins-gitclient-ssh196668178943043519.bat because the file is not approved.  If you require access to this file, please contact your system administrator or submit an approval request.
Note that approval requests are processed based on priority and arrival time. Please be patient while your request is reviewed and processed.  Scroll down for diagnostic data.

Source[c:\program files\git\mingw64\bin\git.exe] ProcessHash[017b2f5aa11781cd293e1c412472ed3d92d08affd945fa63bb3a633b1a98785c] ProcessPublisher[Johannes Schindelin (Valid[Yes] Trusted[Yes])]
Cmd[git.exe fetch --tags --force --progress -- ssh://g...@COMPANY.TLD:PORT/GROUP/PROJ.git +refs/heads/*:refs/re]
ProcessFlags[WrittenFiles:HaveABInfo]
KernelProcessFlags[LocalSystem:64Bit:DepEnabled:LocalAdmin]
Tags[\device\harddiskvolume1\program files\git\mingw64\bin\git.exe]
Target[d:\jenkins\workspace\DIR\PROJ@tmp\jenkins-gitclient-ssh196668178943043519.bat]
Notifier[Block] TargetHash[3b29d2bc77bcadb27fc146d767f23d9c46fb5ab7836daa4d0e60134f1e34996b] TargetPublisher[No Publisher (Valid[No] Trusted[Ineligible:No Cert])]
Media[Fixed] Device[Unapproved:0x00000000] DeviceFlags[0x00000000]
State[Unapproved] Flags[0x00000802]
Object[File]
Rule[File and Path Execute: Unapproved Executables] List[17] Group[100] Id[27]
Server[CBPServer.COMPANY.COM:41002]
Policy[MFC High Enforcement] Id[41] Version[0x00000000] CLVersion[211507]
Enforcement[20:20:20]
User[NT AUTHORITY\SYSTEM] Pid[12616] Tid[12936]
Computer[XXXXXX] Domain[DDDDDDDD]
Agent[8.1.6.212]
OS[Microsoft Windows Server 2008 R2 x64 Server Enterprise Service Pack 1 (6.1.7601)]
DateTime[3/24/2020 10:03:49 PM]

As a work-around I could replace the default option of using the "git" command with using "JGit" in Global Tool configuration, but because CarbonBlack disabled any other invokation of external commands, I resorted to asking the admins to correct the CarbonBlack limit. I think they added a permission one level above the particular random path to the auto-generated batch files, but I don't know their exact solution. It worked.

ilatypov@yahoo.ca (JIRA)

unread,
Mar 25, 2020, 5:22:07 PM3/25/20
to jenkinsc...@googlegroups.com
Ilguiz Latypov edited a comment on Bug JENKINS-20356
The proof was found in Event Viewer / Windows Logs / Application in a message from Source "Cb Protection Agent Notifier".
{noformat}

Notification displayed for target "d:\jenkins\workspace\DIR\PROJ@tmp\jenkins-gitclient-ssh196668178943043519.bat" and process "c:\program files\git\mingw64\bin\git.exe".

Cb Protection blocked an attempt by git.exe to run jenkins-gitclient-ssh196668178943043519.bat because the file is not approved.  If you require access to this file, please contact your system administrator or submit an approval request.
Note that approval requests are processed based on priority and arrival time. Please be patient while your request is reviewed and processed.  Scroll down for diagnostic data.

Source[c:\program files\git\mingw64\bin\git.exe] ProcessHash[017b2f5aa11781cd293e1c412472ed3d92d08affd945fa63bb3a633b1a98785c] ProcessPublisher[Johannes Schindelin (Valid[Yes] Trusted[Yes])]
Cmd[git.exe fetch --tags --force --progress -- ssh://g...@COMPANY.TLD:PORT/GROUP/PROJ.git +refs/heads/*:refs/re]
ProcessFlags[WrittenFiles:HaveABInfo]
KernelProcessFlags[LocalSystem:64Bit:DepEnabled:LocalAdmin]
Tags[\device\harddiskvolume1\program files\git\mingw64\bin\git.exe]
Target[d:\jenkins\workspace\DIR\PROJ@tmp\jenkins-gitclient-ssh196668178943043519.bat]
Notifier[Block] TargetHash[3b29d2bc77bcadb27fc146d767f23d9c46fb5ab7836daa4d0e60134f1e34996b] TargetPublisher[No Publisher (Valid[No] Trusted[Ineligible:No Cert])]
Media[Fixed] Device[Unapproved:0x00000000] DeviceFlags[0x00000000]
State[Unapproved] Flags[0x00000802]
Object[File]
Rule[File and Path Execute: Unapproved Executables] List[17] Group[100] Id[27]
Server[CBPServer.COMPANY.COM:41002]
Policy[ MFC COMPANY High Enforcement] Id[41] Version[0x00000000] CLVersion[211507]

Enforcement[20:20:20]
User[NT AUTHORITY\SYSTEM] Pid[12616] Tid[12936]
Computer[XXXXXX] Domain[DDDDDDDD]
Agent[8.1.6.212]
OS[Microsoft Windows Server 2008 R2 x64 Server Enterprise Service Pack 1 (6.1.7601)]
DateTime[3/24/2020 10:03:49 PM]
{noformat}


As a work-around I could replace the default option of using the "git" command with using "JGit" in Global Tool configuration, but because CarbonBlack disabled any other invokation of external commands, I resorted to asking the admins to correct the CarbonBlack limit.  I think they added a permission one level above the particular random path to the auto-generated batch files, but I don't know their exact solution.  It worked.

wei.yao1992@gmail.com (JIRA)

unread,
Mar 30, 2020, 12:09:05 PM3/30/20
to jenkinsc...@googlegroups.com
yao wei commented on Bug JENKINS-20356

Ilguiz Latypov Thanks for the update! I tried, my git.exe is also blocked by Cp protection. Thank!
Reply all
Reply to author
Forward
0 new messages