Differences between revisions 21 and 22
Revision 21 as of 2021-03-09 17:09:30
Size: 5899
Editor: ?Felix Lechner
Comment: Explain use of non-default keytabs with systemd
Revision 22 as of 2021-03-09 17:14:10
Size: 5834
Editor: ?Felix Lechner
Comment: Bump header levels in document hierarchy access to sections via URL
Deletions are marked like this. Additions are marked like this.
Line 4: Line 4:

== Overview ==
Line 13: Line 11:
=== Client and Server === == Client and Server ==
Line 30: Line 28:
=== Keytab location === == Keytab location ==
Line 42: Line 40:
=== Server === == Server ==
Line 61: Line 59:
=== Client === == Client ==
Line 84: Line 82:
== Other tutorials and further information sources == == See also ==

NFSv4 (nfs4) + Kerberos in Debian

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

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.

Keytab location

On servers it may make sense to isolate privileges for different services in separate keytabs stored in /etc/keytab/*. From a security perspective, that can be an improvement over the unified default location in /etc/krb5.keytab. For consistency across machines, you may end up doing so even on your clients.

When using custom keytab locations via the -k switches in /etc/default/nfs-common, the systemd scripts that ship with nfs-utils will still prevent the two services rpc-svcgssd and rpc-gssd from starting. You may have to drop the following statements from those service files:

ConditionPathExists=/etc/krb5.keytab

The GSS services for NFSv4 run as root already, so they are not by themselves a good reason to split up the keytabs. The question arises when you also offer services like LDAP or PostgreSQL.

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.

See also