Back in Juli I wrote a blog-post about how I set up a Gitolite-Server using Kerberos-Authentication.
As this post seems to be the only documentation on the web about how to do this, I got quite some feedback. In a recent email conversation I have been asked, if I know about a method, which would not require a patched Version of ssh.
Well, I did not know of one immediately, but now I have implemented one, which does not only make it unnecessary to patch sshd, but will also make the server a little bit more elegant to use from a users perspective 🙂
So here is a new Version of my Gitolite Server+Kerberos HOWTO
Login is now possible with your usual login name (username@servername), using gitolite@servername is obsolete and disabled by this setup.
Supported login-methods are:
- password authentication (password is checked by whatever active Pluggable Authentication Module, pam_krb5 in my case)
- authentication without password using an ssh public key
- authentication without password using kerberos/gssapi
How to setup the system:
We once again start from a system which has a working Kerberos installation. We will however not need something like libnss-ldapd or libnss-sss. I assume that we are working as root, so just use sudo bash on Ubuntu and derivates.
- Add a local user gitolite to your system with „*“ in passwd field
- Download and compile libnss-catchall [1]:
git clone git://git.geggus.net/nss-catchall.git
cd libnss-catchall
dpkg-buildpackage or make
- Install the resulting libnss-catchall package or shared library:
dpkg -i ../libnss-catchall*.deb
- create /etc/passwd_nss_catchall as follows:
grep gitolite /etc/passwd >/etc/passwd_nss_catchall
- Change the passwd line in /etc/nsswitch.conf as follows:
passwd: compat catchall
- Append the following lines to your sshd_config [2]:
PermitUserEnvironment yes
Match User !root,*
ForceCommand /usr/local/bin/gitolite_wrapper_script
- Create the gitolite_wrapper_script as follows:
echo -e '#!/bin/bash\n\n/usr/local/bin/gitolite-shell $LOGNAME\n' >/usr/local/bin/gitolite_wrapper_script
- su to user gitolite and clone the gitoline code into this users home directory:
git clone git://github.com/sitaramc/gitolite.git gitolite.clone
- Loosely follow the Installation instructions in README.txt which will boil down to the following commands [3]:
cd gitolite.clone
mkdir -p $HOME/bin
./install -to $HOME/bin
$HOME/bin/gitolite setup -a <adminid>
- Make shure you have gitolite and gitolite-shell available in your PATH, I did this by adding symlinks to /usr/local/bin
- That’s it! You should have a working gitolite server now
Public-key usage is a little bit different from the gitolite documentation. The lines in the file authorized_keys need to look like this:
environment="LOGNAME=your_username" ssh-rsa AAA
A command Option might be present, but is ignored because of the ForceCommand Option in sshd_config.
As with my old setup, Windows users will need to use plink.exe and point the environment variable GIT_SSH to this executable, openssh on Unix will work out of the box if gssapi authentication has been enabled.
[1] The whole stuff works because of libnss-catchall, a NSS (Name Service Switch) module written by me. It will always return a given single uid/gid/home combination for any user who managed to login somehow. This way we always end up being logged in as the gitolite user regardless of the username provided. The login username will however be present in the LOGNAME environment variable in case of gssapi or password authentication and must be set manually when using ssh public keys.
[2]If you have local users on your machine which should be able to use interactive logins adjust the „Match User“ line. On a multi-purpose machine one should IMO consider using the chroot feature of ssh and a separate IP-address for gitolite anyway.
[3]The string I call <adminid> here is most likely the login-name (local part of the kerberos realm) of the one installing this stuff (you!).
Neueste Kommentare