NFSv4 (nfs4) + Kerberos in Debian
Some pointers to getting NFSv4 going with a Kerberos system, perhaps even one similar to LDAP/Kerberos.
Overview
Once one has a nice LDAP/Kerberos system running, one might want to mount filesystems across servers. After a bit of research, it seems that as of 2009-07-18 NFS is still the preferred way to do that between a bunch of Debian machines. NFS does have one horribly broken component to it which this tutorial hopes to solve: host-based authentication. By using Kerberos instead, hosts are required to prove identity in order to mount your filesystem instead of blindly assuming that the IP they're connecting from is genuine.
Start by installing:
nfs-kernel-server (on the server)
nfs-common (on both client and server)
Read through /usr/share/doc/nfs-common/README.Debian.nfsv4. It's a great introduction to this. From here on, it is assumed that you've read this document and may still be struggling to get it going.
Client and Server
Create an nfs Kerberos principal for both your client and server machines. This should be in the form of nfs/hostname@REALM and a copy should be placed in /etc/krb5.keytab. You may need to export it, specifying the encryption method using the following:
kadmin: ktadd -e des-cbc-crc:normal -k /tmp/my.keytab nfs/hostname@REALM
Your /etc/krb5.keytab file should only be readable by root.
There are three different modes that nfs can operate in with Kerberos, which should be specified in the mount/export options:
krb5 Use Kerberos for authentication only.
krb5i Use Kerberos for authentication, and include a hash with each transaction to ensure integrity. Traffic can still be intercepted and examined, but modifications to the traffic will be apparent.
krb5p Use Kerberos for authentication, and encrypt all traffic between the client and server. This is the most secure, but also incurs the most load.
Server
You need to create the export root. All nfs4 exports will be off this path.
Say we wish to expose /home on the server. We need to create a root path for nfs4 (we put it at /export, but you can put it wherever you'd like):
$ mkdir -p /export/home $ mount --bind /home /export/home
In your /etc/fstab, the last line would read:
/home /export/home none ro,bind 0 0
In your /etc/exports would read:
# 'fsid=0' designates this path as the nfs4 root # 'crossmnt' is necessary to properly expose the paths # 'no_subtree_check' is specified to get rid of warning messages # about the default value changing. This is the default value /export gss/krb5(rw,sync,fsid=0,no_subtree_check,crossmnt) /export/home gss/krb5(rw,sync,no_subtree_check)
Client
On the client side, mount in the following way:
$ mount -t nfs4 -o sec=krb5 nfs4-server.example.com:/home /home
If you don't specify the type, it may fall back on nfs3, which will probably error on you.
Tips
Try enabling verbose messages for rpc.gssd by adding RPCGSSDOPTS="-vvv" to /etc/default/nfs-common
If autodetction fails, edit /etc/default/nfs-common to enable idmapd, gssd on the clients + server and /etc/default/nfs-kernel-server to enable svcgssd on the server.
ensure your Kerberos domains are correctly configured. This includes in your krb5.conf file; nfs seems to use it to get the realm. This also seems to imply that servers must be in the form of HOST.domain, where domain is common to both the server and client.
- Make sure your domain is specified in /etc/idmapd.conf
- Also take note that you must leave off the root when mounting on the client.
when tinkering with your export file, make sure to re-export with exportfs -ra
If you successfully mount a path, but it shows up empty, add crossmnt to the nfs4 root options in the exports file.
rpc.svcgssd on the server looks for the prinicpal nfs/reverse_lookup_of_your_ip_address (not nfs/SOMETHING_YOU_CAN_SET). Make sure that the reverse lookup is set. If necessary, you can specify this in your /etc/hosts file.
If all else fails, restart your daemons. Also try restarting nscd, as that can cause hard-to-spot caching errors.