6

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.

chb
  • 283
  • 2
  • 12

2 Answers2

12

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?

chb
  • 283
  • 2
  • 12
  • 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 08: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 05:38
0

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 10.100.28.239

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. :)

Andrew Schulman
  • 8,811
  • 21
  • 32
  • 47
Josh
  • 101
  • 1