-
Bug
-
Resolution: Unresolved
-
Major
-
None
In Windows 10 version 1803, Microsoft started shipping OpenSSH in Windows, which was previously an optional beta feature. This causes problems for the sshagent step in Windows, which will produce a stacktrace resembling the following:
java.lang.RuntimeException: [ssh-agent] Could not find a suitable ssh-agent provider.
at com.cloudbees.jenkins.plugins.sshagent.SSHAgentStepExecution.initRemoteAgent(SSHAgentStepExecution.java:175)
at com.cloudbees.jenkins.plugins.sshagent.SSHAgentStepExecution.start(SSHAgentStepExecution.java:63)
at org.jenkinsci.plugins.workflow.cps.DSL.invokeStep(DSL.java:229)
at org.jenkinsci.plugins.workflow.cps.DSL.invokeMethod(DSL.java:153)
(snip!)
The problem is that Windows' OpenSSH binaries appear in the PATH ahead of those from Git, which means ssh-agent will be executed from C:\Windows\System32\OpenSSH.
There are two obvious workarounds for this – first, to uninstall Windows' OpenSSH (which can be done in the new Settings panel under "Manage optional features”). The other solution would be to tweak the system path so that Git's paths appear first, but this is likely to cause other problems in Windows. I also tried to set the GIT_SSH environment variable, but this did not seem to work.
It would be nice if the ssh-plugin either supported OpenSSH on Windows natively, or was smart enough to use the mingw binary provided on the system.
I had a quick look at the ssh-agent source code, and to support OpenSSH on Windows a fix would need to be made in the ExecRemoteAgent class. The OpenSSH agent service (which is disabled by default in Windows 10) doesn't produce the output that is expected by the ExecRemoteAgent class. Specifically, this class expects that ssh-agent will produce output resembling the following:
SSH_AUTH_SOCK=/tmp/whatever/agent.12283; export SSH_AUTH_SOCK;
SSH_AGENT_PID=12284; export SSH_AGENT_PID;
echo Agent pid 12284;
The class then attempts to extract the agent PID by parsing the text in the parseAgentEnv method. However, the ssh-agent implementation on Windows' OpenSSH client doesn't produce any output at all, which causes this exception to be thrown:
[ssh-agent] FATAL: Could not find a suitable ssh-agent provider
[ssh-agent] Diagnostic report
[ssh-agent] * Exec ssh-agent (binary ssh-agent on a remote machine)
[ssh-agent] java.lang.StringIndexOutOfBoundsException: String index out of range: -14
[ssh-agent] at java.lang.String.substring(String.java:1967)
[ssh-agent] at com.cloudbees.jenkins.plugins.sshagent.exec.ExecRemoteAgent.getAgentValue(ExecRemoteAgent.java:154)
[ssh-agent] at com.cloudbees.jenkins.plugins.sshagent.exec.ExecRemoteAgent.parseAgentEnv(ExecRemoteAgent.java:138)
(snip!)
I didn't dig any deeper into this, but my armchair opinion is that this class needs to find the PID in some other way than parsing stdout. I'm not sure exactly what way this would be. Microsoft is aware of this issue
see https://github.com/PowerShell/Win32-OpenSSH/issues/1145 but it is unclear if they will change the implementation just yet.
[JENKINS-51968] sshagent plugin broken on Windows 10 version 1803
| Priority | Original: Minor [ 4 ] | New: Major [ 3 ] |
| Description |
Original:
In Windows 10 version 1803, Microsoft started shipping OpenSSH in Windows, which was previously an optional beta feature. This causes problems for the sshagent step in Windows, which will produce a stacktrace resembling the following: java.lang.RuntimeException: [ssh-agent] Could not find a suitable ssh-agent provider. at com.cloudbees.jenkins.plugins.sshagent.SSHAgentStepExecution.initRemoteAgent(SSHAgentStepExecution.java:175) at com.cloudbees.jenkins.plugins.sshagent.SSHAgentStepExecution.start(SSHAgentStepExecution.java:63) at org.jenkinsci.plugins.workflow.cps.DSL.invokeStep(DSL.java:229) at org.jenkinsci.plugins.workflow.cps.DSL.invokeMethod(DSL.java:153) (snip!) The problem is that Windows' OpenSSH binaries appear in the PATH ahead of those from Git, which means ssh-agent will be executed from C:\Windows\System32\OpenSSH. There are two obvious workarounds for this – first, to uninstall Windows' OpenSSH (which can be done in the new Settings panel under "Manage optional features”). The other solution would be to tweak the system path so that Git's paths appear first, but this is likely to cause other problems in Windows. I also tried to set the GIT_SSH environment variable, but this did not seem to work. It would be nice if the ssh-plugin either supported OpenSSH on Windows natively, or was smart enough to use the mingw binary provided on the system. I had a quick look at the ssh-agent source code, and to support OpenSSH on Windows a fix would need to be made in the ExecRemoteAgent class. The OpenSSH agent service (which is disabled by default in Windows 10) doesn't produce the output that is expected by the ExecRemoteAgent class. Specifically, this class expects that ssh-agent will produce output resembling the following: {{SSH_AUTH_SOCK=/tmp/whatever/agent.12283; export SSH_AUTH_SOCK;}} {{SSH_AGENT_PID=12284; export SSH_AGENT_PID;}} {{echo Agent pid 12284;}} The class then attempts to extract the agent PID by parsing the text in the parseAgentEnv method. However, the ssh-agent implementation on Windows' OpenSSH client doesn't produce any output at all, which causes this exception to be thrown: [ssh-agent] FATAL: Could not find a suitable ssh-agent provider [ssh-agent] Diagnostic report [ssh-agent] * Exec ssh-agent (binary ssh-agent on a remote machine) [ssh-agent] java.lang.StringIndexOutOfBoundsException: String index out of range: -14 [ssh-agent] at java.lang.String.substring(String.java:1967) [ssh-agent] at com.cloudbees.jenkins.plugins.sshagent.exec.ExecRemoteAgent.getAgentValue(ExecRemoteAgent.java:154) [ssh-agent] at com.cloudbees.jenkins.plugins.sshagent.exec.ExecRemoteAgent.parseAgentEnv(ExecRemoteAgent.java:138) (snip!) I didn't dig any deeper into this, but my armchair opinion is that this class needs to find the PID in some other way than parsing stdout. I'm not sure exactly what way this would be. Microsoft is aware of this issue (see [https://github.com/PowerShell/Win32-OpenSSH/issues/1145|https://github.com/PowerShell/Win32-OpenSSH/issues/1145,]), but it is unclear if they will change the implementation just yet. |
New:
In Windows 10 version 1803, Microsoft started shipping OpenSSH in Windows, which was previously an optional beta feature. This causes problems for the sshagent step in Windows, which will produce a stacktrace resembling the following: java.lang.RuntimeException: [ssh-agent] Could not find a suitable ssh-agent provider. at com.cloudbees.jenkins.plugins.sshagent.SSHAgentStepExecution.initRemoteAgent(SSHAgentStepExecution.java:175) at com.cloudbees.jenkins.plugins.sshagent.SSHAgentStepExecution.start(SSHAgentStepExecution.java:63) at org.jenkinsci.plugins.workflow.cps.DSL.invokeStep(DSL.java:229) at org.jenkinsci.plugins.workflow.cps.DSL.invokeMethod(DSL.java:153) (snip!) The problem is that Windows' OpenSSH binaries appear in the PATH ahead of those from Git, which means ssh-agent will be executed from C:\Windows\System32\OpenSSH. There are two obvious workarounds for this – first, to uninstall Windows' OpenSSH (which can be done in the new Settings panel under "Manage optional features”). The other solution would be to tweak the system path so that Git's paths appear first, but this is likely to cause other problems in Windows. I also tried to set the GIT_SSH environment variable, but this did not seem to work. It would be nice if the ssh-plugin either supported OpenSSH on Windows natively, or was smart enough to use the mingw binary provided on the system. I had a quick look at the ssh-agent source code, and to support OpenSSH on Windows a fix would need to be made in the ExecRemoteAgent class. The OpenSSH agent service (which is disabled by default in Windows 10) doesn't produce the output that is expected by the ExecRemoteAgent class. Specifically, this class expects that ssh-agent will produce output resembling the following: {{SSH_AUTH_SOCK=/tmp/whatever/agent.12283; export SSH_AUTH_SOCK;}} {{SSH_AGENT_PID=12284; export SSH_AGENT_PID;}} {{echo Agent pid 12284;}} The class then attempts to extract the agent PID by parsing the text in the parseAgentEnv method. However, the ssh-agent implementation on Windows' OpenSSH client doesn't produce any output at all, which causes this exception to be thrown: [ssh-agent] FATAL: Could not find a suitable ssh-agent provider [ssh-agent] Diagnostic report [ssh-agent] * Exec ssh-agent (binary ssh-agent on a remote machine) [ssh-agent] java.lang.StringIndexOutOfBoundsException: String index out of range: -14 [ssh-agent] at java.lang.String.substring(String.java:1967) [ssh-agent] at com.cloudbees.jenkins.plugins.sshagent.exec.ExecRemoteAgent.getAgentValue(ExecRemoteAgent.java:154) [ssh-agent] at com.cloudbees.jenkins.plugins.sshagent.exec.ExecRemoteAgent.parseAgentEnv(ExecRemoteAgent.java:138) (snip!) I didn't dig any deeper into this, but my armchair opinion is that this class needs to find the PID in some other way than parsing stdout. I'm not sure exactly what way this would be. Microsoft is aware of this issue see [https://github.com/PowerShell/Win32-OpenSSH/issues/1145|https://github.com/PowerShell/Win32-OpenSSH/issues/1145,] but it is unclear if they will change the implementation just yet. |
jglick from reading:
https://github.com/PowerShell/Win32-OpenSSH/issues/827#issuecomment-321972376
creates a S.gpg-agent.ssh file - which may contain it? (although says port number, not PID so may not be useful).
I did in fact update my test installation of Windows 10 to 1803 and indeed saw an ssh-agent command appear, which prints nothing when run. (I did not have one before although I have some Git distribution installed, via Chocolatey.) If some S.gpg-agent.ssh file is being created, I could not find it. Nor does the command respond to /? etc.
Andreas Meyer
added a comment - Just a suggestion:
Read the path of ssh-agent from a dedicated environment variable (say JENKINS_SSH_AGENT) instead of solely relying on PATH. If JENKINS_SSH_AGENT isn't defined, fallback to the old behaviour. This way we could avoid fiddling with PATH altogether.
Andreas Meyer
added a comment - Just a suggestion:
Read the path of ssh-agent from a dedicated environment variable (say JENKINS_SSH_AGENT) instead of solely relying on PATH. If JENKINS_SSH_AGENT isn't defined, fallback to the old behaviour. This way we could avoid fiddling with PATH altogether. 
ethorsa
added a comment - Is there any workaround known? You can skip this plugin and just use the withCredentials step to bind an SSH private key to a local file, which can then be passed to various commands typically with a -i option. In a CI context I would not consider this any less secure than using ssh-agent, and it is certainly easier to troubleshoot.
Any progress on this, I also have this issue using the Windows OpenSSH
I get the following
[ssh-agent] Looking for ssh-agent implementation...
[ssh-agent] Exec ssh-agent (binary ssh-agent on a remote machine)
$ ssh-agent
[ssh-agent] FATAL: Could not find a suitable ssh-agent provider
If I run my container with: "PowerShell -c "Get-Command ssh-agent""
I get
CommandType Name Version Source ----------- ---- ------- ------ Application ssh-agent.exe 8.1.0.1 C:\Windows\System32\OpenSSH\ssh-agent.exe
This could be done specifically for the Jenkins agent, so it does not affect any other software.
Nor I. If the Windows version of this command behaves fundamentally differently than the Linux version, then it would make sense to create a distinct RemoteAgentFactory.