Gitolite: adding user not working, and DENIED by fallthru when cloning as root?

Jay picture Jay · Jun 1, 2012 · Viewed 25.8k times · Source

I've managed to init an empty git repo on my NAS, and I attempted to add a new user by generating a new public key "foo.pub" and copying + pasting it into keydir/ and committing that and pushing it onto the NAS.

First, the files:

Here is my ~/.ssh/config file:

Host root
    HostName iptonas
    User root
    Port 123        

Host foo
    HostName iptonas
    User foo
    Port 123
    identityfile ~/.ssh/foo

Grabbed a copy of gitolite-admin from NAS:

git clone ssh://root/gitolite-admin

I get:

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

Here is my gitolite.conf file:

repo gitolite-admin
    RW+     =   git

repo testing
    RW+     =   @all

repo newrepo
    RW+     =   foo
    RW+     =   bar

When I pushed my copy of gitolite-admin using:

git push root:gitolite-admin

I get:

Counting objects: 10, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (5/5), done.
Writing objects: 100% (6/6), 1.02 KiB, done.
Total 6 (delta 0), reused 0 (delta 0)
remote: Initialized empty Git repository in /root/repositories/newrepo.git/
To root:gitolite-admin
   897113c..e7e2daf  master -> master

Now, when I try to push to the new repo

When I try to run:

git clone foo:newrepo

I get:

Cloning into 'newrepo'...
foo@iptonas's password: 
fatal: 'newrepo' does not appear to be a git repository
fatal: The remote end hung up unexpectedly

When I try to run:

git clone root:newrepo

I get:

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

I'm not sure what I'm doing wrong?

I am following these instructions: http://www.nineproductions.com/linux/53-gitolite-hosting.html Under "Adding Repositories and Users"

Answer

VonC picture VonC · Jun 1, 2012

Those instructions mentions cloning with a user which has a id_rsa.pub key used when installing Gitolite.

So, your account must have in its ~/.ssh the id_rsa and id_rsa.pub keys used by gitolite when declaring the 'git' user (which is the only one able to clone gitolite-admin repo).

Now, to add a user, you not only have to declare said user in the gitolite.conf file (which you did), you also have to add his public key to the local gitolite-admin repo 'keys' directory.

  • I ask Steve Franko to generate a new public/private key pair using ”ssh-keygen -t dsa
  • I ask Steve Franko to send me the PUBLIC key he just generated
  • I rename the public key from id_dsa.pub to sfranko.pub
  • I copy the sfranko.pub key into the gitolite-admin/keydir directory

If you do both those operations before pushing back gitolite-admin, then Gitolite will declare that new user, and your git clone foo:newrepo will work.

Note that if your did the Gitolite installation with the git account as I recommended before, you should have in your config file:

Host git
    HostName iptonas
    User git
    Port 123
    Identityfile ~/.ssh/git

And go a git clone git:gitolite-admin.

The only time you should see/use root is at the beginning of the installation on the server side, in order to declare/add the git account.
After that, I really recommend you to not use/see root anywhere in your process.


Actually I did generate two key sets, so my ~/.ssh folder currently has: id_rsa, id_rsa.pub, id_foo, id_foo.pub

Your ~/.ssh folder should contain:

git, git.pub, id_foo, id_foo.pub

Gitolite bases its authorization mechanism on an authentication made after the name of the public key.

Again: on the server side, you must do the gitolite installation as a user like 'git', with as an argument a /tmp/git.pub (not /tmp/id_rsa.pub)


Let's recap because there is much confusion here. Gitolite is based on ssh.
That means you need one account (here 'git') on the server side (which will be your Gitolite server), in which a ~git/.ssh/authorized_keys file will record all the Gitolite admin/users public keys.

On the client side (your user foo), you need to have (at least for your first user) the public and private keys from git, and the ones from foo.

Your ~foo/.ssh/config file will contain:

Host gitadmin
    HostName iptonas
    User git
    Port 123        
    identityfile ~/.ssh/git

Host foo
    HostName iptonas
    User git
    Port 123
    identityfile ~/.ssh/foo

Note that the user for any ssh communication is always git! You always contact the Gitolite server through an ssh address like ssh://git@iptonas:123/arepo.
Except, since yo have multiple SSH keys to chose from, you can type instead:

  • git clone gitadmin:gitolite-admin, or
  • git clone foo:newRepo

The first command will allow you to clone the gitolite-admin repo (because you do that using git public and private ssh keys, so you have the rights to do that).
You can use that local clone to put foo.pub in the keys directory, and to declare a newRepo in the config file.
Then you push back that repo (and Gitolite does its magic, creating a new repo, adding the content of foo.pub to ~git/.ssh/authorized_keys for you, with a forced-command script in order to intercept any ssh commands emitted by foo).

(I prefer naming that ssh shortcut 'gitadmin' instead of git, even if the public/private keys are named 'git.xxx', because 'gitadmin' better conveys the intent of the ssh commands you will do with it: you will administer git access rights)

The second command allows you to clone your newRepo and to work on it.

Note that:

  • ssh gitadmin, or
  • ssh foo

will display the gitolite version and the rights associated with the ssh keys used by each ssh shortcuts 'gitadmin' and 'foo', as defined in the ~foo/.ssh/config file.