Vscode-remote-release: remote ssh: git commit fails when gpg signing via gpg-agent forwarding

[diablodale]

Git fails to sign a commit, with _Windows_ VSCode Remote SSH, when GnuPG on the local+remote computers are configured to use the local GPG agent/keys.

Setup

Version: 1.36.1 (system setup)
Commit: 2213894ea0415ee8c85c5eea0d0ff81ecc191529
Date: 2019-07-08T22:59:35.033Z
Electron: 4.2.5
Chrome: 69.0.3497.128
Node.js: 10.11.0
V8: 6.9.427.31-electron.0
OS: Windows_NT x64 10.0.18362

Remote SSH Extension: 0.44.2
Remote Development pack: 0.15.0

Repo

In WSL Ubuntu 18.04...

1. Setup GIT signing with GPG https://git-scm.com/book/en/v2/Git-Tools-Signing-Your-Work
   
   
   
   • Set your global git config for gpg.program=gpg, user.signingkey=xxxxxx, and commit.gpgsign=true
   
   
2. Setup GPG agent forwarding over SSH https://wiki.gnupg.org/AgentForwarding
3. SSH to a remote Ubuntu 18.04 server...

Now on this remote Ubuntu 18.04 server...

1. Setup GIT signing with GPG
   
   
   
   • Again set your global git config
   
   
2. Setup the server portion of GPG agent forwarding over SSH https://wiki.gnupg.org/AgentForwarding
   
   
   
   • Restart ssh daemon if you edited sshd configuration
   
   
3. Logout of the remote server (restart ssh daemon if necessary)
4. SSH again to the remote server
5. Create a new GIT repo
6. Create a dummy file
7. Git commit that new file. It should automatically gpg sign it due to your global git config
8. git log --show-signature and notice the successful gpg signature. 🙂 This demonstrates that the remote git+ssh+gpg is successfully going over the ssh tunnel and using the local gpg agent/keys.

Now on your Windows computer

1. Launch VSCode
2. Use the VSCode Remote Development Extension for SSH to open a SSH connection to the same remote server
3. Open the same remote server's folder in which you created that git repo
4. Edit and make changes to the dummy file
5. Using VSCode's UI, committ this file

Result

The commit fails and VSCode shows a modal error dialog box Git: gpg failed to sign the data

In the Output tab for Remote - SSH is the following of interest. Notice the last line with error

SSH Resolver called for host: home-nas
Setting up SSH remote "home-nas"
Using commit id "2213894ea0415ee8c85c5eea0d0ff81ecc191529" and quality "stable" for server
Testing ssh with ssh -V
ssh exited with code: 0
Got stderr from ssh: OpenSSH_for_Windows_7.7p1, LibreSSL 2.6.5
Running script with connection command: "ssh"  -o ClearAllForwardings=true    "home-nas" bash
...
> connect to /home/dale/.gnupg/S.gpg-agent.extra port -2 failed: No such file or d
> irectory

Expected

Successful commit

Notes

I believe part of the problem is due to _Windows_ VSCode using a Win32 SSH program yet my entire GPG and SSH configuration is in WSL. In WSL I have all the SSH config settings and entire GPG environment/agent.

This topic of sockets and forwarding are likely related to the following two: https://github.com/microsoft/vscode-remote-release/issues/16 , https://github.com/microsoft/vscode-remote-release/issues/72
Potential workaround in the topic https://github.com/microsoft/vscode-remote-release/issues/937

This is my ~/.ssh/config in WSL

Host myremoteserver
  User dale
  Hostname myremoteserver
  IdentityFile ~/.ssh/id2_rsa
  RemoteForward /run/user/1000/gnupg/S.gpg-agent /home/dale/.gnupg/S.gpg-agent.extra

Given the error in the Remote - SSH log above, this suggests to me that the Windows SSH client is:

1. Referencing a WSL path. The Windows SSH client likely does not understand a local Windows path of /home/dale/.gnupg/S.gpg-agent.extra
2. Mismatch of networking/socket environments. The Windows SSH client is trying to setup a Windows socket at that path when it needs to be in the WSL environment because the gpg-agent is running in WSL and listening on that WSL unix-socket path.

[jletey]

@diablodale Is this equivalent? #72

[diablodale]

In my notes area, 72 is one of the three related issues. However, not duplicates. 72 is focused on only docker containers and already has a workaround.

[jletey]

I see, sorry ... my bad ... completely missed your notes area 🤦‍♂️

[roblourens]

You are right that this is about the WSL side and windows side. I have https://github.com/microsoft/vscode-remote-release/issues/937 for that.

[roblourens]

I don't see any reason why this wouldn't work with #937, so I'll close it as a duplicate for now. Have you tried verifying that by just SSHing from a WSL terminal?

[roblourens]

Also I see you found the SSH agent forwarding issue, which sounds relevant, but I think it isn't because that is really about setting the SSH_AUTH_SOCK environment variable so it can find the forwarded agent socket. However it sounds like in this case you always use the same remote socket path and there is no environment variable that needs to be fixed in the remote environment.

[diablodale]

Hello. As I read what you wrote, I think your collapsing together two things:

• Feature to enable use of WSL gpg infrastructure in VSCode
• Failure of VS Code/extension (or dependencies) to recognize WSL paths+config in GPG+SSH configurations and therefore must transform them into WSL style and use WSL tools+pipes.

Making the former new feature might obscure the latter. So this issue becomes a test case (not a dup) that testers needs to add to the test case list.

Alternately, thelatter bug could be fixed which requires code changes to recognize a WSL path+config was given and then to either: a) abort with meaningful error, or b) to the transformations.

[roblourens]

I don't think it's possible for vscode to do anything about the second issue on it's own. Trying to map the wsl path to a windows path will just lead to pain, and I also don't think vscode should try to validate an ssh config any further than what openssh itself does. But I will leave this issue open to make sure it is considered carefully along with #937.

[anthr76]

Facing same issue via SSH with Linux to Linux.

[billcxx]

For me, this solves the problem

export GPG_TTY=$(tty)

https://unix.stackexchange.com/questions/257061/gentoo-linux-gpg-encrypts-properly-a-file-passed-through-parameter-but-throws-i/257065#257065

[fcastilloec]

For me, this solves the problem

export GPG_TTY=$(tty)

https://unix.stackexchange.com/questions/257061/gentoo-linux-gpg-encrypts-properly-a-file-passed-through-parameter-but-throws-i/257065#257065

I tried this, adding it to the remote machine's .bashrc but I'm still getting the error. Any other ideas?