How to Fix SSH Signing Failed: Agent Refused Operation

sign_and_send_pubkey: signing failed: agent refused operation means SSH found a candidate public key, but the connected agent would not use its private key to sign the authentication request. The key may be locked, absent from the active agent, restricted by confirmation or lifetime rules, stored on an unavailable hardware token, or exposed through a stale or inaccessible agent socket.

Confirm which key and agent are used

ssh -vvv user@example.com
printf '%s\n' "$SSH_AUTH_SOCK"
ssh-add -l

Verbose output distinguishes a key being offered from the agent refusing the signing operation. ssh-add -l should list fingerprints without exposing private key material.

If SSH_AUTH_SOCK is empty, SSH may be reading private key files directly. If it points to a nonexistent or inaccessible socket, the current shell may have inherited stale agent state.

Compare loaded and configured keys

ssh -G example.com | grep -E '^(identityfile|identitiesonly|identityagent) '
ssh-add -L

Compare fingerprints rather than copying full public keys into tickets or logs:

ssh-keygen -lf ~/.ssh/id_ed25519.pub
ssh-add -l

When IdentitiesOnly yes is active, ensure the intended IdentityFile is configured. When it is absent, too many agent keys can produce a different error: Too many authentication failures.

Check the agent socket and ownership

ls -l "$SSH_AUTH_SOCK"
stat "$SSH_AUTH_SOCK"
ps -ef | grep '[s]sh-agent'

The socket and agent should belong to the expected user. Problems commonly appear after using sudo, attaching to an old terminal multiplexer session, switching desktop sessions, or forwarding an agent through multiple hosts.

Do not change ownership or permissions on an unfamiliar socket. Start or reconnect to the correct user agent instead.

Reload an approved file-based key

If the key should be available from a local file:

ssh-add ~/.ssh/id_ed25519

Enter the passphrase only at the trusted local prompt. If the key was added with confirmation or a lifetime constraint, the agent may require user interaction or may have expired it.

Avoid copying private keys to remote servers to work around an agent problem.

Check hardware-backed keys

For FIDO, smart-card, PIV, or PKCS#11 keys, verify that the token is connected, unlocked, and available to the agent. Touch or PIN confirmation may be required. Inspect the key type without exposing private material:

ssh-add -l
ssh -Q key

Hardware middleware, desktop keychains, and agent implementations have different diagnostics. Restarting them can disrupt other sessions, so identify the active provider before changing state.

Diagnose forwarded-agent failures

On the remote host:

printf '%s\n' "$SSH_AUTH_SOCK"
ssh-add -l

Confirm forwarding is enabled only for the trusted hop that needs it. Agent forwarding lets the remote host request signatures from your local agent; a compromised remote host can abuse that access while the session is active.

If a terminal multiplexer retains an old forwarded socket after reconnecting, create a fresh session or update its environment using the multiplexer’s supported workflow.

Diagnose it with Rumus

Diagnose this SSH sign_and_send_pubkey agent refused operation error. Inspect the
verbose authentication sequence, effective IdentityFile and IdentityAgent settings,
loaded key fingerprints, SSH_AUTH_SOCK existence and ownership, agent process,
key lifetime or confirmation constraints, hardware-token availability, sudo or
tmux boundaries, and agent forwarding. Do not expose or copy private keys, reload
keys, restart agents, or change forwarding without approval.

Confirm the fix

ssh-add -l
ssh -vvv user@example.com

Confirm the intended fingerprint signs successfully and the server accepts it. Also verify that no unnecessary keys or agent-forwarding rules were enabled as part of the fix.