How to fix Error connecting to agent: No such file or directory in SSH

SSHBEGINNERMEDIUMUpdated May 28, 2026· 346 views

This error appears when SSH tools like ssh-add try to reach the SSH agent, but SSH_AUTH_SOCK points to a missing or inaccessible socket. Usually the agent isn't running or the path is wrong.

Quick fix

Fixes Error connecting to agent: No such file or directory

ps aux | grep ssh-agent
  1. Check if SSH agent is running
  2. Start SSH agent with eval
  3. Add your SSH private key to the agent
  4. Make SSH agent persistent across sessions (Linux/Mac)
ssh — error
ps aux | grep ssh-agent
Error connecting to agent: No such file or directory

What this error means

SSH agent is a background service that holds your unencrypted SSH private keys and performs authentication on your behalf. SSH clients (like ssh, ssh-add, git) communicate with the agent through a Unix socket file specified by the SSH_AUTH_SOCK environment variable. When this error appears, it means the SSH command tried to contact the agent at the socket path in SSH_AUTH_SOCK, but that file doesn't exist or can't be accessed. This usually happens because the agent was never started, crashed, or the environment variable points to the wrong location.

Typical symptoms

  • ssh-add -l returns 'Error connecting to agent: No such file or directory'
  • Git SSH operations fail with agent connection error
  • SSH key operations in IDEs (VS Code, etc.) fail silently
  • SSH_AUTH_SOCK environment variable is set but empty or incorrect
  • Works in some terminal windows/sessions but not others
  • Recent system update or terminal restart broke SSH

Common causes

  1. SSH agent is not running in the current terminal session
  2. SSH_AUTH_SOCK environment variable points to a nonexistent socket file
  3. SSH agent crashed or was terminated unexpectedly
  4. Socket file path mismatch (e.g., /run/user/1000/ssh-agent.socket vs .sock)
  5. GNOME Keyring or similar service disabled SSH agent functionality without setting correct environment variables
  6. SSH_AUTH_SOCK inherited from a parent session where the agent was killed
  7. Running SSH tools in a subprocess or different shell without proper environment propagation
  8. File permissions on socket directory prevent SSH client from accessing it
  9. SSH agent is running but using a different socket path than what SSH_AUTH_SOCK specifies

How to fix "Error connecting to agent: No such file or directory"

1Check if SSH agent is running

First, verify whether an SSH agent process exists:

bash
ps aux | grep ssh-agent

You should see a line like:

bash
user  12345  0.0  0.1  8192  1024 ?  Ss  10:30  0:00  ssh-agent

If no ssh-agent process appears, the agent is not running. Proceed to step 2 to start it.

If the agent is running, check the SSH_AUTH_SOCK variable:

bash
echo $SSH_AUTH_SOCK

It should output something like /tmp/ssh-XXXXXXXXXX/agent.12345 or /run/user/1000/ssh-agent.socket. If it's empty or unset, proceed to step 2.

2Start SSH agent with eval

The most reliable way to start SSH agent in a new terminal session is:

bash
eval "$(ssh-agent -s)"

This command:
1. Starts a new SSH agent process
2. Outputs shell commands to set environment variables (SSH_AUTH_SOCK, SSH_AGENT_PID)
3. eval executes those commands in your current shell

After running this, verify it worked:

bash
echo $SSH_AUTH_SOCK
ssh-add -l

The second command should return either your loaded keys or "The agent has no identities" (which is fine—it just means no keys are loaded yet).

On macOS and BSD, the same command works:

bash
eval "$(ssh-agent -s)"

Note: ssh-agent does not have a -K flag. (-k lowercase *kills* a running agent, and -K is an ssh-add option on macOS, not an ssh-agent option.) On macOS you usually don't even need to start the agent manually—launchd starts one automatically and sets SSH_AUTH_SOCK to a path under /private/tmp/com.apple.launchd.*/Listeners. To store a key passphrase in the macOS Keychain when adding the key, use the ssh-add flag instead (see step 3):

bash
ssh-add --apple-use-keychain ~/.ssh/id_ed25519   # older macOS: ssh-add -K
3Add your SSH private key to the agent

Once the agent is running, load your SSH private key:

bash
ssh-add ~/.ssh/id_ed25519

If your key has a different name or location:

bash
ssh-add ~/.ssh/id_rsa
ssh-add ~/.ssh/github-key

You'll be prompted for the key's passphrase (if it has one). After entering it, the key is now loaded in the agent.

On macOS, add --apple-use-keychain to store the passphrase in the Keychain so you aren't prompted on future logins:

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

Verify the key is loaded:

bash
ssh-add -l

Should show output like:

bash
256 SHA256:abcdef... user@host (ED25519)
4Make SSH agent persistent across sessions (Linux/Mac)

To avoid running eval ssh-agent in every new terminal, add it to your shell startup file.

For bash, add to ~/.bashrc:

bash
if [ -z "$SSH_AUTH_SOCK" ]; then
  eval "$(ssh-agent -s)"
  ssh-add ~/.ssh/id_ed25519 2>/dev/null
fi

For zsh, add to ~/.zshrc:

zsh
if [ -z "$SSH_AUTH_SOCK" ]; then
  eval "$(ssh-agent -s)"
  ssh-add ~/.ssh/id_ed25519 2>/dev/null
fi

For fish, add to ~/.config/fish/config.fish:

fish
if not set -q SSH_AUTH_SOCK
  eval (ssh-agent -c)
  ssh-add ~/.ssh/id_ed25519 2>/dev/null
end

The condition [ -z "$SSH_AUTH_SOCK" ] ensures the agent is only started once per session. After adding this, reload your shell:

bash
source ~/.bashrc

On macOS, prefer letting launchd manage the agent and use ssh-add --apple-use-keychain plus an ~/.ssh/config entry (AddKeysToAgent yes, UseKeychain yes) instead of starting ssh-agent in your shell rc file.

5Fix GNOME Keyring SSH issues (Linux)

On some Linux desktops, GNOME Keyring stopped providing the SSH agent by default, so SSH_AUTH_SOCK is never set.

Step 1: Enable the gcr-ssh-agent socket:

bash
systemctl --user enable gcr-ssh-agent.socket
systemctl --user start gcr-ssh-agent.socket

Step 2: Set SSH_AUTH_SOCK environment variable persistently:

bash
mkdir -p ~/.config/environment.d
echo "SSH_AUTH_SOCK=$XDG_RUNTIME_DIR/gcr/ssh" > ~/.config/environment.d/ssh_auth.conf

Step 3: Log out and back in (or restart your desktop session) for changes to take effect.

Verify it's working:

bash
echo $SSH_AUTH_SOCK
ssh-add -l
6Fix socket path mismatch (systemd user service)

Sometimes SSH_AUTH_SOCK points to a different path than the actual agent socket.

Check what the agent is actually using:

bash
ps aux | grep ssh-agent | grep -v grep

And check what SSH_AUTH_SOCK is set to:

bash
echo $SSH_AUTH_SOCK

If they don't match, try killing the agent and restarting it:

bash
pkill ssh-agent
eval "$(ssh-agent -s)"

For systemd user service setup, if you're using a service unit, ensure your SSH_AUTH_SOCK is correctly set. For example, add to your service unit file:

ini
[Service]
Environment="SSH_AUTH_SOCK=%t/ssh"

Or set it in environment.d files:

bash
echo "SSH_AUTH_SOCK=$XDG_RUNTIME_DIR/ssh" > ~/.config/environment.d/sshauth.conf
7Fix Windows OpenSSH issues

On Windows, SSH agent setup is different.

Step 1: Start the SSH Agent service:

powershell
# Run PowerShell as Administrator
Set-Service ssh-agent -StartupType Automatic
Start-Service ssh-agent
Get-Service ssh-agent

Step 2: Add your key using ssh-add:

bash
ssh-add C:\Users\YourUsername\.ssh\id_ed25519

Step 3: Verify it works:

bash
ssh-add -l

If ssh-add still fails, ensure you're using Windows' native OpenSSH (not Git Bash's bundled version). Use the full path:

powershell
C:\Windows\System32\OpenSSH\ssh-add.exe -l

If that works but regular ssh-add doesn't, add the Windows OpenSSH directory to your PATH environment variable.

Advanced notes

Advanced troubleshooting:

SSH_AUTH_SOCK Socket Directory Permissions: The socket file exists in a directory that must have correct permissions. Typically in /tmp or /run/user/1000. If you see "Permission denied" instead of "No such file", check directory ownership:

bash
ls -ld /tmp/ssh-*
ls -ld /run/user/1000

The directory should be owned by your user with 700 permissions.

SSH Agent in SSH Tunnel/Remote Session: If you're SSH'ing into a remote machine and want to use your local keys, you can forward the agent with the -A flag:

bash
ssh -A remote.host

Be aware that agent forwarding is a security trade-off: anyone with root on the remote host (or who can read your forwarded socket) can use your loaded keys to authenticate as you elsewhere while your session is open. Only forward to hosts you fully trust, and prefer ProxyJump for reaching a host through a bastion:

bash
ssh -J bastion.host remote.host

1Password SSH Agent: If using 1Password for SSH key management, ensure the 1Password SSH agent socket is correctly symlinked and SSH_AUTH_SOCK points to it. Refer to 1Password documentation for your platform.

Terminal Multiplexers (tmux/screen): When creating new panes/windows in tmux or screen, the environment variables from your original shell may not be inherited. Fix this by explicitly setting SSH_AUTH_SOCK in your multiplexer config or by sourcing your shell startup file.

Debugging: To see detailed SSH debugging output, run ssh with verbose flag:

bash
ssh -vvv your.host

This shows exactly where SSH is looking for the agent and which socket paths it's trying.

Frequently asked questions

What does "Error connecting to agent: No such file or directory" mean?
SSH agent is a background service that holds your unencrypted SSH private keys and performs authentication on your behalf. SSH clients (like ssh, ssh-add, git) communicate with the agent through a Unix socket file specified by the SSH_AUTH_SOCK environment variable. When this error appears, it means the SSH command tried to contact the agent at the socket path in SSH_AUTH_SOCK, but that file doesn't exist or can't be accessed.
How do I fix "Error connecting to agent: No such file or directory"?
This error appears when SSH tools like ssh-add try to reach the SSH agent, but SSH_AUTH_SOCK points to a missing or inaccessible socket. Usually the agent isn't running or the path is wrong.
What causes "Error connecting to agent: No such file or directory"?
SSH agent is not running in the current terminal session SSH_AUTH_SOCK environment variable points to a nonexistent socket file SSH agent crashed or was terminated unexpectedly
Is the "Error connecting to agent: No such file or directory" error serious?
It is a medium-severity error — more of a blocker than a risk. The steps above resolve it.

Official resources & further reading