Fixing “Could Not Open a Connection to Your Authentication Agent”

The error Could not open a connection to your authentication agent usually means your current shell cannot reach an SSH agent. It’s a local problem: your SSH client hasn’t reached the server yet.

The agent may not be running, the shell may not know where its socket is, or SSH_AUTH_SOCK may point to a socket that no longer works. The fix depends on which case you have—and on whether you’re using Linux, macOS, Windows, WSL, or Git Bash.

Check what your shell can reach

On Linux, macOS, WSL, or Git Bash, start with these checks:

echo "$SSH_AUTH_SOCK"
test -S "$SSH_AUTH_SOCK" && echo "socket exists"
ssh-add -l

Interpret the results in order:

• If SSH_AUTH_SOCK prints nothing, this shell has no agent socket configured.
• If the variable has a value but test -S prints nothing, it points to a socket that isn’t there—often because the agent exited.
• If ssh-add -l reports The agent has no identities, the agent is reachable; it just has no keys loaded.
• If ssh-add -l prints the original connection error, the shell still can’t talk to the agent.

test -S checks that the path is a Unix-domain socket. Finding an ssh-agent process with ps isn’t enough: an agent can be running in a different session, with a socket this shell can’t use.

For a deeper explanation of the agent and how SSH uses it, see how ssh-agent works.

Linux, WSL, and Git Bash: start an agent in this shell

If the socket variable is empty or stale, start an agent and add your key:

eval "$(ssh-agent -s)"
ssh-add ~/.ssh/id_ed25519

The ssh-agent -s command prints shell commands that set variables such as SSH_AUTH_SOCK. eval runs those commands in your current shell, which is what makes the agent reachable there. Without eval, the commands are only printed; your shell’s environment doesn’t change.

This setup is tied to the shell where you run it. A new terminal tab, a new login session, or a shell started through another tool may not inherit the agent variables. If the error returns in a different shell, check SSH_AUTH_SOCK there rather than assuming the key disappeared.

If you’re trying to connect with a particular key and don’t need an agent, OpenSSH can use the key file directly with ssh -i. Here’s a practical guide to connecting with a private key.

macOS: check before starting another agent

A typical macOS login session already has an agent managed by launchd. Check whether your shell has its socket before starting a new agent:

echo "$SSH_AUTH_SOCK"
ssh-add -l

If the variable is missing, look for something that may have removed or replaced it, such as a shell startup file or a container that doesn’t inherit the login environment. If you confirm that no usable agent is available, the same eval "$(ssh-agent -s)" command can start one for the current shell.

To load a passphrase-protected key into the macOS Keychain, use:

ssh-add --apple-use-keychain ~/.ssh/id_ed25519

Windows: identify which SSH environment you’re using

Windows OpenSSH, Git Bash, and WSL don’t necessarily share an agent or loaded keys. A key added in one environment may not appear in another, so check the shell where the command fails.

Native PowerShell or Command Prompt

Native Windows OpenSSH uses the OpenSSH Authentication Agent Windows service. From an elevated PowerShell prompt, check and start it like this:

Get-Service ssh-agent
Set-Service -Name ssh-agent -StartupType Automatic
Start-Service ssh-agent
ssh-add $env:USERPROFILE\.ssh\id_ed25519

Get-Service shows whether the service is running, stopped, or disabled. Unlike the Unix-style shell setup, this uses a Windows service; there’s no eval step.

Git Bash and WSL

Git Bash and WSL use Unix-style shells, so the Linux commands apply in each environment:

eval "$(ssh-agent -s)"
ssh-add ~/.ssh/id_ed25519

If a key appears to be loaded in one environment but not another, check which SSH tools the failing shell is using. In Git Bash, run which ssh and which ssh-add; in PowerShell, run Get-Command ssh. Different SSH clients or agent sockets can explain why the key isn’t visible.

Watch out for sudo

A command that works as your regular user may fail under sudo with the same agent error. sudo switches to root’s environment, which generally doesn’t include your user’s SSH_AUTH_SOCK.

Usually, the better fix is to run ssh or ssh-add as your normal user rather than passing your agent socket into a root environment. SSH keys and agents are generally intended to belong to the user who owns them.

Confirm the key is loaded

After fixing the agent connection, check again:

ssh-add -l

If it lists a fingerprint, the agent can see the loaded key. If it says The agent has no identities, add the key explicitly:

ssh-add ~/.ssh/id_ed25519

If the agent is reachable but SSH later reports Permission denied (publickey), that’s a different stage of the connection: the client reached the server, but authentication wasn’t accepted. Don’t keep restarting the agent—check which key and username SSH is using, and whether the server has the corresponding public key.

The main diagnostic is simple: check whether the current shell has a socket, whether that socket exists, and whether ssh-add -l can talk to it. Then use the fix that matches your environment.

I originally published a more detailed version of this guide on the SSHFlow blog.

I'm also building SSHFlow — an SSH client where every server gets its own workspace for terminals, SFTP, code, and databases.