doc/kerberized-server.mdwn

   1 [[!meta title="Enabling Kerberos logins for your server"]]
   2
   3 If you want kerberized logins on a server you run, you'll need a
   4 *keytab* from accounts.  Fill out the
   5 [keytab request form](https://ist.mit.edu/accounts/keytab),
   6 which sends them an e-mail.
   7
   8 Your new keytab will be in
   9 `/mit/accounts/srvtabs/FOR_YOURUSERNAME`, which is AFS and vaguely
  10 insecure.  You probably want to install it in `/etc/krb5.keytab`,
  11 and then **set a new (random) key**.
  12
  13     # mv -f /etc/krb5.keytab /etc/krb5.keytab.old  # back up any keytab you already have
  14     # mv /mit/accounts/srvtabs/FOR_JOEUSER/joeserver-new-keytab /etc/krb5.keytab
  15     # k5srvutil change
  16     # k5srvutil delold
  17
  18 Note that the `k5srvutil` command will also generate keys for the 3DES and RC4 ciphers, which are considered weak.
  19 You are strongly advised to read the "Upgrading cryptographic strength" section below on how to generate only AES keys instead.
  20
  21 If you're using Debathena, you can install the `debathena-ssh-server-config` package to configure Kerberos authentication on the server side. If not, make sure your `/etc/ssh/sshd_config` file includes the lines
  22
  23     GSSAPIAuthentication yes
  24     GSSAPIKeyExchange yes
  25
  26 This will let you SSH in with Kerberos.
  27
  28 Then create a file called `.k5login` in the home directory of
  29 whichever users you want to be able to log into with Kerberos. List the
  30 full Kerberos principal of each user, one per line (e.g.,
  31 `joeuser@ATHENA.MIT.EDU`)
  32
  33 If you don't want it to be possible to log in to a user account via
  34 Kerberos, create an empty `.k5login` file in their home directory.
  35 Otherwise, by default, you can log in to a user account with a Kerberos
  36 principal from the default realm (ATHENA, presumably) whose username
  37 matches; that is to say, an Athena user whose username matches a local
  38 username can log in to that local account.  (One option to avoid this is
  39 to create a `.k5login` file in `/etc/skel` so that new accounts you
  40 later add get this file by default.)
  41
  42 ## Upgrading cryptographic strength
  43
  44 You may wish to change the encryption algorithms (*enctypes*) included in your keytab. With server principals (like `daemon/servername.mit.edu` or `host/servername.mit.edu`) it is particularly important to support *only* strong algorithms. If you support a weak algorithm, an attacker can request an initial ticket encrypted with that key, allowing them to do an offline attack and potentially extract the secret key.
  45
  46 To change the supported enctypes, run `kadmin`:
  47
  48     kadmin -p daemon/kronborg.mit.edu  -k -t daemon.kronborg.keytab
  49
  50 From within `kadmin`, to create new keys:
  51
  52     ktadd -k daemon.kronborg.keytab -e aes256-cts:normal,aes128-cts:normal daemon/kronborg.mit.edu
  53
  54 After all tickets currently issued against your service expire (which will happen after at most one day), you should remove the old keys from your keytab. If there are no outstanding tickets, you can do this from within `kadmin`:
  55
  56     ktremove -k daemon.kronborg.keytab daemon/kronborg.mit.edu old
  57
  58 Before exiting, you may wish to verify in a separate terminal that the correct updated key has been written to the keytab:
  59
  60     kinit -k -t daemon.kronborg.keytab daemon/kronborg.mit.edu
  61     kvno daemon/kronborg.mit.edu@ATHENA.MIT.EDU