I've come across an interesting problem and I literally don't know where to start looking to resolve it!

The VCS machine in our office is running gitweb and my public key is on this machine fine. I can access the repositories from my machine without any problems, using my key.

However, if I am on any kind of remote shell, key authentication does not work! It falls back to password authentication, but the git user is configured to not have a password, so this is no good!

I have confirmed the problem by SSHing into another machine in the office and from there back into my machine. Also, by physically using another machine to SSH into my machine and even by going through a VPN to access my machine from a different network. In all cases, authentication with the git server fails although they are identical commands to those I run locally.

My first reaction was that gitosis (which automatically handles the keys) was misconfigured. It does include a number of additional security options on the keys:


However, the problem is confined to me - other machines seem to be able to authenticate without a problem whether the shell is remote or local, which suggests that it is my SSH that is misconfigured. I did change the default port away from 22 by editing /etc/ssh/sshd_config but everything else should be at the default values. It's possible someone else has edited the config, so any things to look out for would be appreciated!

My machine is running Ubuntu 9.04 (obviously, upgrading might be a solution). Really, I'm just after a starting point - something to google for to resolve the problem. If this is something simple that someone has come across before then that's fantastic but as I say, I'm really at a loss for now!

Thanks in advance!

  • What do you mean by "if I am on any kind of remote shell"
    – brent
    Nov 8, 2010 at 17:21
  • When you SSH to your machine, do you use the same user ID and username as you would have when you're using the machine directly (same uid and same $HOME)?
    – Bruno
    Nov 8, 2010 at 17:22
  • 1
    'ssh -vvv username@hostname' may be of use...
    – Marm0t
    Nov 8, 2010 at 19:32
  • I mean any shell that was opened from another physical machine. It's the same user and username, yes. I'm logging into my physical machine with my username (and password). From that state, I am failing to authenticate with the git server (via public key) even though a shell opened from the same physical machine (without need for login) authenticates as expected.
    – adamnfish
    Nov 9, 2010 at 1:27
  • I'll try -vvv at work, tomorrow!
    – adamnfish
    Nov 9, 2010 at 1:27

2 Answers 2


I'm unclear on your description of what keys and configuration files reside on what systems. However, if you are accustomed to being able to use your private key from a box to which you have not copied it, then you are doing so through use of SSH agent forwarding. Try removing 'no-agent-forwarding' from the option list that you quoted above and see if that resolves your problem.

  • Thanks for the answer, but I don't think this is the issue. I can use key authentication from a local shell (opened in the gui, but not when I've logged in externally). My key seems to be set up ok, given that it works fine from a locally opened shell.
    – adamnfish
    Nov 9, 2010 at 1:31

I had multiple keys in my ~/.ssh folder. Clearing out all of them but the main id_dsa key and re-adding that key to gitosis resolved the problem.

It's still a mystery why I was getting such strange behaviour! It must have been processing the keys differently via SSH / on a local shell. If anyone can shed any light on it, I'd be interested (I have the -v and -vvv output for local shells and remote SSH shells if you need it).

I wanted to add this in case someone else comes across the problem! (although it's very hard to search for, because there are so many questions on how to set up ssh keys at all)

Thanks very much to everyone who helped out.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .