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.

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's-ssh-key@github.com

This does not work, however:

anderson@client -> root@remote -> anderson's-ssh-key@github.com

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;
SSH_AGENT_PID=75084; export SSH_AGENT_PID;
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
/tmp/launch-pg2gVc/Listeners

ssh key has been uploaded to GitHub and is working:

anderson$ ssh -T git@github.com
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
[root@host1~]#

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

**crickets**

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

[root@host1~]# ssh -T git@github.com
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
1  
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

1 Answer 1

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

 
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.