Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

UPDATE: the whole thing described below works fine for non-root accounts on the remote machine.

That is, this works:

anderson@client -> nonroot@remote -> anderson'

This does not work, however:

anderson@client -> root@remote -> anderson'

So the question is actually, how do I make ssh agent forwarding work when the machine in the middle is root?

Local machine (OSX) has forwarding turned on in the ~/.ssh/config file:

Host remotehost
    ForwardAgent yes

Local machine does not override this setting in /etc/ssh/ssh_config.

Host *
#   ForwardAgent no

Local machine is running ssh-agent:

anderson$ ssh-agent
SSH_AUTH_SOCK=/tmp/ssh-L0iFZ891Gv/agent.75083; export SSH_AUTH_SOCK;
echo Agent pid 75084;

ssh-add has been performed on the key:

anderson$ ssh-add -K ~/.ssh/id_rsa
Passphrase updated in keychain: /Users/anderson/.ssh/id_rsa
Identity added: /Users/anderson/.ssh/id_rsa (/Users/anderson/.ssh/id_rsa)

$SSH_AUTH_SOCK is there:

anderson$ echo $SSH_AUTH_SOCK

ssh key has been uploaded to GitHub and is working:

anderson$ ssh -T
Hi [elided]! You've successfully authenticated, but GitHub does not provide shell access.

Remote machine (Ubuntu 12.04LTS) has the public ssh key from the local machine and it works:

anderson$ ssh root@remotehost

Remote machine has AllowAgentForwarding configured:

[root@host1~]# head /etc/ssh/sshd_config
# Package generated configuration file
# See the sshd_config(5) manpage for details

AllowAgentForwarding yes

And here's where it goes pear-shaped: SSH_AUTH_SOCK is nowhere to be found on the remote:

[root@host1~]# echo $SSH_AUTH_SOCK


And of course key forwarding is nowhere to be found as well:

[root@host1~]# ssh -T
Permission denied (publickey).

Even forcing it like this doesn't work:

anderson$ ssh -A root@remotehost

Debug output:

anderson$ ssh -vvv -A root@remotehost
OpenSSH_5.6p1, OpenSSL 0.9.8r 8 Feb 2011
debug1: Reading configuration data /Users/anderson/.ssh/config
debug1: Applying options for remotehost
debug1: Applying options for *
debug1: Reading configuration data /etc/ssh_config
debug1: Applying options for *
debug1: auto-mux: Trying existing master
debug2: fd 3 setting O_NONBLOCK
debug2: mux_client_hello_exchange: master version 4
debug3: mux_client_request_forwards: requesting forwardings: 0 local, 0 remote
debug3: mux_client_request_session: entering
debug3: mux_client_request_alive: entering
debug3: mux_client_request_alive: done pid = 45287
debug3: mux_client_request_session: session request sent
debug1: mux_client_request_session: master session id: 3

So am I missing something? It seems to me I've covered all of the bases for debugging. Any ideas on what else I can check?

share|improve this question
Why are you sshing as root anyway? – EEAA Mar 1 '13 at 3:28
I knew someone would ask that. :-) Long story short, there's no good reason other than to change it right now would take more time than I have. Certainly before this goes production I want to have everything sorted into user accounts, but that's going to take a lot of work for reasons I won't get into right now. – Scott A Mar 1 '13 at 4:23

I had similar case, and the reason was that wrapper I was using was setting ControlPath option, and SSH also was stuck at debug1: mux_client_request_session: master session id: 3. Removing a directory specified in ControlPath has resolved the issue.

share|improve this answer

Your Answer


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.