Fix SSH agent forwarding on Windows

[mafredri]

Currently SSH agent forwarding is broken on Windows (even on the latest OpenSSH 8.9p1 release).

PS C:\Users\ZeroCool> & 'C:\Program Files\OpenSSH\ssh.exe' -V
OpenSSH_for_Windows_8.9p1, LibreSSL 3.4.3
PS C:\Users\ZeroCool> & 'C:\Program Files\OpenSSH\ssh-add.exe' -L
Error connecting to agent: Unknown error

It's uncertain what the problem is, but most likely the use of unix sockets. We could look at projects like masahide/OmniSSHAgent for inspiration.

Fixing this could open up a path towards using our own SSH agent proxy instead of our GIT_SSH_COMMAND wrapper. This would allow for features like git commit signing via SSH keys in the agent (including the coder key and whatever other keys have been forwarded).

---

As mentioned in https://github.com/coder/coder/issues/3126#issuecomment-1234285576, SSH agents are somewhat of a mess on Windows (excerpt):

When it comes to Windows, the SSH agent seems like a minefield. First and foremost, agent forwarding on Windows doesn't seem to work (or at least properly in all scenarios, see https://github.com/PowerShell/Win32-OpenSSH/issues/1865, the issue tracker has many more like it).

When I say a minefield, check out this graph (borrowed from masahide/OmniSSHAgent):

So take-aways here are that:

• Implementing our own SSH agent on Windows is fraught with peril (perhaps we can take learnings from OmniSSHAgent, or find similar libs that abstract it away)
• Our current SSH agent forwarding most likely doesn't work on Windows at all (I tested Windows 10, OpenSSH_for_Windows_8.1p1, didn't work), or perhaps it might in an environment where unix sockets are supported (although my understanding is that Windows OpenSSH is incompatible with std OpenSSH agent)
• More research (and testing a potential implementation in various settings) is needed

[github-actions[bot]]

This issue is becoming stale. In order to keep the tracker readable and actionable, I'm going close to this issue in 7 days if there isn't more activity.

[omartijn]

Yeah this is still broken, please don't just close issues "because they are stale"

[deansheather]

The way that SSH agent works on windows is that you start a system service and it listens on a named pipe called \\.\pipe\openssh-ssh-agent from my experience. So for forwarding from a windows client to a workspace, we need to connect to that named pipe instead of reading the env var. For forwarding to a windows workspace, we need to create a named pipe listener at that address. If one already exists we can't do anything.

[deansheather]

I'll investigate this after I get the GPG implementation mentioned above in.

[deansheather]

I think we can accomplish this for windows workspaces (i.e. listening on the agent socket) by intercepting forward calls in our SSH server, looking for values like /tmp/.ssh-agent and using a named pipe listener instead. Sadly, this method only supports a single listener, so it'll fail if the user tries to forward twice. I think that's fine for MVP though.

[github-actions[bot]]

This issue is becoming stale. In order to keep the tracker readable and actionable, I'm going close to this issue in 7 days if there isn't more activity.

[omartijn]

It seems to me that nowadays there are two schools of thought on the best way of keeping the number of open issues down. One way is to fix a bug and then close the issue. The other way is to simply wait an "appropriate amount of time", mark the issue as stale and then close it.

[mafredri]

@deansheather I'm guessing this issue is still not fixed? I'm reopening for now so it isn't lost. Feel free to close if this isn't the case.