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.

2 Answers 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?

  • 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, 2013 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, 2013 at 8:40
  • Good on ya for poring over the debugging output. This also resolved the issue I was having, same symptoms as yours. Aug 16, 2015 at 5:38

For anyone looking for the entire process to forward keys and get the debug logs along with fix it is as follows:

Create ~/.ssh/config

Host [IP of HOST]
    ForwardAgent yes

Run ssh-agent

eval "$(ssh-agent)"

Add the key you want forwarded to the ssh agent:

ssh-add [path to key if there is one]/[key_name].pem

Log into the remote host:

ssh -A -v [user]@[hostname]

view the debug logs upon ssh

debug1: Remote: Agent forwarding disabled: mkdtemp() failed: Permission denied
Last login: Tue Nov 10 22:57:07 2020 from

while logged into the remote machine view tmp permission. make sure the user has permission to access the tmp folder

ls -la /tmp/
sudo chown 0:0 /tmp
sudo chmod 1777 /tmp

my issue was I created a user to run the server under and that user did not have the permissions needed for the temp folder. I did not want to use root as that is not best practice. The fix was the same. :)

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .