users are asked for password while using gitolite - gitolite

Question

I have successfully created gitolite-admin.git repo on server (say) 10.107.105.13. I can clone this repo on my local machine (say) 10.14.42.7 by issuing git clone gitolite#10.107.105.13:gitolite-admin. I had to add some lines in .ssh/config file to make sure that correct private key is used.
Then I have added a user dilawar to conf/gitolite.conf file and a appropriate key dilawar.pub to keys folder. I have added and commited this commit to the gitolite-admin repo. I have also added one more entry in .ssh/conf file so that a correct private key is used. But when I try to do git clone dilawar#10.107.105.13:testing, gitolite asks for the password. I am under the impression that I do not have to create user dilawar on 10.107.105.13. I have checked by logging into server that repository testing.git exists as well public-key dilawar.pub has been added to .ssh/authorized_keys.
I have also tried ssh -vvvv dilawar#10.107.105.13 to check if the correct file is being offered. Here is my .ssh/conf file.
HostName 10.107.105.13
User gitolite
IdentityFile ~/.ssh/gitolite
Host 10.107.105.13
HostName 10.107.105.13
User dilawar
IdentityFile ~/.ssh/id_rsa
What I am doing wrong?

Answer 1

In your config file, I see:
User dilawar
That is wrong. ssh communication to a gitolite server are always done with the same account (here gitolite).
What changes is the private key used, which will help gitolite determine your identity.
What you ~/.ssh/config file should look like is:
Host admin
HostName 10.107.105.13
User gitolite
IdentityFile ~/.ssh/gitolite
Host dilawar
HostName 10.107.105.13
User gitolite
IdentityFile ~/.ssh/id_rsa
For cloning gitolite-admin, you would use:
git clone admin:gitolite-admin
For cloning a repo dilawar has access to:
git clone dilawar:aRepo
See more at "Gitolite: adding user not working, and DENIED by fallthru when cloning as root?".
See also "how gitolite uses ssh"
Adding your public key to the server's ~git/.ssh/authorized_keys file is how ssh uses pubkeys to authenticate users.
Let's say sita#work.station is trying to log in as git#server.
What you have to do is take the ~sita/.ssh/id_rsa.pub file for user sita on work-station and append its contents (remember it's only one line) to ~git/.ssh/authorized_keys for user git on server.
The authorized_keys file can have multiple public keys (from many different people) added to it so any of them can log in to git#server.

Answer 2

I have got it working by cloning the repository using the gitolite username.
git clone gitolite#server:repo
If keys are added successfully then further pull and push will go smoothly.
I am accepting VomC answer as a better answer.

Answer 3

VonC's answer is the key, but I ran into an edge case that's worth mentioning for future searchers.
Even if you do everything else right, as in VonC's answer, a somewhat standard setting for ControlPath can mess things up.
I had two users in ~/.ssh/config, as below:
Host gitolite
HostName <whatever>
User git
IdentityFile ~/.ssh/gitolite
Host username
HostName <whatever>
User git
IdentityFile ~/.ssh/username
In theory, this should have allowed me to run git clone git#username:reponame, but the server kept thinking that I was trying to clone the repo as the gitolite admin (who does not have permission to clone that repo), rather than as the gitolite user (who does have permission to clone the repo).
The problem was that in my all hosts section, I had the following:
Hosts *
# other stuff that doesn't matter
ControlPath ~/.ssh/ssh-%r#%h:%p
If you don't see it right away (I didn't!), the problem is that the expansions for %r#%h%p (= username#hostname:port) are identical for the gitolite and username entries. They're both git#hostname:port! Once I realized that, it was an easy fix. Simply add distinguishing elements into a more specific ControlPath entry for those two users. E.g.,
Host gitolite
HostName <whatever>
User git
IdentityFile ~/.ssh/gitolite
ControlPath ~/.ssh/gitolite-admin-%r#%h:%p
Host username
HostName <whatever>
User git
IdentityFile ~/.ssh/username
ControlPath ~/.ssh/gitolite-username-%r#%h:%p

Answer 4

I had to edit /etc/ssh/sshd_config and add git (the user) to the line which begins with AllowUsers.
Then I had to add git to a sysadmin group that was also allow on sshd_config's line that begins with AllowGroups.
Don't forget to restart the ssh daemon with sudo service ssh restart.
Note : I didn't have to ssh-copy-id or add the public key to /home/git/.ssh/authorized_keys as suggested before (gitolite's developer recommends against this btw.)

Answer 5

I had the same problem, with a different solution because of my config. I setup my gitolite user as “git” so I needed to do git clone git#server:repo.git