References used for this item:
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.
(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¶
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.
/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
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:
Set up the pseudofilesystem for exporting:¶
Create the base export directory:
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)
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¶
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.
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.: