So it appears that ssh will use the IdentityAgent property from the ~/.ssh/config file before it uses the SSH_AUTH_SOCK environment variable. Git started working in the dev container once I disabled the IdentityAgent in the config file.

Another solution is to bind ~/.1password/agent.sock into the container. This will satisfy the IdentityAgent locally and in the container.

From man ssh:

IdentityAgent

Specifies the Unix-domain socket used to communicate with the authentication agent.

This option overrides the SSH_AUTH_SOCK environment variable and can be used to select a specific agent. Setting the socket name to none disables the use of an authentication agent. If the string "SSH_AUTH_SOCK" is specified, the location of the socket will be read from the SSH_AUTH_SOCK environment variable. Otherwise if the specified value begins with a ‘$’ character, then it will be treated as an environment variable containing the location of the socket.

Arguments to IdentityAgent may use the tilde syntax to refer to a user's home directory, the tokens described in the “TOKENS” section and environment variables as described in the “ENVIRONMENT VARIABLES” section.

So, to make this work both locally and in a dev container:
1. export the SSH_AUTH_SOCK in your shell's config file (.bashrc, .zshrc, etc.).
2. Use IdentifyAgent SSH_AUTH_SOCK in the ~/.ssh/config file

Hi @smfelsher,

I've been trying to resolve a similar issue, however, my setup is a little different.

My host OS is Windows and I use WSL2 for some coding. In VS Code in Windows and VS Code in WSL2, signing my commits with a key from 1Password works beautifully.

However, when I launch a devcontainer from WSL2, something's not working.

I am trying to see how your solution might help me resolve my issue, but I am not sure how to do it.

$SSH_AUTH_SOCK in WSL2 is empty.
$SSH_AUTH_SOCK in the devcontainer in WSL2 contains a socket referencing

ssh-add -l in WSL2 returns an error: Could not open a connection to your authentication agent.

ssh-add -l in the devcontainer in WSL returns the same list of keys as on the Windows host OS (so at least something seems to work...).

I would appreciate any ideas you might have.

PS: In your latest reply, in step 2, I think you mean IdentityAgent instead of IdentifyAgent?

@Speedbird186 ,

Yes, it should be IdentityAgent!

Regarding your problem.

I think this will only work in a Dev Container by using the SSH_AUTH_SOCK environment variable. So, export SSH_AUTH_SOCK in your shell configuration file for WSL. If you're using bash, then in .bashrc put the following: export SSH_AUTH_SOCK="$HOME/.1password/agent.sock".

Now, launch VSCode, but before you start your dev container, see if your VSCode environment is seeing SSH_AUTH_SOCK. Open the integrated terminal in VSCode and see that SSH_AUTH_SOCK is set. If SSH_AUTH_SOCK is not set, you need to figure out how to set it before you launch your dev container. I believe VSCode will map the host SSH_AUTH_SOCK to a socket file in the container.

Oh, and one other thing that I forgot in my previous post! I have mapped my host ~/.ssh directory into the container. Here is a snippet from my devcontainer.json.

```json
"mounts": [
// Bind mount the developer's SSH directory to allow using SSH keys for
// GitLab. The target must be the home directory of the non-root user of the
// container.
{
"source": "${localEnv:HOME}/.ssh",
"target": "/home/node/.ssh",
"type": "bind"
}
]

```

I'm using a Node image and the non-root user, node, in the container, so I'm mapping my .ssh directory into the container user's home directory.

So,

• Your SSH config and keys must be mapped into the dev container, like on your host.
• VSCode will map the local SSH_AUTH_SOCK into the container if VSCode sees that SSH_AUTH_SOCK is set.
  • Unless you have changed any of the Remote SSH settings in VSCode.

Let me know if I can help you further or if you figure it out!