Take the 2-minute tour ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

This is a generic question, of how to diagnose the error in the following SSH login trace. However, I've pasted specific details to exemplify the problem.

The main problem statement:

When using "ssh -A" to forward keys from one machine to another, the ssh connections inside the target machine may fail with permission denied errors. However, it is tricky to interpret the output of "ssh -v" command (that is - its not clear in the case where a machine has its own id_rsa.pub file, how it is that the ssh -A works ... does it try to use both public keys? or just one of them?)

Some details on the ssh setup

I have a machine "A" , with a VM "B" running in it (fedora 16).

On A , I run

A> ssh root@B

Then, on B, If i invoke "ssh-agent" , I get the following output

B> ssh-agent SSH_AUTH_SOCK=/tmp/ssh-ZJRIzYHw1418/agent.1418; export SSH_AUTH_SOCK; SSH_AGENT_PID=1419; export SSH_AGENT_PID; echo Agent pid 1419;

Finally, not sure if this is important, but , BOTH machines A and B have their own .ssh directories with id_rsa.pub keys. Is that making "ssh -A" fail (i.e. is ssh smart enough to try all available public keys?)

Debug trace

>ssh -v git@github.com
OpenSSH_5.8p1, OpenSSL 1.0.0j-fips 10 May 2012
debug1: Reading configuration data /root/.ssh/config
debug1: Applying options for *
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Connecting to github.com [] port 22.
debug1: Connection established.
debug1: permanently_set_uid: 0/0
debug1: identity file /root/.ssh/id_rsa type 1
debug1: identity file /root/.ssh/id_rsa-cert type -1
debug1: identity file /root/.ssh/id_dsa type -1
debug1: identity file /root/.ssh/id_dsa-cert type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.5p1 Debian-6+squeeze1+github12
debug1: match: OpenSSH_5.5p1 Debian-6+squeeze1+github12 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.8
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-md5 none
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Server host key: RSA 16:27:ac:a5:76:28:2d:36:63:1b:56:4d:eb:df:a6:48
debug1: Host 'github.com' is known and matches the RSA host key.
debug1: Found key in /root/.ssh/known_hosts:10
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: Roaming not allowed by server
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /root/.ssh/id_rsa
debug1: Authentications that can continue: publickey
debug1: Trying private key: /root/.ssh/id_dsa
debug1: No more authentication methods to try.
Permission denied (publickey).
share|improve this question

1 Answer 1

The trouble here is that you're not invoking ssh-agent correctly. Its output is intended to be interpreted by your shell, in order to set the environment variables the OpenSSH client programs use to detect and communicate with the SSH agent. Since you're not doing that, ssh -A doesn't realize there is an agent present with which to communicate; it's offering ~/.ssh/id_rsa et al. because they exist and that's where ssh will look for default private keys, and not for any reason related to the SSH agent which ssh doesn't know is there.

Invoke ssh-agent thusly:

[me@box] ~ $ eval `ssh-agent`

and you should get the intended result from ssh -A.

share|improve this answer
(Editing comment) this makes sense according to the logs. But I don't recall doing this eval trick on other machines which work fine with -A forwarding –  jayunit100 May 24 '13 at 20:09
There I can't help you; I haven't used an SSH agent in years, and no longer have one configured. Presumably, you'd see the client offering keys known to the agent; if the only keys known to the agent are those which ssh would find and offer by default in any case, I'm not sure what the difference would be. –  Aaron Miller May 24 '13 at 20:12

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.