debug1: Remote: Agent forwarding not supported in Windows yet

[ghost]

"OpenSSH for Windows" version 7.7.2.2 default online capabilities install

Server OperatingSystem Windows 10

Client OperatingSystem Arch Linux x86_64

What is failing ForwardAgent from linux to windows. Debug message indicates that Forwarding agent is not supported.

debug1: Remote: Agent forwarding not supported in Windows yet

Expected behavior from linux ssh -A to Windows should forward the agent. on Windows it should be possible to list the forwarded keys with ssh-add -l

The error message from the windows openssh server indicates that this feature is not available yet.

[po1xi548Rysh8BH6]

bump

I would love to see this feature implemented. In our linux shop we certainly have a need for this feature when doing windows builds of our software.

[brianhatchet]

Bumping this feature as well. VS Code's Remote Development plugins and Windows OpenSSH Server is a powerful combination. However, without the ability forward keys, it prevents easy access to git repositories that allow access over ssh using a public key. Or any sort of "jump box" setup.

I am currently working around this by running OpenSSH Server on Ubuntu in WSL, but that's a bit of a shoehorn. Enabling this key feature of OpenSSH (heh) would simplify this setup immensely.

[seppestas]

Note that this is documented in https://github.com/PowerShell/Win32-OpenSSH/wiki/Project-Scope. However, it is called "Authentication forwarding" iof. "Agent forwarding".

I suggest labeling this issue with the "feature request". It's a lacking feature, not a bug.

IMO the wiki should use the "Agent forwarding" terminology to better document this.

[shmerl]

Does this still apply? For example that scope page says that X11 forwarding isn't supported, but it actually already works.

But I tired doing agent forwarding (using ssh -A) like this: Linux → Windows → Linux, and it didn't work.

[Mazwak]

Been trying for 3 hours, to no avail. I think it’s still missing.

I’m using latest release 8.6.0.0p1.

[Mazwak]

I just realized I misread the OP.

I tested Windows -> Linux, not Linux -> Windows.

~~Installed 8.9.1.0p1-Beta, and it works for my needs.~~

~~That is:~~

• ~~ssh into a second server~~
• ~~kgit push/pull inside VSCode with remoteSSH~~

[shmerl]

I managed to bypass it with using -J (ssh jump). It worked fine.

[ghost]

Hello, I myself have no longer a use case for this setup and cannot test it. But thx for the great work and support! Reading comment by shmerl seams to work, closing my original issue :)

[Emilgardis]

Can we reopen this issue as it's on the vNext milestone?

[shmerl]

To clarify, -A -J only helps if you jump from a Linux host over the Windows host straight to another Linux host (ProxyJump). Not sure if this is fixed if you do simply -A and then -A again from it.

[bilby91]

I've been working on getting support for ssh forwarding by implementing AF_UNIX sa_family.

So far I have a build where ssh-add -l will list the fingerprints from the first host (where the ssh client runs) successfully. From what've seen (I'm fairly new to Windows development), we would need to conditionally support AF_UNIX since it's only supported in > Windows 10.

I'm more than happy to contribute with a PR for this support but I would probably need some guidance in terms of how to protect the different code paths and what would be the best approach to check for the AF_UNIX support.

[bilby91]

I can confirm that authentication against GitHub is working fine using ssh -T.

PS C:\Users\bilby91> ssh -T [email protected]
debug3: receive packet: type 90
debug1: client_input_channel_open: ctype [email protected] rchan 2 win 65536 max 16384
debug2: client_request_agent: ssh_agent_bind_hostkey: agent refused operation
debug2: fd 9 setting O_NONBLOCK
debug3: fd 9 is O_NONBLOCK
debug1: channel 1: new [authentication agent connection]
debug1: confirm [email protected]
debug3: send packet: type 91
debug3: receive packet: type 96
debug2: channel 1: rcvd eof
debug2: channel 1: output open -> drain
debug2: channel 1: obuf empty
debug2: chan_shutdown_write: channel 1: (i0 o1 sock 9 wfd 9 efd -1 [closed])
debug2: channel 1: output drain -> closed
debug1: channel 1: FORCE input drain
debug2: channel 1: ibuf empty
debug2: channel 1: send eof
debug3: send packet: type 96
debug2: channel 1: input drain -> closed
debug2: channel 1: send close
debug3: send packet: type 97
debug3: channel 1: will not send data after close
debug3: receive packet: type 97
debug2: channel 1: rcvd close
debug3: channel 1: will not send data after close
debug2: channel 1: is dead
debug2: channel 1: garbage collecting
debug1: channel 1: free: authentication agent connection, nchannels 2
debug3: channel 1: status: The following connections are open:
  #0 client-session (t4 r0 i0/0 o0/0 e[write]/0 fd 6/7/8 sock -1 cc -1 io 0x01/0x00)
  #1 authentication agent connection (t4 r2 i3/0 o3/0 e[closed]/0 fd 9/9/-1 sock 9 cc -1 io 0x00/0x00)

Hi bilby91! You've successfully authenticated, but GitHub does not provide shell access.

I still can't get git clone to use the key from the agent. I suspect that this might be related to git not using my custom built version. Anyone has any idea around that ?

[bilby91]

I had to configure git config --global core.sshcommand "C:/Program\ Files/OpenSSH/ssh.exe" to use my own ssh.exe. I can now clone repositories using the ssh key stored in 1Password in my local mac 🚀

[bilby91]

WSL2 support is also working when running bash in the sshed powershell session