Skip to content

Conversation

@HannesWell
Copy link

Since Windows-10 a ssh-agent is installed by default on Windows systems. But that agent works differently than the ssh-agent known from UNIX systems and therefore attempts to use this plugin fail. From the error message the cause of the failure is not easy to understand. And of course not being able to use this plugin on Windows agents is in general a unsatisfactory situation.

Fortunately the git (for-windows) installation by default contains a ssh-agent implementation that behaves like the known UNIX implementation and runs on Windows. And a git installation is often available.

This change extends the ssh-agent plugin to attempt to locate the described ssh-agent installation provided by git, when running on Windows.
If no executable is found, either through a git installation or by searching the system's PATH variable, the execution fails with a meaningful message.

If you don't want a strict requirement on git-client I could also make that optional and prepare the code to handle a potential absence at runtime.

This hopefully avoids confusion like in

Testing done

I tested this locally with the changes applied on a Windows computer and it worked out of the box.
If you think there should be more test cases I'm happy to provide them, but I'd need some instructions and specific demands.
I see that you execute the build pipeline (including tests?) on Windows too, but from my understanding of the problem, this plugin effectively doesn't work on Windows at all (before this change). So either the latter assumption is wrong or the tests cover scenarios.

Submitter checklist

  • Make sure you are opening from a topic/feature/bugfix branch (right side) and not your main branch!
  • Ensure that the pull request title represents the desired changelog entry
  • Please describe what you did
  • Link to relevant issues in GitHub or Jira
  • Link to relevant pull requests, esp. upstream and downstream changes
  • Ensure you have provided tests that demonstrate the feature works or the issue is fixed

Since Windows-10 a ssh-agent is installed by default on Windows systems.
But that agent works differently than the ssh-agent known from UNIX
systems and therefore attempts to use this plugin fail.
From the error message the cause of the failure is not easy to
understand. And of course not being able to use this plugin on Windows
agents is in general a unsatisfactory situation.

Fortunately the git (for-windows) installation by default contains a
ssh-agent implementation that behaves like the known UNIX implementation
and runs on Windows. And a git installation is often available.

This change extends the ssh-agent plugin to attempt to locate the
described ssh-agent installation provided by git, when running on
Windows.
If no executable is found, either through a git installation or by
searching the system's PATH variable, the execution fails with a
meaningful message.
@HannesWell
Copy link
Author

HannesWell commented Nov 22, 2025

Another alternative or complementary solution could be adding a configuration option with the ssh-agent executable.
The default would be just ssh-agent, but one could also specify an absolute path to any other exe.
Of course would be ideal if this just works, but with an option for the (path of) the ssh-agent exe at least then one could make it work on Windows agents too, at least without adding the ssh-agent provided by Git to the system's PATH, which also can cause other problems.

@HannesWell
Copy link
Author

@jglick could you please have a look at this respectively the remaks?

@jglick
Copy link
Member

jglick commented Dec 1, 2025

Sorry, I am not maintaining this plugin save for critical fixes or routine org-wide maintenance. It works on Linux but was never intended for use on Windows, and is best avoided generally. #163 (comment)

@HannesWell
Copy link
Author

Sorry, I am not maintaining this plugin save for critical fixes or routine org-wide maintenance.

Too bad :/ Is there anybody else maintaining this too and interested in reviewing this?

It works on Linux but was never intended for use on Windows, and is best avoided generally.

Understand, still I think it would be convenient if this would work on Windows too, especially in multi-OS pipelines where similar scripts run under multiple OS. Mainly because this plugin makes the use of SSH very convenient and simple.

Another alternative or complementary solution could be adding a configuration option with the ssh-agent executable.
The default would be just ssh-agent, but one could also specify an absolute path to any other exe.

Or would you be willing to accept at least a change to just add the proposed executable parameter (or however you'd like to name it)? This way this plugin could at least be made to work on Windows without modifying the entire system PATH of the executing machine. And the change should be small and easy to review.

@jglick
Copy link
Member

jglick commented Dec 4, 2025

Is there anybody else maintaining this

I do not think so. I will mark it for adoption. (See #153.)

@HannesWell
Copy link
Author

Is there anybody else maintaining this

I do not think so. I will mark it for adoption.

Too bad :/

See #153.

Thanks for the pointer, I looked into this but I'm struggling to use the approach using eval $(ssh-agent -s) for a sshUserPrivateKey credential protected by a password.
Do you have any hints how to set up the ssh-agent securely in that case?

@jglick
Copy link
Member

jglick commented Dec 4, 2025

On Windows? No. For most purposes in CI systems you would not need to use ssh-agent at all, just directly pass a private key to some command.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants