Over the years I've watched Kerberos and related tools from afar,
interested in the idea, but not interested enough to figure out the
installation, configuration, etc. Well, in an attempt to secure
assorted NFS mounts around my home, I decided to take the plunge
today and install NFSv4 + Kerberos. Here are my notes for my
Gentoo systems, mostly following the Kerberos install
guide. I'll use the following settings for my examples:

Setup the NFS server

Now we'll setup NFSv4 using Kerberos authentication. There
don't seem to be authoritative docs, but there are a number of good
tutorials (1, 2, 3,
4).

Emerge nfs-utils with the kerberos USE flag set
(homepage). You may also want app-crypt/kstart
(homepage) to automatically renew your server and client
tickets. Now is also a good time to check your kernel config. I was
missing CRYPTO_CTS, which lead to

Since we'll be running the NFS service, we'll need a
nfs/<fqdn>@REALM principal for the service. Because we want that
service to start automatically at boot, we neek to keep its key in a
keytab file (krb manual).

You need use kadmin.local here (instead of kadmin) so the process
has premission to create and edit the keytab file.

Read through /etc/idmapd.conf to see if you need to make any changes
for your setup. I set Domain = d.net and Local-Realms = R.EDU.
You probably also want to look through /etc/conf.d/nfs. I added
-vvv to OPTS_RPC_GSSD, OPTS_RPC_IDMAPD, and OPTS_RPC_SVCGSSD
to aid in debugging.

Setup your export filesystem. NFSv4 wants all its exports to live
under a single root, so do something like:

Note that the syntax has changed somewhat, and there seem to have been
a few versions of the NFSv4 syntax. exports(5) should contain good
documentation for whatever version of nfs-utils you have installed
on your system.

If you used mount --bind to populate /export, make sure you add
appropriate entries to /etc/fstab so the mounts come up when you
reboot.

Then scp the new keyfile over to /etc/krb5.keytab on the client
and remove the temporary version from the host. You can list the keys
in a keytab with klist -e -k /path/to/keytab if you find a keytab
lying around but forget what's inside it.

On the client, you'll need gssd and idmapd running (both part of
nfs-utils).

# /etc/init.d/rpc.gssd start
# /etc/init.d/rpc.idmapd start

There's no need to add these to your default runlevel, since they
should be started automatically if you have NFSv4 entries in your
/etc/fstab (I have no idea how that works).

Other stuff

If you hadn't had the kerberos USE flag set before, you should
consider adding it to your /etc/make.conf and running

$ sudo emerge -av --deep --newuse --update @world

to get Kerberized versions of any packages you have installed
(e.g. cups, curl, cvs, emacs, openssh, most SASL libraries,
...).

For details on using Kerberos with SSH, check out the excellent
description in the SSH definative guide. The key elements are
host/<fqdn>@REALM principals for each host (with keyfiles on each
server) and appropriate enabling of the GSSAPI* options in
sshd_config and ssh_config.

There's also suite of Kerberos-aware utilities in
app-crypt/mit-krb5-appl (krcp, krlogin, krsh, ktelnet, and
kftp). I don't use the non-Kerberized versions, so I haven't tried
any of these.

If you're using MPD on an NFS-mounted music repository, you might
be interested in my kinit-mpd.sh script for granting the mpd
user access to the NFS-mounted music as the nobody principal.

For debugging, check out the KRB5_TRACE environment variable. I
sent some patches upstream to integrate reverse DNS debugging
into the KRB5_TRACE framework. The patches will go live with the
next major krb5 release after the 1.10 series.