[JENKINS-71122] incorrect assumption in search for ssh on Windows

[jenkins-infra-bot]

the git client tries to obtain the location for SSH but fails if the ssh client is not installed with the official git plugin, or uses an incorrect ssh binary if ssh.exe is otherwise on the path.

This has multiple implications:

1) it just fails outright as it can not find ssh.exe despite it being on the path (C:\Windows\System32\OpenSSH\ssh.exe})
2) it may pick the incorrect the ssh.exe binary which may not be correctly integrated with the windows os to load certificates etc thus having different behaviour between the git plugin in jenkins and running the same commands on the command line directly as the Jenkins user.

2023-04-21 18:04:28.777+0000 [id=109]       WARNING o.e.j.s.h.ContextHandler$Context#log: Error while serving http://192.168.48.1:60095/job/vague_monarchy/descriptorByName/hudson.plugins.git.UserRemoteConfig/checkUrl
java.lang.RuntimeException: ssh executable not found. The git plugin only supports official git client https://git-scm.com/download/win
    at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.getSSHExecutable(CliGitAPIImpl.java:2587)
    at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.createWindowsGitSSH(CliGitAPIImpl.java:2593)
    at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandWithCredentials(CliGitAPIImpl.java:2047)
    at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandWithCredentials(CliGitAPIImpl.java:2007)
    at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandWithCredentials(CliGitAPIImpl.java:1998)
    at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.getHeadRev(CliGitAPIImpl.java:3646)

---

Originally reported by teilo, imported from: incorrect assumption in search for ssh on Windows

• assignee: markewaite
• status: Open
• priority: Minor
• component(s): git-client-plugin
• resolution: Unresolved
• votes: 0
• watchers: 2
• imported: 20251211-071809

Raw content of original issue

the git client tries to obtain the location for SSH but fails if the ssh client is not installed with the official git plugin, or uses an incorrect ssh binary if ssh.exe is otherwise on the path.

This has multiple implications:

1) it just fails outright as it can not find ssh.exe despite it being on the path (C:\Windows\System32\OpenSSH\ssh.exe})
2) it may pick the incorrect the ssh.exe binary which may not be correctly integrated with the windows os to load certificates etc thus having different behaviour between the git plugin in jenkins and running the same commands on the command line directly as the Jenkins user.


2023-04-21 18:04:28.777+0000 [id=109]       WARNING o.e.j.s.h.ContextHandler$Context#log: Error while serving http://192.168.48.1:60095/job/vague_monarchy/descriptorByName/hudson.plugins.git.UserRemoteConfig/checkUrl
java.lang.RuntimeException: ssh executable not found. The git plugin only supports official git client https://git-scm.com/download/win
    at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.getSSHExecutable(CliGitAPIImpl.java:2587)
    at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.createWindowsGitSSH(CliGitAPIImpl.java:2593)
    at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandWithCredentials(CliGitAPIImpl.java:2047)
    at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandWithCredentials(CliGitAPIImpl.java:2007)
    at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandWithCredentials(CliGitAPIImpl.java:1998)
    at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.getHeadRev(CliGitAPIImpl.java:3646)

[jenkins-infra-bot]

markewaite:

• Original comment link
• Raw content of original comment:

  I disagree that it is an incorrect assumption on the location of ssh for command line git for Windows.  I think that the plugin should prefer the ssh implementation that is delivered with command line git because that is the version of ssh that is most widely tested with command line git for Windows.
  
  The MinGit distribution of command line git for Windows delivers ssh.exe in the usr\bin\ssh.exe file.  It is designed for use with systems that do not require the full interactive capabilities of command line git (like Jenkins agents and Jenkins controllers).
  
  The full distribution of git for Windows delivers ssh.exe in C:\Program Files\Git\usr\bin\ssh.exe.  It is designed for use with systems that need the full interactive capabilities of command line git for Windows.  That is the ssh.exe version invoked when a git bash shell is used on Windows.  It can be the ssh.exe version invoked from command prompt windows if the full integration with git is used.
  
  I'm glad that OpenSSH 8.2p1 works well with command line git for Windows, but I believe that the git client plugin should continue its preference for the ssh.exe that is shipped with command line git for Windows.
  
  Can you help me better understand the configuration that exposed this issue to you?  We don't see this issue on the Windows agents on ci.jenkins.io.  I don't see the issue on Windows ssh agents that I run with MinGit .  I don't see the issue on the Windows agents that I run with inbound agents started from a command prompt.
  
  I'm fine with adding the C:\Windows\System32\OpenSSH\ssh.exe location as another valid location to find ssh.exe on Windows, but would like to understand how you discovered the issue.
  

I disagree that it is an incorrect assumption on the location of ssh for command line git for Windows. I think that the plugin should prefer the ssh implementation that is delivered with command line git because that is the version of ssh that is most widely tested with command line git for Windows.

The MinGit distribution of command line git for Windows delivers ssh.exe in the usr\bin\ssh.exe file. It is designed for use with systems that do not require the full interactive capabilities of command line git (like Jenkins agents and Jenkins controllers).

The full distribution of git for Windows delivers ssh.exe in C:\Program Files\Git\usr\bin\ssh.exe. It is designed for use with systems that need the full interactive capabilities of command line git for Windows. That is the ssh.exe version invoked when a git bash shell is used on Windows. It can be the ssh.exe version invoked from command prompt windows if the full integration with git is used.

I'm glad that OpenSSH 8.2p1 works well with command line git for Windows, but I believe that the git client plugin should continue its preference for the ssh.exe that is shipped with command line git for Windows.

Can you help me better understand the configuration that exposed this issue to you? We don't see this issue on the Windows agents on ci.jenkins.io. I don't see the issue on Windows ssh agents that I run with MinGit . I don't see the issue on the Windows agents that I run with inbound agents started from a command prompt.

I'm fine with adding the C:\Windows\System32\OpenSSH\ssh.exe location as another valid location to find ssh.exe on Windows, but would like to understand how you discovered the issue.

[MarkEWaite]

Git client plugin 6.5.0 will switch to use the first SSH found on the Windows PATH. If it is not found on the Windows PATH, then it has a series of searches that it uses to find it. Thanks to @akash-manna-sky for pull request:

• [JENKINS-72450] Use first ssh in the Windows PATH #1706

[MarkEWaite]

Reverted from git client plugin 6.5.0 pre-release because Windows OpenSSH hangs when used from inside a Windows 11 (or 10) agent that was started by the SSH launcher.