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.
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.
First, verify whether an SSH agent process exists:
ps aux | grep ssh-agentYou should see a line like:
user 12345 0.0 0.1 8192 1024 ? Ss 10:30 0:00 ssh-agentIf 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:
echo $SSH_AUTH_SOCKIt 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.
The most reliable way to start SSH agent in a new terminal session is:
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:
echo $SSH_AUTH_SOCK
ssh-add -lThe 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:
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):
ssh-add --apple-use-keychain ~/.ssh/id_ed25519 # older macOS: ssh-add -KOnce the agent is running, load your SSH private key:
ssh-add ~/.ssh/id_ed25519If your key has a different name or location:
ssh-add ~/.ssh/id_rsa
ssh-add ~/.ssh/github-keyYou'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:
ssh-add --apple-use-keychain ~/.ssh/id_ed25519Verify the key is loaded:
ssh-add -lShould show output like:
256 SHA256:abcdef... user@host (ED25519)To avoid running eval ssh-agent in every new terminal, add it to your shell startup file.
For bash, add to ~/.bashrc:
if [ -z "$SSH_AUTH_SOCK" ]; then
eval "$(ssh-agent -s)"
ssh-add ~/.ssh/id_ed25519 2>/dev/null
fiFor zsh, add to ~/.zshrc:
if [ -z "$SSH_AUTH_SOCK" ]; then
eval "$(ssh-agent -s)"
ssh-add ~/.ssh/id_ed25519 2>/dev/null
fiFor fish, add to ~/.config/fish/config.fish:
if not set -q SSH_AUTH_SOCK
eval (ssh-agent -c)
ssh-add ~/.ssh/id_ed25519 2>/dev/null
endThe condition [ -z "$SSH_AUTH_SOCK" ] ensures the agent is only started once per session. After adding this, reload your shell:
source ~/.bashrcOn 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.
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:
systemctl --user enable gcr-ssh-agent.socket
systemctl --user start gcr-ssh-agent.socketStep 2: Set SSH_AUTH_SOCK environment variable persistently:
mkdir -p ~/.config/environment.d
echo "SSH_AUTH_SOCK=$XDG_RUNTIME_DIR/gcr/ssh" > ~/.config/environment.d/ssh_auth.confStep 3: Log out and back in (or restart your desktop session) for changes to take effect.
Verify it's working:
echo $SSH_AUTH_SOCK
ssh-add -lSometimes SSH_AUTH_SOCK points to a different path than the actual agent socket.
Check what the agent is actually using:
ps aux | grep ssh-agent | grep -v grepAnd check what SSH_AUTH_SOCK is set to:
echo $SSH_AUTH_SOCKIf they don't match, try killing the agent and restarting it:
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:
[Service]
Environment="SSH_AUTH_SOCK=%t/ssh"Or set it in environment.d files:
echo "SSH_AUTH_SOCK=$XDG_RUNTIME_DIR/ssh" > ~/.config/environment.d/sshauth.confOn Windows, SSH agent setup is different.
Step 1: Start the SSH Agent service:
# Run PowerShell as Administrator
Set-Service ssh-agent -StartupType Automatic
Start-Service ssh-agent
Get-Service ssh-agentStep 2: Add your key using ssh-add:
ssh-add C:\Users\YourUsername\.ssh\id_ed25519Step 3: Verify it works:
ssh-add -lIf ssh-add still fails, ensure you're using Windows' native OpenSSH (not Git Bash's bundled version). Use the full path:
C:\Windows\System32\OpenSSH\ssh-add.exe -lIf that works but regular ssh-add doesn't, add the Windows OpenSSH directory to your PATH environment variable.
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:
ls -ld /tmp/ssh-*
ls -ld /run/user/1000The 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:
ssh -A remote.hostBe 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:
ssh -J bastion.host remote.host1Password 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:
ssh -vvv your.hostThis shows exactly where SSH is looking for the agent and which socket paths it's trying.
sign_and_send_pubkey: no mutual signature supported
How to fix "sign_and_send_pubkey: no mutual signature supported" in SSH
sign_and_send_pubkey: signing failed for RSA from agent: agent refused operation
How to fix "sign_and_send_pubkey: signing failed for RSA from agent: agent refused operation" in SSH
Bad owner or permissions on /home/user/.ssh/config
How to fix "Bad owner or permissions on .ssh/config" in SSH
No more authentication methods to try.
How to fix "No more authentication methods to try." in SSH
Error connecting to agent: Connection refused
How to fix "Error connecting to agent: Connection refused" in SSH