Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

users are asked for password while using gitolite

Tags:

gitolite

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?

like image 397
Dilawar Avatar asked Jun 06 '12 00:06

Dilawar


3 Answers

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 [email protected] 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.

like image 118
VonC Avatar answered Nov 10 '22 12:11

VonC


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.

like image 25
Dilawar Avatar answered Nov 10 '22 11:11

Dilawar


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
like image 34
Telemachus Avatar answered Nov 10 '22 12:11

Telemachus