Super User is a question and answer site for computer enthusiasts and power users. 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

This query isn't directly related to Git, but since one of Git's supported transports is SSH, and I'm trying to use agent-forwarding, I thought I would ask for clarification (the man pages have let me down)

I'm trying to automate a software deployment using Capistrano, I've managed to suspend some of the pain-points (pre-seeding the known hosts, before deployment, etc), but I'm left with the following situation.

My team log into the server as themselves, individual user accounts, everyone is in a developers group, and the umask is 002. None of the above is really relevant, except to say the purpose is to make sure my team can always work as themselves, without requiring super user privilieges.

We connect to the server using the following ~/.ssh/config:

  User beaks
  ForwardAgent yes
  IdentityFile ~/.ssh/id_rsa_business

The initial login works perfectly, ssh opens a connection to my user account, and all is in order.

The problem comes at the next step,

git ls-remote

This is using the aforementioned Git+SSH transport layer (see link above) - and should typically use my forwarded-agent key (which I have verified present with env | grep SSH_AUTH_SOCK)

The response is a simple "authentication failed (public key) the other end hung up unexpectedly", I suspect because the agent for my user isn't being used when I approach as their shared git user.

I also can't rule out EC2 weirdness (security policies, etc) - but in that case, I would have expected a timeout or connection failure. I feel pretty confident that I'm hitting - and that they're not letting me in, because my agent isn't offering my beaks key for their git user.

Happy to add any additional information if I missed anything.

share|improve this question
Re "which I have verified present": All you have verified is presence of a SSH agent socket. Use ssh-add -l to make sure you've actually got some keys in it. – grawity Mar 8 '11 at 21:33
Also, FYI, usernames are completely irrelevant for agent forwarding, so that is not a problem. – grawity Mar 8 '11 at 21:33
up vote 6 down vote accepted

Simply seeing that ssh-agent is running is insufficient. Look to see if the key you want is present ssh-add -L Have you verified that this key works from some other host? What does ssh-add -L print on that system?

You can also run GIT_TRACE=1 git ls-remote ... and it will print the ssh command it runs. You can manually run the ssh command and get that working before bringing git into the picture.

share|improve this answer
I'd forgotten about this question, it turns out that the agent didn't have the key, although I was getting passphraseless access to the key, because of OSX passphrase caching (unrelated to storing the key in the agent) - thus my confusion. – Lee Hambley May 24 '11 at 21:19

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.