gitolite: can connect via ssh, can't clone

问题:

I installed gitolite on my server using this tutorial. This falls under the "non-root" method.

It fails when I try to clone gitolite-admin back to my client. I get this error message:

git clone [e-mail]:gitolite-admin
Cloning into gitolite-admin...
fatal: The remote end hung up unexpectedly

Also:

git clone ssh://[e-mail]:gitolite-admin
Cloning into gitolite0admin...
Using username "git-upload-pack 'gitolite".
fatal: The remote end hung up unexpectedly

I have also tried appending .git to the end of the repo name, and I have also tried adding repositories/gitolite-admin (suggested by the errors in the tutorial linked above) and a combination of both of these and none work. I can find no results on google regarding the "Using username" bit, which intrigues me.

I can connect to the machine via ssh, and it tells me that I have access to R and W gitolite-admin. So, SSH is working?

回答1:

Check the ssh parts about gitolite: the fact that you can connect to server.com through ssh only means:

• your ssh key is registered in server.com@~/.ssh/authorized_keys
• that key isn't related to gitolite 'there is no "command=" option, which means "regardless of what the incoming user is asking to do, forcibly run this command instead").
  You are in an interactive session, able to execute any command you like.

What I don't like at all about the third-party tutorial is that it tries using the same name for git user and ssh non-root user

You should keep separate:

• the non-root user (which isn't an account, just an ssh key, which will be linked to gitolite, with admin privileges to the gitolite-admin repo)
• the hosting account, which should be 'git', not gitolite, precisely to avoid confusion between the two usage mode:
  • git (log on directly on server.com, no ssh here): interactive session needed to execute git command (like cloning on the server the gitolite repo, and executing gitolite/src/gl-system-install)
  • ssh [e-mail] which will use your ~/.ssh/id_rsa(.pub) public and private keys, which, being the ones of the gitolite, will authorize you to clone the gitolite-admin repo and push back that repo

Again:
'gitolite' is not a true account, only a name authorized to execute commands on server.com as 'git' (the actual "hosting account", as in "hosting git services and repos").
All the other git users will also execute git commands on server.com as git.
And that particular user (gitolite) will be linked to gitolite authorization layer through the forced-command mechanism, with privileges setup during the gitolite installation in order to grant that 'user' rights to clone, modify and push back gitolite-admin repo.
(That is its only particularity compared to all the other ssh git users you will add: they won't have access to that specific git repo which is the gitolite-admin one)

Trying to name the two with the same name is just asking for trouble.

I don't like using the default naming convention for the public/private keys, so I prefer on the client defining those keys with the name of the intended user:

~/.ssh/gitolite.pub
~/.ssh/gitolite

Then I define a config file: ~/.ssh/config with in it:

host gitolite
     user git
     hostname server.com
     identityfile ~/.ssh/gitolite

(Note the user here: always git)
Then I can clone my gitolite-amin repo:

git clone gitolite:gitolite-admin
# modify locally
# git add -A ; git commit -m "my modifs"
git push origin master

回答2:

For posterity, the fix is to make sure that GIT_SSH is not set to TortoisePlink.exe. Git can't use it.