8

I am trying to get an git server repository running. I did install gitolite

when running git info over ssh the server answers

ssh git@myserver info

hello Brian, this is git@hepide01pep1 running gitolite3  on git 1.6.3.2
R W   testing

When trying to clone the gitolite-admin repository I get the following error

git clone git@myserver:gitolite-admin

Cloning into 'gitolite-admin'...
FATAL: R any gitolite-admin Brian DENIED by fallthru
(or you mis-spelled the reponame)
fatal: The remote end hung up unexpectedly

Same thing happens with this syntax

git clone ssh://git@myserver/gitolite-admin 
Cloning into 'gitolite-admin'...
FATAL: R any gitolite-admin Brian DENIED by fallthru
(or you mis-spelled the reponame)
fatal: The remote end hung up unexpectedly

Cann anybody give me some useful hints? I checked the Answers here and on the web but didn't find anything that helped me any further.

macbert
  • 772
  • 2
  • 11
  • 29

3 Answers3

15

The accepted answer is a good one if you you're just setting up gitolite, but if you're a new user to an existing installation, you'll get the same error as the one in the question unless you've been added as an administrator.

If you have shell access to the server gitolite lives on, login and switch to the user that gitolite users - usually called git.

Once logged into the gitolite user, go to the conf file and give yourself RW+ rights on the gitolite-admin repo. Gitolite conf is usually in /home/git/.gitolite/conf/gitolite.conf (assuming username is git). For a gitolite user named Peaches, grant the permissions thusly:

repo gitolite-admin
    RW+     =   OriginalAdmin Peaches

Save the file, and run setup from the command line, still as the gitolite user:

gitolite setup

If you've been setup as a user correctly, you should be able to clone now.

For more on adding users, see the documentation

MrOodles
  • 1,856
  • 21
  • 21
8

gitolite-admin is only accessible with the public key named after the git account used for the gitolite server.

You are using by default your brian.pub, which only gives you access to testing.git repo.

you need to define a $HOME/.ssh/config file on your local workstation, in order to record ssh parameters to use the right key.
See "gitolite: can connect via ssh, can't clone".

~/.ssh/gitolite.pub
~/.ssh/gitolite

Then I define a config file: ~/.ssh/config with in it:

host gitolite
     user git # replace it by the actual git user for the gitolite server
     hostname server.com
     identityfile ~/.ssh/gitolite

The clone will work:

git clone gitolite:gitolite-admin

The OP macbert confirms:

I did rename the key to git.pub, ran gitolite setup -pk git.pub and removed the old brian key from the .gitolite/keydir.
After that I got git clone git@myserver:gitolite-admin:

Cloning into 'gitolite-admin'... 
remote: Counting objects: 15, done. 
remote: Compressing objects: 100% (12/12), done. 
remote: Total 15 (delta 0), reused 0 (delta 0) 
Receiving objects: 100% (15/15), done.

So with the right default key, a ssh git@myserver info should this time display the right access for gitolite-admin repo in the 'hello' message.

Community
  • 1
  • 1
VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • ah good hint - this works git clone git@myserver:testing.git Cloning into 'testing'... warning: You appear to have cloned an empty repository. how could I change this? On this guide it looks to my like the key could be named anything: $ mkdir bin $ gitolite/install -ln $ gitolite setup -pk sena.pub Initialized empty Git repository in /home/gitolite/repositories/gitolite-admin.git/ Initialized empty Git repository in /home/gitolite/repositories/testing.git/ WARNING: /home/gitolite/.ssh/authorized_keys missing; creating a new one Next step would be the clone an the tut. says it works – macbert Sep 27 '12 at 09:38
  • @macbert correct: but you won't be able to clone `gitolite-admin` unless you specify through the `config` file that you want to use the right public key. And the name of the keys is important. – VonC Sep 27 '12 at 09:39
  • Okay great! I did rename the key to git.pub ran gitolite setup -pk git.pub and removed the old brian key from the .gitolite/keydir After that I got git clone git@myserver:gitolite-admin Cloning into 'gitolite-admin'... remote: Counting objects: 15, done. remote: Compressing objects: 100% (12/12), done. remote: Total 15 (delta 0), reused 0 (delta 0) Receiving objects: 100% (15/15), done. Sound great - Thanks @VonC – macbert Sep 27 '12 at 09:47
  • Btw. you should never need to change anything in `.gitolite/` manually. That’s what the `gitolite-admin` repository is for. Whenever you push an update to that repository, it automatically updates. So when you want to rename a user, change the name of the key file *and* update the configuration file to use the new name and commit&push that together. Otherwise it will fail. – poke Sep 27 '12 at 10:38
1

Usually bare git repos are using a .git name. Please try to do

git clone git@myserver:gitolite-admin.git

iltempo
  • 15,718
  • 8
  • 61
  • 72
  • same output :-7 git clone git@myserver:gitolite-admin.git Cloning into 'gitolite-admin'... FATAL: R any gitolite-admin Brian DENIED by fallthru (or you mis-spelled the reponame) fatal: The remote end hung up unexpectedly – macbert Sep 27 '12 at 09:31
  • @macbert normal: this has nothing to do with the name of the repo, and everything to do with how gitolite control the access to that specific '`gitolite-admin`' repo. – VonC Sep 27 '12 at 09:41
  • 6
    Gitolite is smart enough to take care of the `.git`; you don’t need it at all. – poke Sep 27 '12 at 10:36