Stop mentioning srvtabs; also update security recommendations
authorGeoffrey Thomas <geofft@mit.edu>
Thu, 2 Jun 2011 03:56:26 +0000 (23:56 -0400)
committerGeoffrey Thomas <geofft@mit.edu>
Thu, 2 Jun 2011 03:56:26 +0000 (23:56 -0400)
jmorzins says on -c help that accounts will no longer give out srvtabs,
so we no longer need to mention them.

Also address that you should remove the old, insecure key instead of
merely generating a new one and keeping both, and that you should create
empty .k5login files for local users.

doc/kerberized-server.mdwn

index c287e21d34667cfa60690c4c0bfbcad423d7e63f..96d07673821e6ee9b745d351ca5f57a792068b47 100644 (file)
@@ -3,17 +3,17 @@
 If you want kerberized logins on a server you run, you'll need a
 *keytab* from accounts.  Fill out the
 [keytab request form](http://web.mit.edu/accounts/www/srvtabform.html),
 If you want kerberized logins on a server you run, you'll need a
 *keytab* from accounts.  Fill out the
 [keytab request form](http://web.mit.edu/accounts/www/srvtabform.html),
-which sends them an e-mail.  Ask for a "keytab"; by default they'll
-give you a srvtab, the Kerberos 4 analogue.
+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 `/etc/krb5.keytab`,
 
 Your new keytab will be in
 `/mit/accounts/srvtabs/FOR_YOURUSERNAME`, which is AFS and vaguely
 insecure.  You probably want to install it in `/etc/krb5.keytab`,
-and then randomize the key.
+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
 
     # 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
 
 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
 
 
 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
 
@@ -23,18 +23,15 @@ If you're using Debathena, you can install the `debathena-ssh-server-config` pac
 This will let you SSH in with Kerberos.
 
 Then create a file called `.k5login` in the home directory of
 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 log into with Kerberos. List the
+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.,
 `joeuser@ATHENA.MIT.EDU`)
 
 full Kerberos principal of each user, one per line (e.g.,
 `joeuser@ATHENA.MIT.EDU`)
 
-## Dealing with srvtabs
-
-If you don't specifically mention a "keytab" in your request to
-Accounts, they may give you the Kerberos 4 equivalent, a srvtab.
-
-In this case you'll want to convert the srvtab to a keytab, like so.
-
-    $ ktutil
-    ktutil: rst /mit/accounts/srvtabs/FOR_JOEUSER/joeserver-new-srvtab
-    ktutil: wkt /etc/krb5.keytab
-    ktutil: q
+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.)