I receive a Could not open a connection to your authentication agent error message when I attempt to connect from an intermediate server to a third server using the agent forwarding option (-A) of an OpenSSH client. The first connection to the intermediate server goes smoothly using a key loaded into ssh-agent. The error message is displayed when attempting a connection to the final server.

My OpenSSH client is set to allow forwarding with ForwardAgent yes in ~/.ssh/config, and the intermediate server has AllowAgentForwarding yes in the daemon's configuration file. The client config is not overridden by a system level file.

I'm not using a terminal multiplexer in order to avoid an error stemming from environment variables not being set. To run the agent, I use exec ssh-agent zsh and verify that both SSH_AUTH_SOCK and SSH_AGENT_PID are present in the local environment. I use ssh-add to add the private keys for the intermediate and final server, respectively; I verify they are added with ssh-add -l.

All servers are of a recent version (OpenSSH 5.3) and the client is OpenSSH 6.2.


I'm posting this here because I spent a lot of time trying to find a solution using Google, reading man pages, and consulting a popular book on SSH, all to no avail.

The key to finding the problem was poring over the debugging output.

debug1: Remote: Agent forwarding disabled: mkdtemp() failed: Permission denied

The intermediate machine is a virtual server (RHEL 6.4) hosted by a cloud provider that uses an AWS stack. For reasons I can't explain, this is what permissions on the /tmp directory were set to:

drwxr-x--- 19  727  727  4096 Nov 28 05:30 tmp

Grep'ing through /etc/passwd I couldn't find a user with an ID of 727.

Correcting the permissions like so solved my woes:

sudo chown 0:0 /tmp
sudo chmod 1777 /tmp

Can anyone speak to the peculiar ownership of the /tmp directory?

| improve this answer | |
  • no idea why you had these permissions. 1777 permissions and root as owner should be standard for /tmp on all Linux distributions. A wild theory for the strange owner could be that someone was trying to issue chmod 727 tmp for whatever reason and did a chown 727 tmp instead... – etagenklo Nov 28 '13 at 11:32
  • I contacted the provider and they stated that all new instances have root as owner of /tmp. I'm thinking that, when I updated over 270MB of packages after initial boot, one of the relevant RPMs made the change. – chb Nov 29 '13 at 8:40
  • Good on ya for poring over the debugging output. This also resolved the issue I was having, same symptoms as yours. – Charney Kaye Aug 16 '15 at 5:38

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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