1Password SSH Agent Not Working | Fix SSH In Minutes

Guide / By

If 1Password SSH agent isn’t working, set the correct agent socket, keep 1Password running, and approve the SSH request when prompted.

When an SSH login or a Git fetch fails, the message can point in the wrong direction. The server might be fine. Your repo might be fine. The snag is often local: your SSH client can’t talk to an agent, or it’s talking to the wrong one.

This article walks you through a clean, repeatable fix path. You’ll start with quick checks, then lock in a stable socket configuration, then handle the two errors that trap most people: “could not open a connection” and “permission denied (public auth)”.

How The 1Password SSH Agent Fits Into SSH

SSH has three moving pieces on your machine. Your SSH client is the program that runs when you type ssh or when Git calls SSH behind the scenes. The agent is a background process that can answer authentication challenges. The identity material is stored somewhere safe.

With 1Password’s SSH agent, the private material stays inside the 1Password app, and the agent acts as the bridge. Your SSH client reaches the agent through a socket path. If the socket path is wrong, missing, or not reachable from the shell you’re using, authentication breaks.

So, most fixes come down to two questions. Is the agent running and reachable? Is your SSH client configured to use that agent?

Fast Checks Before You Edit Files

These checks take a minute and prevent you from chasing the wrong fix.

  • Open 1Password And Keep It Running — Make sure the desktop app is open and signed in, and set it to stay in the menu bar or tray so the agent keeps running in the background.
  • Confirm The SSH Agent Is Enabled — In the 1Password desktop app settings, go to the Developer area and confirm the SSH agent is turned on. The 1Password developer docs show the “Set Up SSH Agent” flow and the option to keep the app in the tray/menu bar so the agent stays active.
  • Test From The Same App That Fails — If Git fails inside an IDE terminal, test inside that same terminal. If it fails in a separate terminal, test there. Socket paths and exported variables can differ between apps.
  • Run A Verbose SSH Test — Use a verbose run to see what agent and identities SSH is trying. For GitHub, this is a common sanity check:
ssh -vT git@github.com

In the output, look for lines that show which agent path SSH is using and whether it’s offering too many identities or none at all.

1Password SSH Agent Not Working On Mac, Windows, Or Linux

If you only do one thing, do this: configure your SSH client to point at the 1Password agent socket path that 1Password documents. On Mac and Linux, the 1Password docs show using IdentityAgent ~/.1password/agent.sock in your SSH config as the clean default, and also mention that you can set SSH_AUTH_SOCK in the shell that runs your SSH command.

If you already set one of these in the past, verify it’s still correct. A lot of “1password ssh agent not working” reports trace back to a stale socket path after a reinstall, a shell change, or an app launch path that doesn’t inherit your exports.

Use An SSH Config Entry That Always Applies

Create or edit ~/.ssh/config. Add a host block that points to the agent socket:

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

This is simple, readable, and it stays consistent across shells. The 1Password “Get started” page shows this same pattern for configuring SSH clients.

Set SSH_AUTH_SOCK For A Single Session

If you want a fast test without changing config files, set the socket for the current shell session:

export SSH_AUTH_SOCK=~/.1password/agent.sock

Then rerun your SSH test in that same terminal. If that fixes the issue, your next step is to persist the config in ~/.ssh/config or ensure your login shell exports the variable for the apps you use.

Create A Stable Socket Shortcut

On some systems, the agent socket lives in a longer path, and 1Password’s docs mention using a symlink at ~/.1password/agent.sock so you have a short, stable target for config. If you already have the symlink, confirm it points to a real socket and not a dead file.

If you don’t know the real socket path on your machine, use the 1Password app’s SSH agent setup screen. It provides the intended snippet for your system, and it’s the safest source for the correct path.

Triage With A Symptom Table

This table matches the most common failure messages to the fixes that solve them.

What You See Likely Cause Fix That Usually Works
Could not open a connection to your authentication agent SSH can’t reach the agent socket Set IdentityAgent to ~/.1password/agent.sock or export SSH_AUTH_SOCK in the same shell
Permission denied (public auth) Wrong identity offered, or none offered Match host to a specific public identity file, then re-run with ssh -vT to verify what is offered
Too many authentication failures Server limits attempts and too many identities are offered Limit identities per host using SSH config, or use the 1Password agent config file ordering

Fix Permission Denied And Too Many Attempts

Once your client can talk to the agent, the next class of problems is “the wrong identity is being offered.” Servers often limit the number of tries per connection. The 1Password docs call out this “six identity limit” behavior and recommend matching identities to hosts so you don’t trigger authentication failures.

Match A Host To One Public Identity File

If you have more than one SSH identity, tell SSH which one to use for each host. You can do it with an explicit host block in ~/.ssh/config:

Host github.com
  HostName github.com
  User git
  IdentityAgent ~/.1password/agent.sock
  IdentityFile ~/.ssh/github_ed25519.pub

The private material stays in 1Password. The public identity file is safe to store locally and is what SSH uses to decide which identity to offer first.

Reduce What The Agent Offers

If you have a lot of identities stored in 1Password, you can control which ones the agent makes available, and in what order, using the 1Password SSH agent config file. 1Password documents the file location as ~/.config/1Password/ssh/agent.toml and explains that ordering affects what gets offered first.

This is the cleanest fix when you work with many accounts and hosts. It keeps your ~/.ssh/config tidy while preventing the “too many attempts” failure on strict servers.

Windows And WSL Gotchas

Windows can be smooth with 1Password’s agent, yet two issues show up more than anything else: a competing Windows agent service and mixed tooling across PowerShell, Git Bash, and WSL.

Disable The Built-In OpenSSH Agent Service

1Password’s SSH docs describe a Windows step where you check the “OpenSSH Authentication Agent” service and disable it so 1Password can listen on the system-wide pipe. If the Windows agent is running, your client might connect to the wrong agent, even if 1Password is set up correctly.

  • Open Services — Run services.msc using Win+R.
  • Find OpenSSH Authentication Agent — Select it and set Startup type to Disabled.
  • Stop The Service — If it’s running, stop it so 1Password can take over.

Use The 1Password WSL Integration When You Work In WSL

If you run Git and SSH inside WSL, use 1Password’s documented WSL integration. The 1Password developer docs state that the integration lets you authenticate SSH and Git commands inside WSL using the 1Password agent on the Windows host, and that it works with both WSL 1 and WSL 2.

In practice, this keeps the agent on the Windows side while WSL tools route requests through the integration. If you try to stitch together a Linux socket inside WSL without the integration, you can end up with a socket path that looks right yet never answers.

Keep The Setup Stable Day To Day

After you get a green test run, take ten minutes to make the fix stick so the next shell, IDE update, or reboot doesn’t bring the problem back.

  • Prefer IdentityAgent In ~/.ssh/config — It stays consistent across shells and matches 1Password’s documented setup approach.
  • Keep 1Password In The Tray Or Menu Bar — 1Password’s “Get started” docs include the setting to keep the app running so the agent continues in the background.
  • Limit Identities Per Host — If you touch multiple repos and servers, set host blocks so strict servers don’t reject you after too many tries.
  • Not Compatible Linux Packaging — 1Password notes that the SSH agent doesn’t work with Flatpak or Snap Store installs on Linux, so use an install method that allows the agent to run.

If you hit the “1password ssh agent not working” problem again after an app update, repeat the quick checks first. Confirm the agent is enabled, confirm the socket path, then rerun the verbose SSH test. That small loop finds most regressions fast.

Official Docs Worth Keeping Open

These pages map closely to the steps above and are the fastest way to confirm the current paths and settings.

If you still can’t authenticate after these steps, test from a fresh terminal session, then review your host’s authorized identities.