RFC: Removal of pageant SSH agent support

[mscdex]

I'm considering removing support for authenticating with the pageant SSH agent (this the agent made by the PuTTY folks). Is there anyone out there that is relying on this and would miss it?

[mscdex]

The reasons why I'd like to remove this:

• While bundling an executable to communicate with the pageant process is nice because no build tools are required, it is not ideal. A few have commented about issues with having a Windows executable bundled with the project.
• The implementation executes a new child process per agent request (whether it's getting a list of public keys or signing data), which isn't very efficient/lightweight compared to a socket like with the OpenSSH agent.
• It's currently supported in the client configuration via a magic string value, which I never really liked, but it worked because it was strictly limited to Windows and more people used pageant there vs. something like cygwin.
• At the time pageant support was added, it was 3 years before WSL existed. It's also been 5 years since WSL was introduced and with its (growing) popularity I feel like perhaps the native OpenSSH agent via WSL has now supplanted pageant for most users.

Possible solutions:

• Completely remove support.
• Keep support built into ssh2 as-is
• Move implementation to a third party module on npm that is marked an optional dependency in ssh2. Not sure if the implementation would be as it is now or if it'd switch to being a C++ binding or perhaps a hybrid with the executable being pulled in from somewhere (either a 3rd npm module or from a git repo) and used as a fallback if the binding fails to compile.

[theophilusx]

I think complete removal or if required move to an optional second module. Last time I did a new windows 10 install, openSSH client was installed automatically and as you say, we now have WSL. Even openssh server is available with just a couple of clicks without WSL on Windows. One advantage of putting it into a separate module is that you can then monitor the download numbers and use that information to assess whether the code is worth maintaining etc. The core package would also then be smaller. mscdex ***@***.***> writes:

…

The reasons why I'd like to remove this: * While bundling an executable to communicate with the pageant process is nice because no build tools are required, it is not ideal. A few have commented about issues with having a Windows executable bundled with the project. * The implementation executes a new child process per agent request (whether it's getting a list of public keys or signing data), which isn't very efficient/lightweight compared to a socket like with OpenSSH. * It's currently supported in the client configuration via a magic string value, which I never really liked, but it worked because it was strictly limited to Windows and more people used pageant there vs. something like cygwin. * At the time pageant support was added, it was 3 years before WSL became a thing on Windows. It's been 5 years since WSL was introduced and with its popularity I feel like perhaps the native OpenSSH agent via WSL has now replaced pageant in popularity. Possible solutions: * Completely remove support. * Keep support built into ssh2 as-is * Move implementation to a third party module on npm that is marked an optional dependency in ssh2. Not sure if the implementation would be as it is now or if it'd switch to being a C++ binding or perhaps a hybrid with the executable being pulled in from somewhere (either a 3rd npm module or from a git repo) and used as a fallback if the binding fails to compile. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or unsubscribe.

-- Tim Cross

[131]

What about moving all ssh-agent related (client and server) to a dedicated repository / package ?
I understand with the recent merge of ssh2@1, it might look like going backward, but ssh-agent is a totally autonomous application & design

If you want it, I'll gladly leave my ssh-agent-js to you, so you can publish all your BaseAgent & stuffs 👍

[mscdex]

What about moving all ssh-agent related (client and server) to a dedicated repository / package ?

I'm less inclined to do this because it would mean needing to keep the separate modules in sync which is one of the things I disliked about ssh2-streams. Additionally there are other issues (e.g. github issue placement) that arise when you have multiple packages like that that are tightly dependent on each other that (from my experience) negate any benefit of separating things out.

For these reasons I'm leaning more towards option 1 or 2.

[131]

Then i'll go for Option 1 : Completely remove support.
It is the way to go ; leave this bloated thing outside of the scope of ssh2 main package.

It will end up as a dedicated external module, but that's nodejs way & design ( & success)

[rathboma]

I think a lot of users still use pageant, especially those in large organizations. My app (https://beekeeperstudio.io) has many users still using it for their SSH agent.

Could there be a middle ground where you leave open support for an 'agent plugin' so that at least the functionality could be moved to a separate package, and not bundled with ssh2?

[mscdex]

@rathboma At this point I'm less inclined to create/maintain such a separate module myself, but if someone else wants to pull the existing code out into a module and maintain that (and maybe improve it), that's fine. With the pluggable agent implementations in v1.x it would be trivial to use pageant authentication via a 3rd party module.