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 [email protected]: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 [email protected]: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 [email protected] 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?
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_keysfile is how ssh uses pubkeys to authenticate users.
Let's say[email protected]is trying to log in asgit@server.
What you have to do is take the~sita/.ssh/id_rsa.pubfile for usersitaon work-station and append its contents (remember it's only one line) to~git/.ssh/authorized_keysfor usergiton 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.
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.
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
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With