Stop "Permission denied (publickey)" errors by fixing SSH agent socket permissions

You’re trying to deploy via a bastion host using ssh -A user@bastion, but the connection to the target server fails with Permission denied (publickey). The keys are correct, the authorized_keys file is right, but the agent on the bastion simply won’t forward the socket because its permissions are too loose for the remote SSH daemon to accept.

The 5-minute setup

First, verify the current state of your agent socket. Run this on your local machine (or the machine initiating the SSH chain):

ls -la ~/.ssh/agent.sock

You should see permissions like srw------- (600). If you see srwxr-xr-x or similar, the socket is world-readable or group-writable, which causes OpenSSH to reject the forwarding attempt for security reasons.

To fix this immediately without restarting your shell, use ssh-add to reset the agent environment and ensure the socket is created with strict permissions. However, the most robust fix is ensuring your ~/.ssh directory and the socket itself are owned by you and have no group/other write permissions.

Run these commands to harden the environment:

# Ensure the .ssh directory is 700
chmod 700 ~/.ssh

# Remove any existing socket (it will be recreated by the agent)
rm -f ~/.ssh/agent.sock

# Restart the SSH agent to regenerate the socket with default secure permissions
# (This assumes you are using a standard systemd user service or systemd --user)
systemctl --user restart ssh-agent

# Verify the new socket permissions
ls -la ~/.ssh/agent.sock

If you are not using systemd for the agent (e.g., you started it manually in your .bashrc or .zshrc), kill the existing agent and restart it:

eval "$(ssh-agent -s)"

Now, test the forwarding again. When connecting to the bastion, explicitly forward the agent:

ssh -A user@bastion

Once logged into the bastion, verify the agent socket is now present and accessible:

ls -la ~/.ssh/agent.sock
# Should show srw------- and be owned by your user

Then, try connecting to the target:

ssh user@target-server

Why it works

The SSH agent communicates via a Unix domain socket. For ssh -A to work, the remote SSH daemon must be able to connect to this socket. However, for security, the SSH client only allows agent forwarding if the socket’s permissions are strict (typically 0600). If the socket is group- or world-writable, the SSH client silently disables forwarding or the remote daemon rejects the connection because it cannot safely bind to a potentially compromised socket. By resetting the agent and ensuring the ~/.ssh directory is 700, you guarantee the socket is created with the correct restrictive permissions, allowing the secure forwarding mechanism to function.

Pro Tip

If you’re using ssh -A frequently and still face issues, check if AllowAgentForwarding is enabled on the bastion host. On the bastion, edit /etc/ssh/sshd_config and ensure:

AllowAgentForwarding yes

Then reload the service: sudo systemctl reload sshd. Many production bastions disable this by default, which causes the same "Permission denied" error even with perfect local permissions. You can verify this remotely with:

ssh user@bastion "grep -i AllowAgentForwarding /etc/ssh/sshd_config"