Kerberos and nfs4

This page will provide a fairly simple 'howto' for setting up kerberos with nfs, for nfs4 (version 4 nfs)

References used for this item:

MIT Kerberos Admin’s Guide

krb-nfs howto

linux-nfs Kerberos end-user doc

nfs configuration

See also: Kerberos for birds not dummies

NFS, version 4 issues

What is similar

Nfs4 is very much like 2 and 3; one sets up the exports on the server, and adds entries in /etc/fstab on the client.

Important Differences

(1) Exporting of pseudofilesystems

Nfs4 uses “pseudofilesystems” for its exports. so, rather than just exporting as is done in v2 and v3, one creates an export point, and (for ease of management) bind mounts the desired exported filesystems into that export point. the example will likely make this clearer.

(2) krb authentication, identification, and privacy

Nfs4 also can use kerberos to assist in identification of client and server, and also encryption of the nfs traffic. Use of krb entails a bit more complexity in the configuration. i.e. there are more ways to break things.

Set up the NFS server

kerberos

Copy the krb5.conf file from the kerb server to the nfs server.

Either on the kerberos admin server, with kadmin.local, or on the nfs server, using kadmin, add the nfs service as a principal:

addprinc -randkey nfs/my-nfs-server.riseup.net

Create a keytab for the nfs server:

ktadd -k /path/to/output/krb5.keytab  nfs/my-nfs.server.riseup.net

Scp or cp that keytab file to the nfs server, ensuring that it is either named as the default /etc/krb5.keytab or is defined in the krb5.conf file.

Configuration Files

/etc/idmapd.conf this file should have Domain set to the kerberos domain/realm

[General]

Verbosity = 0
Pipefs-Directory = /var/lib/nfs/rpc_pipefs
Domain = riseup.net

[Mapping]

Nobody-User = nobody
Nobody-Group = nogroup

[Translation]
Method = nsswitch

/etc/default/nfs-common there is a need to start these daemons for nfs4

NEED_STATD=yes
NEED_IDMAPD=yes
NEED_GSSD=yes

/etc/default/nfs-kernel-server

NEED_SVCGSSD=yes
# DEBUG MODE   Options for rpc.svcgssd.
RPCSVCGSSDOPTS=" -vvv "

If necessary (due to multi-realm kerberos needs, identify, in both /etc/default/nfs* files, that krb5.conf file and export the environment variable:

export KRB5_CONFIG=/etc/krb5.some-other.conf

Set up the pseudofilesystem for exporting:

Create the base export directory:

mkdir /export

Bind mount whatever filesystems you really want to export

mount -t bind /usr/local/blah /export/blah
mount -t bind /var/lib/bork   /export/bork

This should provide

ls /export

blah
bork

Edit your /etc/exports file. Three examples are provided: (1) simple nfs (2) kerberos of three types: with authentication, integrity, privacy

nfs4 like nfs v2 and v3 (no pseudofilesystem needed)

/some/path/to/exported_images        client-hostname(async,rw,root_squash,no_subtree_check)

nfs4 with krb authentication of client and server (pseudofilesystem /exports ):

/exports        gss/krb5(sec=krb5,rw,insecure,sync,wdelay,no_subtree_check,no_root_squash,fsid=0)
/exports/some-directory        gss/krb5(sec=krb5,rw,insecure,sync,wdelay,no_subtree_check,nohide,anonuid=65534,anongid=65534)

nfs4 with krb integrity (pseudofilesystem needed):

/exports        gss/krb5i(sec=krb5i,rw,insecure,sync,wdelay,no_subtree_check,no_root_squash,fsid=0)
/exports/some-directory        gss/krb5i(sec=krb5i,rw,insecure,sync,wdelay,no_subtree_check,nohide,anonuid=65534,anongid=65534)

nfs4 with krb privacy (pseudofilesystem needed):

/exports        gss/krb5p(sec=krb5p,rw,insecure,sync,wdelay,no_subtree_check,no_root_squash,fsid=0)
/exports/some-directory        gss/krb5p(sec=krb5p,rw,insecure,sync,wdelay,no_subtree_check,nohide,anonuid=65534,anongid=65534)

Restart services: /etc/init.d/nfs-common restart ; /etc/init.d/nfs-kernel-server restart

Set up the NFS client

Kerberos

Copy the krb5.conf file from the admin server (or the nfs server).

Create the keytab file as was done with the nfs server, and scp the keytab to the nfs client.

Edit the /etc/idmapd.conf file as was done with the server.

Edit the /etc/default/nfs-common file as was done with the server.

fstab

Depending on how the server implements its /etc/exports, the fstab will have corresponding fstab entries.

(1) simple nfs

nfs-server.riseup.net:/path/to/exported/dir   /import/dir  nfs   rsize=8192,wsize=8192,nodev,rw  1       0

(2) kerberos with authentication, integrity, and privacy:


# authentication-only
nfs-server.riseup.net:/        /import        nfs4        sec=krb5,rw,sync,proto=tcp     0    0

# integrity also
nfs-server.riseup.net:/        /import        nfs4        sec=krb5i,rw,sync,proto=tcp    0    0

# privacy also
nfs-server.riseup.net:/        /import        nfs4        sec=krb5p,rw,sync,proto=tcp    0    0

Note either upon restarting /etc/init.d/nfs-common or, after that, trying to kerberos-mount the filesystem, you should see a kerberos ticket in /tmp , /tmp/krb5cc_machine_RISEUP.NET and you can do a klist on it:

root@nfs-client:/etc# klist -e /tmp/krb5cc_machine_RISEUP.NET
Ticket cache: FILE:/tmp/krb5cc_machine_RISEUP.NET
Default principal: nfs/nfs-client.riseup.net@RISEUP.NET

Valid starting     Expires            Service principal
04/12/10 06:25:11  04/12/10 16:25:11  krbtgt/RISEUP.NEt@RISEUP.NET
        renew until 04/13/10 06:25:02, Etype (skey, tkt): AES-256 CTS mode with 96-bit SHA-1 HMAC, AES-256 CTS mode with 96-bit SHA-1 HMAC
04/12/10 06:25:11  04/12/10 16:25:11  nfs/nfs-server.riseup.net@RISEUP.NET
        renew until 04/13/10 06:25:02, Etype (skey, tkt): DES cbc mode with CRC-32, DES cbc mode with CRC-32

UIDs and GIDs

In order for the client to maintain the UID and GID map with nfs, the file /etc/idmapd.conf must be edited. Ensure at least that the Domain matches the kerberos realm/domain that you’re using.

/etc# cat /etc/idmapd.conf
[General]
Verbosity = 0
Pipefs-Directory = /var/lib/nfs/rpc_pipefs
Domain = riseup.net

[Mapping]
Nobody-User = nobody
Nobody-Group = nogroup

[Translation]
Method = nsswitch

note I’m not sure if the server needs this too.

How users can access an nfs mount

“regular” users by default may not access an nfs4-krb mount, unless they have a userid that is a kerberos “principal” and they have a kerberos ticket. Thus, if a user ssh’s in to a machine, and the ssh is using pam_krb to the same realm as the machine uses for nfs, then the user can access the mount. Otherwise, the user should get a kerberos ticket prior to accessing the mount, e.g.:

kinit  username@RISEUP.NET