-
Bug
-
Resolution: Fixed
-
Major
-
None
-
Git plugin 2.0, git client plugin 1.4.6, Windows 8, Windows Server 2011, Windows 7
A git job configured to use the command line implementation with Git plugin 2.0 and git client plugin 1.4.6 fails to clone on Windows, but successfully clones on Linux.
The problem seems to be that it is trying to configure an environment (setting SSH_PASS=echo) for the launched command, even though Windows does not use the same technique to pass environment variables to a process.
I think there was a different behavior in prior versions of git-client.
I created the job by:
- Configure a global ssh credential
- Create a new job, restrict it to only run on Windows
- Use a git ssh protocol URL (like ssh://wheezy64b/var/cache/git/mwaite/bin.git)
- Select the correct ssh credential from the dropdown list
- Add a build step (I used XShell "echo hello world")
- Save the job
- Run the job
Stack trace on Windows:
Started by user anonymous Building remotely on alan-pc in workspace C:\J\workspace\git-cli-ssh Cloning the remote Git repository Cloning repository ssh://wheezy64b/var/cache/git/mwaite/bin.git git --version git version 1.8.3.msysgit.0 using GIT_SSH to set credentials Jenkins ERROR: Error cloning remote repo 'origin' hudson.plugins.git.GitException: Could not clone ssh://wheezy64b/var/cache/git/mwaite/bin.git at org.jenkinsci.plugins.gitclient.CliGitAPIImpl$1.execute(CliGitAPIImpl.java:310) at org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler$1.call(RemoteGitImpl.java:151) at org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler$1.call(RemoteGitImpl.java:144) at hudson.remoting.UserRequest.perform(UserRequest.java:118) at hudson.remoting.UserRequest.perform(UserRequest.java:48) at hudson.remoting.Request$2.run(Request.java:326) 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:63) at java.lang.Thread.run(Unknown Source) Caused by: hudson.plugins.git.GitException: Command "clone --progress -o origin ssh://wheezy64b/var/cache/git/mwaite/bin.git C:\J\workspace\git-cli-ssh" returned status code 128: stdout: Cloning into 'C:\J\workspace\git-cli-ssh'... stderr: error: cannot spawn C:\Users\Alan\AppData\Local\Temp\ssh3783977685963347919.exe: No such file or directory fatal: unable to fork at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:981) at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandWithCredentials(CliGitAPIImpl.java:920) at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.access$400(CliGitAPIImpl.java:64) at org.jenkinsci.plugins.gitclient.CliGitAPIImpl$1.execute(CliGitAPIImpl.java:308) ... 11 more ERROR: null Finished: FAILURE
- is duplicated by
-
-
- Closed
-
[JENKINS-20356] Git CLI cannot clone on Windows using GIT_SSH to set credentials when running as a service
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.
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
Matt Hauck
added a comment - This can probably be marked as Resolved fixed now? 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.
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.
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.
yao wei
added a comment - ilatypov 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.
yao wei
added a comment - ilatypov 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. 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://git@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[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]
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.
This PR solves the issue I am having with windows and GIT_SSH: https://github.com/jenkinsci/git-client-plugin/pull/207