1

I have installed gitolite3 from the EPEL repository to Centos6.4. There were a number of things that I didn't like, so I set about to change them. First, I created an additional user and group called 'git' to distance from the obscure gitolite3 user. Second, I used a custom folder /Server/Projects instead of /var/lib/gitolite3. I made sure that ownership and permissions were the same.

Setup was also with no problem (su - git, then gitolite3 setup with admin client key).

Normally, on a client machine, the command ssh git@myserver info would generate a nice gitolite plain return listing the repos and permissions. But now it gives me a request for a password. Obviously, gitolite is no longer connected to the ssh port via this user, but the usual bash is.

I'm not an expert on SSH, so something went wrong, or I forgot to do something. Where should I look? I think /usr/share/gitolite3/gitolite3-shell is the app that SSHD should call when a SSH request with the git user comes in..

Florian Mertens
  • 123

1 Answers1

0

SSH is not easy. I have resolved it myself, but it wasn't obvious. It was mostly a SELinux problem, but I found that I had also not setup the pubkey properly.

First, I (re)created the pubkey (admin.pub) for the local computer that was going to administer the gitolite server, copied it to the server git user home folder, rerun (under the git user in his home folder) the gitolite setup with that pubkey. A note here is that my local computer is windows with msys-git, making the problem not easy.

# su - git
$ cd /Server/Projects
$ gitolite setup --pubkey admin.pub

..That resolved the pubkey problem. The selinux was a bigger learning curve, but essentially you lose all of the original /var/lib/gitolite3 folder context labellings when you just copy. To restore the labellings (with semanage), you reference the same labellings (with the -e flag) as on the original folder, to where you have set the current gitolite folder. Since that only adds to the existing selinux file contexts, you also need to restore these from the selinux file contexts. The final pithole is to use absolute paths, not relative paths. You can see what you did with the ll command:

# semanage fcontext -a -e /var/lib/gitolite3 /Server/Projects
# restorecon -R /Server/Projects
# ll -aZ

Now, on your local machine, try it all out with the command below from the computer where the pubkey was coming from, it worked for me. Note that I didn't know that ssh git@unclefloserver info would only return a nice gitolite3 repo info output if the server actually has the pubkey of the requesting user/computer combination. I also failed to understand this concept a bit, and I was trying this out from a different computer.

> git clone git@server:gitolite-admin

Big thanks to @Etan Reisner for keeping the pressure up.

Florian Mertens
  • 123