Home / server / Questions / 392825
Accepted
cmckendry
Asked: 2012-05-26 16:39:15 +0800 CST

Recurring "agent admitted failure to sign using the key" error with passwordless SSH

  • 772

One of the machines on my network (Mint 12 workstation, up to date) periodically gets into a bad state wherein all outgoing SSH connections fall back to password authentication with the error "agent admitted failure to sign using the key" instead of using the key-based authentication which has been configured.

Once it's in this state it will fail 100% of the time for all outgoing connections. Incoming key-based authentication appears to connect normally. I have tried deleting and regenerating the keypair and redistributing the public key, but the error persists.

A reboot will temporarily resolve the error, but it comes back again in a few days. Doesn't seem to coincide with any particular event/workflow, but I might be missing something.

Has anyone else seen this?

linux ssh linuxmint

1 Answers

  1. Best Answer

    The "agent" here is ssh-agent, a program that loads the private key into memory and holds it for future ssh connections to use so you don't have to retype the password. It looks like somewhere along the line, it is being commanded to forget the key (are you suspending to disk/hibernating? That might do it to prevent the unencrypted key from being written to disk) or has a bug that causes it to forget the key. Either way, ssh-add should allow you to add the key back to the agent.

    I'm fairly certain you'd be getting a different error message if ssh couldn't talk to ssh-agent for some reason. If ssh-add says it can't open a connection to your authentication agent, then the real problem is that it stopped running, or the environment variables that tell ssh how to get in touch with the agent have gone missing, or that the socket file has disappeared. If the environment variables $SSH_AUTH_SOCK and $SSH_AGENT_PID are both still set when this is happening (with echo $SSH_AGENT_PID), make sure the ssh-agent process referenced by $SSH_AGENT_PID is still running, and if so, that the socket file at $SSH_AUTH_SOCK is still there. It could be that you have an agressive /tmp cleaning process that is removing the socket.

    • 2