microsoft
Enable use of gpg-agent for Explorer view population
I am aware that the Docker extension uses dockerode (which in turn uses ssh2) for invoking Docker APIs and that currently ssh-agent usage is solved. Because my org mandates the use of GPG signature on all commits, I recently moved to using gpg-agent for both forwarding my SSH identities as well as GPG keys. (Only one agent can be forwarded, so ssh-agent needs to be disabled in order to use gpg-agent, but it hits two birds with one stone, so that's no problem.)
Connecting to remote containers using Remote - Containers with gpg-agent enabled inside the container works flawlessly, I can push/pull/sign code. Having added the remote end as a docker context, I wanted to use this extension to spin up a container that I connect to, but the Explorer view cannot use my selected remote context I defined via the SSH protocol which works passwordless so long as gpg-agent is used (and I added the name of the remote as configure in my .ssh/config).
For the time being I connect to the remote machine to spin up a container either in a VS Code window or in a console window. No biggie, but it does break the flow and reduce elegance.
What OS do you use on your host machine? I'm not very familiar with gpg-agent but it's possible that all that would be needed is to set the SSH_AUTH_SOCK environment variable to match the pipe that gpg-agent is listening on (assuming it's compatible with ssh2 in the same way that ssh-agent is).
I'm using Windows with win-gpg-agent helpers. My effort in and the author's help are documented here.
Related: #3263, which would probably make this obsolete since the CLI doesn't depend on an ssh-agent.
@bwateratmsft Thanks for your reply, as it turns out SSH_AUTH_SOCK is already set to the named pipe that Win32-OpenSSH recognizes. This is set by the agent-gui, the primary helper in win-gpg-agent. The list of things the helper does are summarized here, of which one is:
set environment variable
SSH_AUTH_SOCKon Windows side to point either to pipe name so native OpenSSH tools know where to go or to Cygwin socket file to be used with Cygwin/MSYS2 ssh binaries.
On the remote end, I have in my .bashrc file the following snipet:
_sock_name=$(gpgconf --list-dir agent-socket)
# We came with Win32-OpenSSH, recreate domain socket for remotely forwarded S.gpg-agent.extra
rm -f ${_sock_name}
( socat UNIX-LISTEN:${_sock_name},fork TCP4:127.0.0.1:2850 & ) >/dev/null 2>&1
unset _sock_name
Everything works flawlessly when developing otherwise, I can SSH to the remote end without password prompts (the pinentry provided by win-gpg-agent integrates with the Windows Credential Store, unlike the one shipping with Gpg4Win), there I can sign code using git and authenticate myself with the SSH key on my GPG keychain. The Remote-Docker extensions of MS also displays the containers fine on the remote end (it uses the docker CLI), but it's feature set of managing contexts and containers is far more limited. It's only this extension that isn't gpg-agent friendly, even though SSH_AUTH_SOCK is set, albeit to a value that's only meaningful to Win32-OpenSSH and not to SSH clients expecting vanilla OpenSSH internals.
That makes sense. We're working on a CLI-only Docker client (#3263), that would solve this if Remote - Containers is able to work correctly.
@MathiasMagnus we're actively working on #3263 now; since we'll be using the Docker CLI only going forward (no longer the HTTP endpoint), I think your scenario should work as long as the CLI does.
With #3586 merged (fixing #3263), I'm going to speculatively close this issue, as it should be fixed.
Since we're using only the CLI to communicate now, as long as the CLI is working, the explorer views should too.