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](http://web.mit.edu/accounts/www/srvtabform.html),
   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 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
  19
  20     GSSAPIAuthentication yes
  21     GSSAPIKeyExchange yes
  22
  23 This will let you SSH in with Kerberos.
  24
  25 Then create a file called `.k5login` in the home directory of
  26 whichever users you want to be able to log into with Kerberos. List the
  27 full Kerberos principal of each user, one per line (e.g.,
  28 `joeuser@ATHENA.MIT.EDU`)
  29
  30 If you don't want it to be possible to log in to a user account via
  31 Kerberos, create an empty `.k5login` file in their home directory.
  32 Otherwise, by default, you can log in to a user account with a Kerberos
  33 principal from the default realm (ATHENA, presumably) whose username
  34 matches; that is to say, an Athena user whose username matches a local
  35 username can log in to that local account.  (One option to avoid this is
  36 to create a `.k5login` file in `/etc/skel` so that new accounts you
  37 later add get this file by default.)