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 example.com using the following ~/.ssh/config:

Host example.com
  User beaks
  ForwardAgent yes
  IdentityFile ~/.ssh/id_rsa_business

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

The problem comes at the next step,

git ls-remote git@github.com:project/repository.git

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 github.com 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 github.com - 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.

  • 2
    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.
    – user1686
    Mar 8 '11 at 21:33
  • Also, FYI, usernames are completely irrelevant for agent forwarding, so that is not a problem.
    – user1686
    Mar 8 '11 at 21:33

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.

  • 2
    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. May 24 '11 at 21:19

No one actually answered this question so people coming here may benefit to seeing my answer to a similar question. https://superuser.com/a/1141035/3376

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.