If you want kerberized logins on a server you run, you'll need a keytab from accounts. Fill out the keytab request form, which sends them an e-mail.
Your new keytab will be in
/mit/accounts/srvtabs/FOR_YOURUSERNAME, which is AFS and vaguely
insecure. You probably want to install it in
and then set a new (random) key.
# mv -f /etc/krb5.keytab /etc/krb5.keytab.old # back up any keytab you already have # mv /mit/accounts/srvtabs/FOR_JOEUSER/joeserver-new-keytab /etc/krb5.keytab # k5srvutil change # k5srvutil delold
Note that the
k5srvutil command will also generate keys for the 3DES and RC4 ciphers, which are considered weak.
You are strongly advised to read the "Upgrading cryptographic strength" section below on how to generate only AES keys instead.
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
GSSAPIAuthentication yes GSSAPIKeyExchange yes
This will let you SSH in with Kerberos.
Then create a file called
.k5login in the home directory of
whichever users you want to be able to log into with Kerberos. List the
full Kerberos principal of each user, one per line (e.g.,
If you don't want it to be possible to log in to a user account via
Kerberos, create an empty
.k5login file in their home directory.
Otherwise, by default, you can log in to a user account with a Kerberos
principal from the default realm (ATHENA, presumably) whose username
matches; that is to say, an Athena user whose username matches a local
username can log in to that local account. (One option to avoid this is
to create a
.k5login file in
/etc/skel so that new accounts you
later add get this file by default.)
You may wish to change the encryption algorithms (enctypes) included in your keytab. With server principals (like
host/servername.mit.edu) it is particularly important to support only strong algorithms. If you support a weak algorithm, an attacker can request a service ticket encrypted with that key, allowing them to do an offline attack and potentially extract your secret key.
To change the supported enctypes, run
kadmin -p daemon/kronborg.mit.edu -k -t daemon.kronborg.keytab
kadmin, to create new keys:
ktadd -k daemon.kronborg.keytab -e aes256-cts:normal,aes128-cts:normal daemon/kronborg.mit.edu
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
ktremove -k daemon.kronborg.keytab daemon/kronborg.mit.edu old
Before exiting, you may wish to verify in a separate terminal that the correct updated key has been written to the keytab:
kinit -k -t daemon.kronborg.keytab daemon/kronborg.mit.edu kvno daemon/kronborg.mit.edu@ATHENA.MIT.EDU