The 1Password SSH Agent: Keys That Cannot Be Silently Stolen

The 1Password SSH agent replaces the default ssh-agent with one that keeps your private keys in your 1Password vault and asks for biometric approval every time a key is used. The security argument is simple and worth understanding: the standard ssh-agent will sign anything for any process running as your user, silently. If something nasty gets onto your laptop, it does not need to steal your key file - it just asks the agent to sign, and the agent says yes. The 1Password agent turns every signature into a prompt you have to approve.

What is actually wrong with the default agent
Enable the agent
Create a key that never touches the disk
Sign Git commits with the same key
The gotchas that will cost you an hour
Is it worth it
How this fits the rest of the stack
FAQ

What is actually wrong with the default agent

The normal setup is a private key sitting at ~/.ssh/id_ed25519, protected by a passphrase you type once per session. After that, ssh-agent holds the unlocked key in memory and signs on demand.

The part people miss: the agent has no idea which process is asking. Any code running as your user can talk to the agent socket and request a signature. It does not need your passphrase, because the key is already unlocked. It does not need to read the key file, so file permissions do not save you. There is no prompt, no log, and no way to tell it happened.

This is not a theoretical concern. A malicious npm postinstall script, a compromised VS Code extension, or any of the supply-chain attacks that have become routine can reach the agent socket. And if you use agent forwarding (ssh -A), root on the remote box can use your agent too - which is why forwarding to machines you do not fully trust is a bad habit.

The 1Password agent changes the model: the key lives in the vault, never on disk, and every signature request raises a prompt with Touch ID or Windows Hello. Malware can still ask. It just cannot get a yes without you.

Enable the agent

In the 1Password desktop app, open Settings, then Developer, and turn on Use the SSH agent. Turn on Display key names when authorising connections while you are there - without it, the approval prompt does not tell you which key is being used, which defeats a good chunk of the point.

Then point SSH at the agent socket. Add this to ~/.ssh/config:

Host *
  IdentityAgent "~/Library/Group Containers/2BUA8C4S2C.com.1password/t/agent.sock"

On Linux, the socket is at ~/.1password/agent.sock. On Windows, use the named pipe:

Host *
  IdentityAgent \\.\pipe\openssh-ssh-agent

Verify it worked:

ssh-add -l

You should see the keys from your vault listed. If you see error fetching identities, the socket path is wrong or the app is locked.

Create a key that never touches the disk

The cleanest path is to let 1Password generate the key, so the private half never exists as a file anywhere.

In 1Password, create a new item of type SSH Key and choose Ed25519 unless something in your infrastructure still demands RSA. Copy the public key out of the item.

Then put the public key on the server as usual - append it to ~/.ssh/authorized_keys on the target host, or paste it into GitHub under Settings, SSH and GPG keys.

Now connect:

ssh deploy@your-server

1Password prompts for biometric approval, signs the challenge, and you are in. There is no key file to leak, no passphrase to forget, and the key syncs to your other machines through the vault rather than being copied around by hand - which is how keys usually end up in three places you have forgotten about.

Sign Git commits with the same key

Since OpenSSH 8.2 and Git 2.34, you can sign commits with an SSH key instead of GPG, which is a substantial simplification. Combined with the 1Password agent, commit signing becomes a biometric prompt rather than a GPG configuration saga.

git config --global gpg.format ssh
git config --global user.signingkey "ssh-ed25519 AAAAC3Nz..."
git config --global commit.gpgsign true

Use the full public key string as the signingkey value. Then add the same key to GitHub a second time, as a Signing Key rather than an Authentication Key - GitHub treats the two roles separately, and a key registered only for auth will produce commits that show as unverified.

From then on, git commit raises a 1Password prompt and the commit lands with a verified badge. The nice property here is that the signing key cannot be exfiltrated by a compromised dependency in your own repo, which is exactly the threat model that makes commit signing worth doing in the first place.

The gotchas that will cost you an hour

Windows and the built-in OpenSSH service. If the Windows ssh-agent service is running, it fights with 1Password for the named pipe. Disable it: Stop-Service ssh-agent and set its startup type to Disabled. This is the single most common cause of a setup that will not work on Windows.

WSL. WSL cannot see the Windows named pipe directly. You need a relay - npiperelay plus a socat forward - to expose the agent inside the Linux environment. It works, but it is fiddly, and it is worth knowing before you start rather than after.

Headless and CI. The agent requires an unlocked desktop app with a human attached to approve prompts. It is a workstation tool. CI runners, cron jobs, and deploy servers still need a normal key or, better, a short-lived token issued by the platform. Do not try to make a biometric agent work on a build machine.

Agent forwarding. Forwarding the 1Password agent is safer than forwarding a normal one, because every use on the remote side still raises a prompt on your laptop. You will notice a request you did not make - which is the entire point.

Is it worth it

For a laptop that holds production access, yes, and the reasoning is not really about 1Password. It is that the default agent grants any local process a silent, unlimited signing oracle for as long as your session lasts, and most developers have never thought about that.

The honest limits: it is a paid product, it depends on a desktop app being unlocked, and the WSL story is annoying. It does nothing for your servers, your CI, or your automation - those still need real key management or, better, short-lived credentials.

But for the specific case of a human on a laptop with a key that can reach production, moving that key into a vault and putting a fingerprint in front of every use is a meaningful reduction in blast radius for roughly ten minutes of setup.

How this fits the rest of the stack

Whatever you decide here, the cost of the decision only shows up as a bill. The RunxBuild hosting calculator is the right place to model that before committing: the compute, the database, the storage, the bandwidth, the worker - each one is a separate line item, and the real cost of a platform is the sum, not the headline number. The RunxBuild dashboard is where the team sees the actual usage once it is running.

Useful related references:

FAQ

Does the 1Password SSH agent work with Git?

Yes, for both authentication and commit signing. Set gpg.format to ssh and use the public key as user.signingkey, then register the key on GitHub a second time as a signing key - GitHub tracks authentication keys and signing keys separately, and a key added only for auth produces unverified commits.

Can I use it in WSL?

Not directly. WSL cannot reach the Windows named pipe on its own, so you need a relay such as npiperelay with a socat forward to expose the agent inside the Linux environment. It works but it is the fiddliest part of the setup.

Does it work on CI or a headless server?

No. The agent needs an unlocked desktop app and a human to approve the biometric prompt, so it is a workstation tool. Build machines and deploy servers should use a dedicated key or short-lived platform credentials instead.

Why does ssh-add -l show nothing?

Either 1Password is locked, the SSH agent is not enabled under Settings and Developer, or the IdentityAgent path in your SSH config points at the wrong socket. On Windows, also check that the built-in ssh-agent service is stopped - it competes for the same named pipe.

Is storing SSH keys in a password manager actually safer?

For a laptop, yes. The default ssh-agent will sign anything for any process running as you, silently and without a prompt, so malware never needs to steal the key file. Moving the key into a vault behind biometric approval means a compromised dependency can request a signature but cannot get one.