Skip to content
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

SSH ForwardAgent does not work for openvscode #1307

Open
nrontsis opened this issue Oct 7, 2024 · 2 comments
Open

SSH ForwardAgent does not work for openvscode #1307

nrontsis opened this issue Oct 7, 2024 · 2 comments
Labels

Comments

@nrontsis
Copy link
Contributor

nrontsis commented Oct 7, 2024

What happened?
ForwardAgent does not work on openvscode. If I do e.g.

devpod up https://github.com/loft-sh/devpod-example-go --provider docker --ide openvscode

the ssh_auth_sock is pointing to a non-existing file.

vscode ➜ /workspaces/devpod-example-go (main) $ ssh -T [email protected]
[email protected]: Permission denied (publickey).
vscode ➜ /workspaces/devpod-example-go (main) $ ls $SSH_AUTH_SOCK
ls: cannot access '/tmp/auth-agent3979699691/listener.sock': No such file or directory

while manually ssh'ing into the pod via ssh devpod-example-go.devpod has no issue: i.e. ForwardAgent works fine, and I can authenticate e.g. in github fine.

What did you expect to happen instead?
ForwardAgent to work for openvscode, as it does when I ssh into the pod.

How can we reproduce the bug? (as minimally and precisely as possible)
Run:

devpod up https://github.com/loft-sh/devpod-example-go --provider docker --ide openvscode

Local Environment:

  • DevPod Version: v0.5.21
  • Operating System: linux + mac
  • ARCH of the OS: AMD64 + ARM64

DevPod Provider:

  • Local/remote provider: docker 20.10.21

Anything else we need to know?
Nothing

@bkneis
Copy link
Contributor

bkneis commented Oct 9, 2024

@nrontsis thanks for raising this issue and providing a clear summary and example! I have replicated the issue and can confirm the problematic behaviours. After debugging I believe the issue is here https://github.com/loft-sh/devpod/blob/main/pkg/ssh/server/ssh.go#L136. We are overriding the SSH_AUTH_SOCK env var on each handler in the SSH server. I believe the issue is caused due to additional SSH commands that are sent in order to set up the container tunnel via the browser. For instance if you perform ls -la /tmp/auth-agent* you can see the correct listener.sock just in the wrong temp directory. If you manually update SSH_AUTH_SOCK to point to this file it works again.

I think the fix is to change the SSH server implementation so we can specify on a per connection basis if the SSH_AUTH_SOCK should be updated. This might be a fairly big change and I am currently occupied with another feature but will return to this soon!

@nrontsis
Copy link
Contributor Author

nrontsis commented Oct 9, 2024

thanks a lot for the reply and the analysis @bkneis!

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

No branches or pull requests

2 participants