Gitolite3 SSH info failing

1

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

Posted 2013-08-09T22:11:13.537

Reputation: 123

1What are the permissions on the .ssh directory and the .ssh/authorized_keys file for the git user? What does ssh -vvv git@myserver info say? What does the ssh log on the server say? – Etan Reisner – 2013-08-12T17:51:54.947

Thanks for helping out! Does the local user doing this ssh command need to be known in the git@server ssh authorized list? the -vvv returns a lot of info, do you want to see it all? Where is the ssh log located, and are you asking about the local ssh log, or the server sshd log? – Florian Mertens – 2013-08-13T22:06:57.003

1The server log. Yes, all of the output. The key the local user is using needs to be in the git@server user's authorized_keys list or the local user's key will not authenticate the user to the git account (but you shouldn't need to do anything about that since gitolite manages authorized_keys for you). – Etan Reisner – 2013-08-14T11:34:45.433

Answers

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

Posted 2013-08-09T22:11:13.537

Reputation: 123

Asked: 2013-08-09T22:11:13.537

Viewed: 810 times

Active: 2013-08-18T15:18:41.377