This article is obsolete now! There is a new article now which does describe a slightly different and better solution.

Once you have been succeeded in taming the three-headed beast called Kerberos, this powerful beast will prove handy for quite a lot of stuff!

I have been fiddling with Linux AD Integration and thus Kerberos at my workplace for quite some time now. Recently I needed to setup a gitolite server for software development, as more and more people tend to migrate from SVN to GIT now and using file based git repositories are a pain in the ass, especially when talking about file permissions and platform independent access.

So thinking about gitolite deployment, I wondered why the hell we should use ssh-keys for authentication if all our users (Windows or Linux) are already authenticated on their system using Kerberos anyway.

It turned out, that gitolite, openssh and an AD-integrated Linux machine (acting as gitolite server) will be 99% sufficient to get this stuff running. All I found on the web about this particular issue was this short discussion which does not offer a proper solution. The 1% missing to the solution I’m presenting here is a 3-line patch for openssh, but read on…

So here comes the gitolite+kerberos mini HOWTO:

• Start from a kerberized Linux server system with a working kerberized ssh setup
• Install a version of openssh with this patch (I also have packages build for debian squeeze, just drop me a line if you like to get them)
• Download my gitolite_wrapper_script and copy it into /usr/local/bin/
• Add the following two lines to your sshd_config:

Match User gitolite
ForceCommand /usr/local/bin/gitolite_wrapper_script

• Add a local (non AD) gitolite user without password to this system
  (I used /usr/share/gitolite as its home)
• su to this user and clone the gitoline repository into this users home
  (git clone git://github.com/sitaramc/gitolite.git gitolite.clone)
• Follow the Installation instructions in README.txt, but use -a <adminid> instead of -pk for setup
• Make shure you have gitolite and gitolite-shell available in your PATH, I did this by adding symlinks to /usr/local/bin
• create a file .k5login in the homedirectory of the gitolite user and add the kerberos realm of your admin <adminid>@<REALM>
• now run git clone gitolite@/<yourserver>:gitolite-admin.git from a client (already using kerberos authentication)
• create a file k5login inside this clone and again add the kerberos realm of your admin <adminid>@<REALM>
• commit and push this file
• on the server replace the .k5login file with a symbolic link to .gitolite/k5login
• You are now running a pure kerberos5 based gitolite server
• The only thing which is different from an ordinary gitolite now is that we don’t manage ssh-keys but kerberos realms using the file k5login

Nice stuff you might think, but why the hell will we need to patch the secure shell daemon? The answer is simple: Once your login has succeeded the Unix shell running with gitolite userid does not know about the kerberos prinzipal used for authentication and there is no way (at least none, that I know of) to figure it out.
The username part of this prinzipal is however needed for gitolite. The only thing my patch does now is adding an environment variable called GSS_AUTH_KRB5_PRINC which can be evaluated by gitolite.
BTW, using the perl-script provided in the usenet discussion linked above was not an option because especially windows machines will not forward tickets by default and forwarding ticket is unnecessary for this purpose anyway.

As far as clients are concerned this has currently been tested using Linux git with openssh as well as Windows git and eclipse EGIT in conjunction with plink.exe provided by putty.