Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

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?

share|improve this question

1 Answer 1

up vote 2 down vote accepted

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.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.