Differences between revisions 19 and 20
Revision 19 as of 2015-11-15 22:37:26
Size: 5602
Editor: ?RalfDragon
Comment:
Revision 20 as of 2021-03-09 16:34:44
Size: 5002
Editor: ?Felix Lechner
Comment: Remove outdated disclaimer from 12 years ago
Deletions are marked like this. Additions are marked like this.
Line 6: Line 6:

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. This guideline is dedicated for Debian Jessie installations or newer.

NFSv4 (nfs4) + Kerberos in Debian

Some pointers to getting NFSv4 going with a Kerberos system, perhaps even one similar to LDAP/Kerberos.

Overview

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 your client and server machines. This should be in the form of nfs/hostname@REALM. Each host should have a copy of its own key inside /etc/krb5.keytab. For each host, locally run kadmin -p adminuser/admin (adminuser/admin is an admin principal) with the commands:

addpriv -randkey nfs/hostnamename@REALM
ktadd nfs/clientname@REALM

The correct hostname can be found out with the command

getent hosts $(hostname) | awk '{print $1; exit}' | xargs getent hosts | awk '{print $2}'

Please note that the ktadd command invaidates all previously-issued keys reference.

Server

There is the myth that one needs to create an export root directory (having fsid=0) and bind all exported directories into it. This works, but the regular exporting as in nfs3 works and is less error-prone. I.e., the command showmount --exports works only without an export root.

Say we wish to expose /home on the server. In your /etc/exports would read:

# 'no_subtree_check' is specified to get rid of warning messages
#    about the default value changing. This is the default value
/home   192.168.1.0/24(rw,sync,no_subtree_check,sec=krb5)

(Replace the network 192.168.1.0/24 according to your desired export configuration. Please note that the older notation "gss/krb5" instead of the network results at least in some situations in errors on the client side about non-existing mount points although "showmount -e" displays them.)

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.

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

  • Your /etc/krb5.keytab file should only be readable by root.

  • Try enabling verbose messages for rpc.gssd by adding RPCGSSDOPTS="-vvv" to /etc/default/nfs-common

  • If autodetection 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
  • when tinkering with your export file, make sure to re-export with exportfs -ra

  • rpc.svcgssd on the server looks for the prinicpal nfs/reverse_lookup_of_your_ip_address (not necessary nfs/hostnameT). Check if the principal matches the return value of the above command. If necessary, you can specify this in your /etc/hosts file.

  • Errors about corrupt keyfiles in auth.log often can be resolved by deleting and re-creating keys and keyfiles.
  • Errors about "Additional pre-authentication required" in auth.log indicate that not the right keys are in the keyfiles or that some wrong encryption ciphers have been used (the default ciphers should be ok). The server should only need a server key inside, the client only the client key. Restart all nfs services after changing the keyfiles.
  • "Server not found in Kerberos database" in auth.log indicate that the key names of client or server and the respective hostnames do not match.
  • If all else fails, restart your daemons. Also try restarting nscd, as that can cause hard-to-spot caching errors.

Other tutorials and further information sources