| 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. |
