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://gitolite@dev.remoteserver.com/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://testid@dev.remoteserver.com/aproject.git
but,it makes error like this...
mac$ git clone ssh://testid@dev.remoteserver.com/aproject.git
Cloning into 'aproject'...
mac@dev.remoteserver.com's password:
Permission denied, please try again.
mac@dev.remoteserver.com's password:
Permission denied, please try again.
mac@dev.remoteserver.com'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.
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.
I was having trouble cloning out the gitolite-admin
repository after the initial setup and it was due to the fact that I gave group write permissions to the home folder of the gitolite user git
and ssh
doesn't like that.
I checked Check /var/log/secure
and saw this :
Authentication refused: bad ownership or modes for directory /home/git
So all I had to do was :
sudo chmod g-w /home/git/
References :
- http://www.daveperrett.com/articles/2010/09/14/ssh-authentication-refused/
- http://gitolite.com/gitolite/glssh.html