Kerberos with SSH, Part 1

2021/06/29

... just because we can.

Why?

Because you don't want to type passwords into ssh. And you naively believe that things that should be easy are easy.

Prerequisites

... a working Kerberos 5 KDC. It's not actually hard to get one up and running... actually, it's probably easier than all this below. But it doesn't quite fit here. Let's assume you already have one. (Or maybe you're running Active Directory? well, some of the steps might be slightly different there.)

Mission objective

Passwordless SSH with domain logins. Namely, we're setting up a brand new machine. It's a fresh Linux install.

How?

Well, we first need a bunch of packages on the client.


sudo apt install krb5-user

This will ask you about a Kerberos domain. Enter yours. Do not forget about making it upper case.

At this point, kinit should work, as long as you've logged on with the right user:


simon@client ~> kinit
Password for simon@DOMAIN.EXAMPLE.COM:

... unless... um...


simon@client ~> kinit
kinit: Client 'simon@domain.example.com' not found in Kerberos database while getting initial credentials

... it's deceptively close to the correct thing, right? Well, um, see the point about "upper case" above. (You can just edit /etc/krb5.conf and fix your realm name there.)

OK, so we have this up and running. Time for SSH! For which, of course, we do need to create a machine principal. You could use kadmin on the new host, but... using an admin account on a random machine just doesn't feel overly secure (keyloggers, etc). Assuming we can SSH into both of them at the same time though, we can just set up an account this way:


simon@kdc ~> sudo kadmin.local
[sudo] password for simon:
sudo: kadmin.local: command not found.

... did I mention that Debian packages are weird? Apparently, although kadmin is included with... krb5-user probably, kadmin.local needs the "admin server" package: krb5-admin-server.


simon@kdc ~> sudo kadmin.local
[sudo] password for simon:
kdamin.local: addprinc host/client.domain.example.com
WARNING: no policy specified for host/client.domain.example.com
Enter password for host/client.domain.example.com:
Re-enter password for host/client.domain.example.com:
Principal "host/client.domain.example.com" created.

... but where exactly do we take passwords from? Well, we can just generate some:


# ... earlier during the day
simon@kdc ~> pwgen -n 16 # should be long enough
authe4HeeHee1Oht kighae1Egh7aiPia ahlug4Gao4shu3Oh oiTe8aasais0jei9
xiep8be3ahs3ooTi EKe2tei6Qui6caey geem4oocoh4reiZa nie0kievood5Di5i
ahPhisioH8Cuechi eiview0leegaezaF aeshoofeCh0sie1a jeigaiRoh9deekes
# etc.

Now, we can just take the same password and make a keytab out of them on the client itself!


simon@client ~> sudo ktutil
ktutil: add_entry -password -p host/client.domain.example.com -f -k 1
Password for "host/client.domain.example.com"@DOMAIN.EXAMPLE.COM": # pw copied from the other SSH window
ktutil: write_kt /etc/krb5.keytab # be kinda careful not to overwrite an existing one
ktutil:

Finally, make /etc/ssh/sshd_config contain the following lines:


# GSSAPI options
GSSAPIAuthentication yes
GSSAPICleanupCredentials yes

(you can just uncomment and edit some.)

Restart sshd, and... (to be continued. You would assume it works. It hopefully will. It might not though.)

This is post no. 16 for Kev Quirk's #100DaysToOffload challenge.

... comments welcome, either in email or on the (eventual) Mastodon post on Fosstodon.