Can not add user with Gitolite

Question

I am newby with gitolite. I've install gitolite on a remote server.

http://dev.remoteserver.com

So I could git-cloning gitolite-admin.git.

git clone ssh://[email protected]/gitolite-admin.git

I wanted to add user and repo using gitolite. following is ordinary add user process.

---

In the local repository, conf / keydir directory exists.

open conf/gitolite.conf 

added below text.

repo   aproject
       RW+ = testid

and, in local-mac,

ssh-keygen -t rsa. 

added the public key in keydir/testid.pub
and then, git add / git commit / git push is done well.

---

okay, then I tried to cloning the fresh git repo from the remote server.

git clone ssh://[email protected]/aproject.git

but,it makes error like this...

mac$ git clone ssh://[email protected]/aproject.git
Cloning into 'aproject'...
[email protected]'s password: 
Permission denied, please try again.
[email protected]'s password: 
Permission denied, please try again.
[email protected]'s password: 
Permission denied (publickey,gssapi-with-mic,password).
fatal: The remote end hung up unexpectedly

I think git cloning shoud not ask password. and correct password also failed git-cloning.

My remote server is CentOS.

and comments welcomes.

Answer 1

With gitolite, all your ssh communications are done with the account used to install gitolite.
In your case: gitolite.

However, you can specify a different public key in order to indicate gitolite to authenticate you against a different user.
The ssh session will still be performed as gitolite.
But the name passed to gitolite script will be testid (because the public key was registered by gitolite in its ~/.ssh/authorized_keys as 'testid')

So use a ~testid/.ssh/config file in which you mention the right parameter:

Host gitolitesrv
Hostname dev.remoteserver.com
User gitolite
IdentityFile /path/to/tesitd

Note that /path/to/ must contain your private key testid and your public key testid.pub.
At this point, their name isn't important (could be xxx and xxx.pub)
What was important was the name of the public key as stored in gitolite-admin/keydir/testid.pub (because the name of the file is used for the id recorded in the authorized_keys forced-command line)

And then, this git clone should work:

git clone gitolitesrv:aproject.git

---

The OP Jinbom Heo mentions having difficulties:

Cloning into 'aproject'... R access for aproject DENIED to gitolite
(Or there may be no repository at the given path. Did you spell it correctly?) fatal: The remote end hung up unexpectedly

it appears that git user is not testid but gitolite.

Host dev2git 
  Hostname dev.remoteserver.com 
  User gitolite 
  IdentityFile ~/.ssh/testid

And a gitolite.conf file include the following (git-pushed):

repo aproject RW+ = testid

At last, I found the reason.
When generating ssh-key using ssh-keygen, I typed password. That's the problem.
So I tried keygen without password, and it works~. I don't know why password should not be added when I make the key. Anyway, It works well

---

I can confirm I have always use passphrase-less keys.
I you do want to protect your keys with passphrase, see "appendix 1: ssh daemon asks for a password"

make sure you're being asked for a password and not a passphrase.
Do not confuse or mistake a prompt saying Enter passphrase for key '/home/sitaram/.ssh/id_rsa': for a password prompt from the remote server!

When you create an ssh keypair using ssh-keygen, you have the option of protecting it with a passphrase.
When you subsequently use that keypair to access a remote host, your local ssh client needs to unlock the corresponding private key, and ssh will probably ask for the passphrase you set when you created the keypair.

You have two choices to avoid this prompt every time you try to use the private key.

• The first is to create keypairs without a passphrase (just hit enter when prompted for one).
  Be sure to add a passphrase later, once everything is working, using ssh-keygen -p.
• The second is to use ssh-agent (or keychain, which in turn uses ssh-agent) or something like that to manage your keys.
  Other than discussing one more potential trouble-spot with ssh-agent (see "appendix 3: ssh client may not be offering the right key"), further discussion of ssh-agent/keychain is out of scope of this document.