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.