Jsch doesn't work with it, because there's no SSH_AUTH_SOCK and presumably it wouldn't work if there was.
But I think it would be relatively straightforward to support it. Instead of the socket, it maintains a named pipe at \\.pipe\openssh-ssh-agent. This seems to be a hard-coded name, and not something for which there's a runtime discovery process (beyond maybe scanning the directory for likely pipe names). Anyway, it looks like these pipes can be opened (although not created, but that's not a problem here) just via RandomAccessFile or FileChannel or, say, via Files::newByteChannel. ie: no native code required.
Using RandomAccessFile is probably simplest, I'm guessing, by way of writing a class implementing USocketFactory and its inner interface Socket to be backed by RandomAccessFile on that fixed named pipe, and the changes to ConnectorFactory to identify and return it where appropriate.
It means the USocketFactory bit is a bit misleadingly named, as we'd be implementing windows pipe access through it, but looks like that would allow the least intrusive change, by allowing it to work with the existing SSHAgentConnector.
This ought actually to be in my own capabilities, although dev on windows and maven is out of my normal bailiwick - but this issue is partly also to see if this project is alive or whether I should find another way. ;-)
Windows has its own official port of OpenSSH these days:
https://github.com/PowerShell/Win32-OpenSSH https://docs.microsoft.com/en-us/windows-server/administration/openssh/openssh_overview
Jsch doesn't work with it, because there's no SSH_AUTH_SOCK and presumably it wouldn't work if there was.
But I think it would be relatively straightforward to support it. Instead of the socket, it maintains a named pipe at
\\.pipe\openssh-ssh-agent. This seems to be a hard-coded name, and not something for which there's a runtime discovery process (beyond maybe scanning the directory for likely pipe names). Anyway, it looks like these pipes can be opened (although not created, but that's not a problem here) just via RandomAccessFile or FileChannel or, say, via Files::newByteChannel. ie: no native code required.Using RandomAccessFile is probably simplest, I'm guessing, by way of writing a class implementing USocketFactory and its inner interface Socket to be backed by RandomAccessFile on that fixed named pipe, and the changes to ConnectorFactory to identify and return it where appropriate.
It means the USocketFactory bit is a bit misleadingly named, as we'd be implementing windows pipe access through it, but looks like that would allow the least intrusive change, by allowing it to work with the existing SSHAgentConnector.
This ought actually to be in my own capabilities, although dev on windows and maven is out of my normal bailiwick - but this issue is partly also to see if this project is alive or whether I should find another way. ;-)