Using 1Password with Visual Studio Code Remote SSH and Dev Containers on Linux

Dave Jansen

Dec 8, 2022 • 6 min read

1Password is a great and powerful tool that helps you use better, more secure passwords for all the accounts, services, and tools you may use.

In October 2020, a beta version of 1Password for Linux was announced, which I was very excited about. 1Password was one of the few tools that I really missed after switching to Linux full-time, so this was music to my ears.

I was using 1Password X up until this point, their browser extension that worked fully independently but had a limited feature set. As soon as all the needed features were in place in the beta – like creating/editing entries, this wasn't actually there initially), I switched over to their app, and I've been using it ever since.

In March of 2022, 1Password announced new features; SSH and Git support, built right into 1Password. This lets you add your SSH key(s) to 1Password, and configure 1Password as your authentication agent for both Git and SSH. With this you can easily sign your Git commits and log in to machines through SSH with the keys stored in your 1Password. What's more, these brand new features were also instantly available in their Linux client. How cool is that?

Setting this up is very easy, as the 1Password app tells you what configuration files to modify, and what to add. It can even do this for you with the click of a button. It's very straight-forward.

If you, like me, use Visual Studio Code with the Remote Development extensions, a few tweaks are needed, but after this you can use this functionality right from within your dev containers even and/or while using remote development servers.

Let's walk through what's needed to make this work.

💡

One important note; As of this writing, the Flatpak release of 1Password sadly does not support this new SSH/Git functionality.

While you can store your SSH keys in 1Password, you cannot configure 1Password to be used as the authentication agent. If you want to use this functionality, you'll have to install 1Password directly.

Checklist

Let's make a note of what our current environment looks like:

Your Linux distro of choice is up-to-date and supported by 1Password,
Your system has Git version 2.35 or newer installed,
You have 1Password installed directly, not the Flatpak version,
You have Visual Studio Code installed directly, not the Flatpak version, along with the Remote Development extensions, and;
You have at least one SSH key added to your 1Password vault.

Alright, let's get started.

Configuring 1Password

In your 1Password application, click on the three dotted menu button (top-left, right next to where it shows your current account selection), and select "Settings..." (or ctrl+, by default). Click on the Developer tab, and enable Use the SSH agent, and Connect with 1Password CLI. Don't let 1Password add its configuration bits when it asks you to, we'll do this manually (and slightly differently) in the next step.

I also recommend enabling Unlock using system authentication service in the Security tab, which will let you unlock 1Password with your system account's password, or something like a fingerprint sensor if you have one that is configured correctly with your system.

Configuring Git

Next, open up a terminal window and run the following command:

❯ git config --global gpg.format ssh

If you are planning on always signing your commits you can set right away:

❯ git config --global commit.gpgsign true

💡

If you've not done this already, now might also be a good time to set your default name and email address, using git config --global user.name "Your Name" and git config --global user.email "[email protected]".

In order to have Git sign your commits with the correct key, we'll set this now, too. Be sure to have already added this key to where you host your repositories (e.g. Github, Gitlab, etc.).

Normally you might point to the key file stored on your system, but in our case we instead set it to the public key of the key you'll be using that you've saved in your 1Password personal vault. The 1Password agent will use this and take care of the rest.

Find your key in 1Password, copy its public key, and then run the following command with this public key pasted in:

❯ git config --global user.signingkey "your public key"

If all went well, your ~/.gitconfig file should now look a little something like this:

[user]
	name = Dave Jansen
	email = i.am at this domain
	signingkey = ssh-ed25519 xxxxxxxxxxxxxx

[gpg]
	format = ssh

[commit]
	gpgsign = true

Configuring SSH

To have SSH use 1Password as the authentication agent, you'll have point the IdentityAgent setting to 1Password. In my case I want to use the 1Password agent for all hosts I connect with, so I added the option to all (wildcard) hosts in my ~/.ssh/config file (creating this file if it doesn't already exist). You can limit this only to certain hosts if you prefer. Either way, it should look something like this:

Host *
	IdentityAgent ~/.1password/agent.sock
	ForwardAgent yes

Note that I have configured ForwardAgent as-well. Depending on what you prefer, you may want to limit to which hosts the agent is forwarded, but in my case it is helpful as it allows me to make use 1Password even when I'm on a remote (dev) machine. Visual Studio Code has this enabled within its own settings by default, too (Refer to remote.SSH.enableAgentForwarding).

💡

If you have previously configured your ~/.ssh/config file to have specific keys for specific hosts and want to start using 1Password for these, too, you'll have to update these references to point to the public key instead, and have the actual key stored in 1Password.

Unfortunately it does not seem like the ssh configuration file supports writing out these public keys in-line, so you'll have to store these public keys on your system, and reference them here.

Configuring your system and Visual Studio Code

The default configuration for VSCode's remote containers is actually quite good, with all its defaults helping out what we want to achieve.

We just need to set one environment variable on a system-wide level (or just for Visual Studio Code, if you prefer) called SSH_AUTH_SOCK, which should also point to 1Password.

How you set this environment variable is dependend on your specific environment. If you're using the (usually default) bash environment, you can add the necessary bits to your ~/.bash_profile file like so:

❯ echo 'export SSH_AUTH_SOCK="$HOME/.1password/agent.sock"' >> ~/.bash_profile

Or if you're using Fish, you can add it as follows:

❯ set -gx SSH_AUTH_SOCK $HOME/.1password/agent.sock

If you are using another environment, please refer to its documentation to find the recommended way to set environment variables. As shown above, you'll want to set the variable called SSH_AUTH_SOCK to have the value of $HOME/.1password/agent.sock.

With this in place, you might have to encourage a reload of environment variables, or just log out and back in to have these changes take effect.

With all these changes in place, you should be able to use 1Password for signing Git commits (and SSH into remote servers) from within Visual Studio Code, even when using remote dev containers. Neat!

💡

If you are using the Visual Studio Code Flatpak release, some additional steps are necessary at this point. This is easy and straight-foward to do though, so fret not. I have written up a companion to this guide that covers all the necessary details.

As you can probably tell, these configurations are not just limited to Visual Studio Code. You'll be able to sign Git commits via command line too – or indeed any GUI application that correctly supports the relatively newer ssh signing format. I personally ended up adopting the GitLens Visual Studio Code extension into my workflow these days, which works quite nicely with this configuration.

I really like how powerful 1Password's SSH and Git signing functionality is. It lets me more easily log in to the servers I manage for clients, even if I'm not behind my main machine, as 1Password keeps everything nice and synchronized. And with the bits in place, I can do all this even within a dev container, which is really nice.

That's it for this one. If this ended up being useful for you, I would love to hear about it. If you have any recommendations for improvements, I'd love to hear that, too.

Thank you.