Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Fix SSH agent forwarding on Windows #4007

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
Tracked by #5051
mafredri opened this issue Sep 12, 2022 · 9 comments
Open
Tracked by #5051

Fix SSH agent forwarding on Windows #4007

mafredri opened this issue Sep 12, 2022 · 9 comments
Labels
cli Area: CLI

Comments

@mafredri
Copy link
Member

mafredri commented Sep 12, 2022

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 #3126 (comment), 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 PowerShell/Win32-OpenSSH#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

This comment was marked as outdated.

@github-actions github-actions bot added the stale This issue is like stale bread. label Nov 12, 2022
@mafredri mafredri removed the stale This issue is like stale bread. label Nov 12, 2022
@ghuntley ghuntley mentioned this issue Nov 14, 2022
10 tasks
@omartijn
Copy link

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

@deansheather
Copy link
Member

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
Copy link
Member

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

@deansheather
Copy link
Member

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
Copy link

github-actions bot commented Apr 5, 2023

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.

@github-actions github-actions bot added the stale This issue is like stale bread. label Apr 5, 2023
@omartijn
Copy link

omartijn commented Apr 5, 2023

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.

@matifali matifali removed the stale This issue is like stale bread. label Apr 5, 2023
@github-actions github-actions bot added the stale This issue is like stale bread. label Jul 5, 2023
@matifali matifali removed the stale This issue is like stale bread. label Jul 5, 2023
@spikecurtis spikecurtis added the networking Area: networking label Sep 26, 2023
@github-actions github-actions bot added the stale This issue is like stale bread. label Mar 25, 2024
@github-actions github-actions bot closed this as not planned Won't fix, can't repro, duplicate, stale Apr 2, 2024
@mafredri
Copy link
Member Author

mafredri commented Apr 2, 2024

@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.

@mafredri mafredri reopened this Apr 2, 2024
@mafredri mafredri removed the stale This issue is like stale bread. label Apr 2, 2024
@coder-labeler coder-labeler bot added bug cli Area: CLI labels Apr 2, 2024
@deansheather deansheather removed the networking Area: networking label Apr 4, 2024
@matifali matifali added bug and removed feature labels Oct 14, 2024
@mafredri
Copy link
Member Author

Just discovered microsoft/go-winio which has support for named pipes, might be useful here.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
cli Area: CLI
Projects
None yet
Development

No branches or pull requests

6 participants