Fix/ssh forwarding agent

[dani84bs]

Problem

With ForwardAgent yes configured, the remote session gets an SSH_AUTH_SOCK
pointing at a socket path that does not exist, so agent forwarding silently
fails (ssh-add -l → "Could not open a connection to your authentication agent").

This is the symptom reported in #11.

Root cause

The ssh2 library binds the forwarded agent socket to the single session
channel that first requests agent forwarding (_agentFwdEnabled is a
client-level flag; the request is sent for that one channel id). sshd tears the
socket down as soon as that channel closes.

The extension read SSH_AUTH_SOCK from the short-lived install/start exec
channel. By the time the value reached VS Code, that channel — and therefore
its forwarding socket — was already gone, leaving every terminal / task /
extension-host process with a dangling path.

Fix

Open a dedicated channel that stays alive for the whole connection to host
the agent forwarding, and read its live SSH_AUTH_SOCK from there:

• SSHConnection.execChannel() — runs a command and resolves with its channel as
  soon as it opens (no pty), instead of waiting for completion.
• RemoteSSHResolver.openAgentForwardSession() — runs echo "$SSH_AUTH_SOCK"; exec cat
  on that channel: prints the socket path once, then exec cat keeps the channel
  (and its socket) open for the connection's lifetime. Closed in dispose().

Notes:

• No pty on purpose. A pty echoes typed input back before the shell runs it,
  which would otherwise be captured as the command's output (yielding a literal,
  unexpanded $SSH_AUTH_SOCK).
• Best-effort. Failure to set up forwarding is caught and logged; it never
  blocks connecting to the remote.
• Cross-platform safe. Only an absolute path is accepted, so a non-POSIX
  remote (e.g. cmd.exe echoing the command verbatim) falls back to unset —
  no worse than before, never a bogus value.

Testing

• Verified end-to-end: local macOS → Linux remote, ForwardAgent yes.
  echo $SSH_AUTH_SOCK, ls -l $SSH_AUTH_SOCK, and ssh-add -l all resolve
  correctly inside a remote terminal.
• Works via ~/.ssh/config (ForwardAgent / IdentityAgent) as well as an
  SSH_AUTH_SOCK env var.

Closes #11.

[daiyam]

I'm sorry. I would like to add unit tests before adding new fixes or features. I would like to have it done by the end of the week. So please be patient. Thx

[dani84bs]

I'm sorry. I would like to add unit tests before adding new fixes or features. I would like to have it done by the end of the week. So please be patient. Thx

It sounds more than wise!
Thank you so much

[daiyam]

Could you add a test with ForwardAgent yes?

A test: https://github.com/jeanp413/open-remote-ssh/blob/master/test/fixtures/default/linux-bash.yml
The used docker: https://github.com/jeanp413/open-remote-ssh/tree/master/dockerfiles/ubuntu-bash

npm run test:images // to build the docker images
npm run test // execute the tests

[dani84bs]

Could you add a test with ForwardAgent yes?

A test: https://github.com/jeanp413/open-remote-ssh/blob/master/test/fixtures/default/linux-bash.yml The used docker: https://github.com/jeanp413/open-remote-ssh/tree/master/dockerfiles/ubuntu-bash

npm run test:images // to build the docker images
npm run test // execute the tests

Sure! 😀

[dani84bs]

Hi @jeanp413 I pushed the commit with tests, please le me know if they are enough

[daiyam]

LGTM

[daiyam]

https://github.com/jeanp413/open-remote-ssh/releases/tag/v0.2.1-beta.2