Check the ssh parts about gitolite: the fact that you can connect to server.com
through ssh
only means:
- your ssh key is registered in
server.com@~/.ssh/authorized_keys
- that key isn't related to gitolite 'there is no "
command=
" option, which means "regardless of what the incoming user is asking to do, forcibly run this command instead").
You are in an interactive session, able to execute any command you like.
What I don't like at all about the third-party tutorial is that it tries using the same name for git user and ssh non-root user
You should keep separate:
- the non-root user (which isn't an account, just an ssh key, which will be linked to gitolite, with admin privileges to the
gitolite-admin
repo)
- the hosting account, which should be '
git
', not gitolite
, precisely to avoid confusion between the two usage mode:
git
(log on directly on server.com
, no ssh here): interactive session needed to execute git command (like cloning on the server the gitolite repo, and executing gitolite/src/gl-system-install
)
ssh git@server.com
which will use your ~/.ssh/id_rsa(.pub)
public and private keys, which, being the ones of the gitolite, will authorize you to clone the gitolite-admin
repo and push back that repo
Again:
'gitolite' is not a true account, only a name authorized to execute commands on server.com
as 'git
' (the actual "hosting account", as in "hosting git services and repos").
All the other git users will also execute git commands on server.com
as git
.
And that particular user (gitolite
) will be linked to gitolite authorization layer through the forced-command mechanism, with privileges setup during the gitolite installation in order to grant that 'user' rights to clone, modify and push back gitolite-admin
repo.
(That is its only particularity compared to all the other ssh git users you will add: they won't have access to that specific git repo which is the gitolite-admin
one)
Trying to name the two with the same name is just asking for trouble.
I don't like using the default naming convention for the public/private keys, so I prefer on the client defining those keys with the name of the intended user:
~/.ssh/gitolite.pub
~/.ssh/gitolite
Then I define a config file: ~/.ssh/config
with in it:
host gitolite
user git
hostname server.com
identityfile ~/.ssh/gitolite
(Note the user here: always git
)
Then I can clone my gitolite-amin
repo:
git clone gitolite:gitolite-admin
# modify locally
# git add -A ; git commit -m "my modifs"
git push origin master
与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…