Password-free remote authentication using Kerberos

When connecting to machines at my workplace, we can’t use SSH public key authentication, so I was left with entering my password each time I open a terminal and connect to one of the servers via SSH. Since I do this quite regularly, it became a major annoyance. After a bit of digging, I found out through our IT support that I can use Kerberos (a network authentication protocol) to remotely authenticate. It sounded daunting at first, but is actually quite simple. I didn’t find a tutorial online that would describe exactly what I was looking for, so I thought this was worth writing up.

With Kerberos, the authentication works like this: From my own machine, I can acquire a so-called ticket (with my password) once from the Kerberos authentication server at my workplace, and then I won’t need the password anymore for any connection for as long as the ticket is valid (which is usually 24 hours or more). I’m using Windows, and the best way to look into this was using a WSL (Windows Subsystem for Linux) terminal. So these instructions should work equally on Windows (through WSL), Linux, and likely also on macOS.

First, on a terminal (WSL in Windows), the Kerberos user package has to be installed, to make the commands kinit and klist available. On Ubuntu, this is:

sudo apt install krb5-user

Then, edit /etc/krb5.conf (as superuser). There are some default configuration values and URLs in the file, which can be commented or removed. To get the relevant server addresses for your company/institution, connect to one of their machines using “traditional” authentication, and then copy & paste the relevant content over to the /etc/krb5.conf on the local machine. In my case the relevant sections were (slightly changed to hide the real URLs):

[libdefaults]
    default_realm = WORKPLACE.AC.UK

[realms]
    WORKPLACE.AC.UK = {
        kdc = kdc.workplace.ac.uk
        admin_server = kadm.workplace.ac.uk
        default_domain = workplace.ac.uk
    }

[domain_realm]
    workplace.ac.uk = WORKPLACE.AC.UK
    .workplace.ac.uk = WORKPLACE.AC.UK

I didn’t need any of the special configuration options. Also make sure to stick to the capitalisation, I think it is important.

Now if needed, connect to the workplace VPN, and then the Kerberos ticket can be acquired using:

kinit user@WORKPLACE.AC.UK

Again the capitalisation is important here. You should now be prompted for your password, and after that, should have successfully acquired the ticket. The active tickets can be listed with klist (no arguments).
That’s it, and ssh user@server.workplace.ac.uk should now no longer ask for the password!

Remark 1: If there are any issues with kinit, a very verbose output can be produced with: KRB5_TRACE=/dev/stdout kinit -V user@WORKPLACE.AC.UK (all on one line).

Remark 2: There are some tutorials out there that say that using Kerberos 5 only works with SSH-1, not with SSH-2, and others that say that ssh needs to be compiled with ./configure --with-kerberos5 ..., but for me it just worked out of the box – I suspect that these tutorials might be outdated, most of them didn’t have a date associated with them.

Finally a command that might come in handy is kdestroy, with which one can delete all the active authentication tickets, should it ever be needed.

One caveat is that one must be able to reach the workplace’s Kerberos server to make this work, which in most cases means one must be connected to VPN first, whereas with SSH public key authentication, one can connect/tunnel completely password-less (and without VPN) via an SSH gateway. There might be a way to tunnel the Kerberos authentication too – if I can make it work, I’ll write a follow-up post.

Update: To do this via an SSH tunnel, see the follow-up blog post!

Update January 2023: It has been reported to me that ssh still asks for a password when setting this up on a macOS device. The following should make it work:
Either use ssh with the -K option: "-K      Enables GSSAPI-based authentication and forwarding (delegation) of GSSAPI credentials to the server."
and/or add the following to your ~/.ssh/config, to enable the option by default / system-wide:
Host workplace.ac.uk
  GSSAPIAuthentication yes
This might also be helpful if other tools like rsync or VSCode still ask for the password.