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

clone, git, gitolite

Solution

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.

Problem

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"

Original source