ssh-agent forwarding for devcontainers on Windows

[froazin]

Summary

Since the OpenSSH Client on Windows doesn’t support ssh-agent forwarding, it would be really nice if the 1Password VSCode extension could act as a proxy, providing effectively emulated ssh-agent forwarding when using Dev Containers or SSH Remote Development.

Use cases

• Enable Git Commit signing when working inside Dev Containers on Windows.
• Enable SSH Authentication with remote endpoints, for pulling/pushing commits, packages etc. when working inside Dev Containers on Windows.

Proposed solution

The extension could replace the ssh-agent inside the dev container in a similar fashion to how the 1Password SSH agent integration on Windows replaces the native ssh-agent. When the container tries to use an SSH key, it sends the request to the extension, which then forwards it to the 1Password desktop app on the Windows host, and then returns the result back to the container.

Is there a workaround to accomplish this today?

It is possible to install docker in WSL directly, rather than use Docker Desktop for Windows. In doing so, you can forward the ssh-agent from your WSL distro to the dev container. This approach has a couple of drawbacks:

• You will need to store your SSH keys in your ~/.ssh directory in your WSL distro and use the native Linux ssh-agent.
• VSCode needs to be configured to always launch Dev Containers by executing within WSL. Windows Containers are off the table.
• You must be using WSL. If you're using Docker Desktop with the Hyper-V backend, you're out of luck.

I've read that switching to the Windows OpenSSH beta channel solves the issue of ssh-agent forwarding. I've not tested this and not seen if/how well this works with the 1Password SSH agent integration for Windows. So, I'll report back my findings once I've found out.

[froazin]

Update: Switching to the beta channel for Win32-OpenSSH does indeed allow ssh-agent forwarding in windows and, it works with 1Password. Admittedly I've only tested on WSL for now.

Will close this request as the functionality is already enroute via the actual Win32-OpenSSH project so adding here as well would be redundant and just create more work than is necessary to maintain.