Kerberos Authentication with Gitolite 3

(Note: This post is originally from 2018, and is copied to this new site for historical reasons. Opinions, network infrastructure, and other things may have changed since this was first written.)

I’d been meaning to actually get around to disabling public key authentication on my SSH daemons, in favor of being entirely Kerberos-only. I’m already using it for auth and deleted most of my keys now anyway, and if there’s a hole in that auth type later, well then I’m even more covered than usual.

There was just one hold up – one of these boxes is also my Gitolite 3 instance, which used SSH keys to decide which user was logging in as the “Git” user. And in order to Kerberize it, I needed to come up with something to replace that.

What it was doing before

It turns out that you can use the ~/.ssh/authorized_keys file to set specific options for a given key, such as “disallow X11 forwarding”, and most interestingly, forcing it to run a specific command.

% cat ~gitolite3/.ssh/authorized_keys
command="/usr/share/gitolite3/gitolite-shell lavacano",no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty ssh-rsa AAAA …

So basically, I just need to run gitolite-shell as the user of my choice. And I know of no way to force a command based on the Kerberos principal baked into OpenSSH already. So, I’ll just have to force the gitolite user to run a shell script and do it there.

How I did it

Keep in mind, this method uses forwardable tickets. While researching a way to handle this, I found that some Kerberos users are allergic to using forwardable tickets if they don’t have to. If that sounds like you, I found a blog article from 2012 that offers an alternative, but it involves patching OpenSSH, which is something that I happen to be allergic to, myself, so I haven’t tested it.

Step 1: SSH Configuration

The first thing you’re going to need to do is open your sshd_config (and disable pubkey auth, too,
if that’s your goal). Add these two lines to the end of it:

Match User gitolite3
ForceCommand /usr/local/bin/gitolite-shell-krb5

Step 2: Writing the command you’re forcing in Step 1

/usr/local/bin/gitolite-shell-krb5 is a script that will read the current Kerberos principal, and use that to determine what user to provide to Gitolite. Here’s my Bash script, which works with MIT Kerberos version 1.13:

#!/bin/bash

# $KRB5_WHOAMI becomes "username@EXAMPLE.COM", assuming MIT klist
# note, this requires forwardable/proxiable tickets
# this regex comes from emailregex.com
KRB5_WHOAMI=$(klist | grep -ioP 'Default principal: \K[A-Za-z0-9._%+-]+@[A-Za-z0-9.-]+\.[A-Za-z]{2,6}')

if [[ -z "${KRB5_WHOAMI// }" ]]; then
    echo "Error setting KRB5_WHOAMI, did you use \"kinit -f\"?" >&2
    exec /usr/share/gitolite3/gitolite-shell
fi

# GL_USER becomes "username"
export GL_USER=$(echo $KRB5_WHOAMI | cut -d '@' -f 1)

if [[ -z "${GL_USER// }" ]]; then
    # this shouldn't break, but what if it does
    echo "Error setting GL_USER, what the hell?" >&2
    exec /usr/share/gitolite3/gitolite-shell
fi

# at this point, we should be good
exec /usr/share/gitolite3/gitolite-shell $GL_USER

If your Kerberos principal is “username@EXAMPLE.COM”, your Gitolite username becomes “username”. This is the
username you use to determine access rights in gitolite-admin/conf/gitolite.conf and so on.

Step 3: Authorized Kerberos principals

Now all you need to do is set up gitolite’s authorized users. First, commit a file gitolite-admin/k5login
to your Gitolite admin repository, containing the Kerberos principals of everyone you want to have access to your Gitolite repositories (just like any other .k5login file). Once you’ve committed and pushed it the first time, you’ll need to make a symlink.

# make sure you're root
$ cd ~gitolite3
$ ln -s .gitolite/k5login .k5login

Finally, remove your keys from your ssh-agent, get a Kerberos ticket with kinit -f, and try to git push a commit. If everything went smoothly, Git should work as usual.