From Linux NFS

Revision as of 16:19, 8 June 2017

Common NFS4 Misunderstandings

Here are some distribution specific guidelines which have been tested on openSUSE and Ubuntu. They attempt to clarify the installation of secure NFS4 on a Linux systems.

Source: Steve Sheriff, steve.lcb@gmail.com

Please note that I am not a Linux expert and that I do not usually use English in my day to day life.

These notes were written after I faced the task of installing secure NFS4 for a heterogeneous LAN of openSUSE, Ubuntu and Windows clients under a Samba 4 Active Directory PDC. This was tested and reproduced on budget hardware. The largest cost for any single component of the LAN was the licence to activate Windows 7 Professional, needed to join Microsoft clients to AD.

I have written this in an attempt to encourage all of us who find ourselves in similar administrative roles, to maintain a centralised repository of correct information, written in plain English, on modern Linux distributions. I also hope that it will serve to dispel many of the myths I read during the installation and save the countless forays I made into uncharted territory.

Myth: NFS4 must be exported from an fsid=0 pseudo root directory. e.g. I am exporting the /home directory to the clients. The /etc/exports file could be either of these examples.

e.g. 1. How not to do it /home is bind mounted to chmod'ed 1777 /exports /etc/exports /export gss/krb5(rw,fsid=0,insecure,no_subtree_check,crossmnt) /export/home gss/krb5(rw,insecure,no_subtree_check) /export gss/krb5i(rw,fsid=0,insecure,no_subtree_check,crossmnt) /export/home gss/krb5i(rw,insecure,no_subtree_check) /export gss/krb5(rw,fsid=0,insecure,no_subtree_check,crossmnt) /export/home gss/krb5(rw,insecure,no_subtree_check) /export *(rw,fsid=0,insecure,no_subtree_check) /export *(rw,nohide,insecure,no_subtree_check)

e.g. 2 . Simply use the familiar nfs3 export method. /etc/exports /home *(rw,sec=none:sys:krb5:krb5i:krb5p,no_subtree_check)

Choice of 5 flavours for mounting on the client.

Please see the comment above: 'The linux implementation allows you. . .'

Myth: you must use the nohide option for the bind mount to be visible on the client. You can use crossmnt on the pseudoroot or nohide on the bind mount. Or neither and use simply the conventional nfs3 syntex for /etc/exports.

Myth: NFS4 can only use weak DES cryptography e.g. you have been told that NFS4 can only use weak DES cryptography and so you need the line: [libdefaults] allow_weak_crypto = true added to /etc/krb5.conf Not needed. Tested using arcfour-hmac-md5 with kernels 3.1.9-1.4-desktop (openSUSE 12.1) and 3.0.0-15-default** (Ubuntu 11.10) **need to check the uname -r output on Ubuntu. Am writing his on openSUSE

Myth: NFS4 needs only the nfs/fqdn@REALM principal in it's keytab No. It needs the machine principal too. rpc.gssd will not allow you to make a test mount on the server (e.g. to test by mounting to /mnt) unless the machine principal is there along with the nfs principal in the keytab. Myth: The client must have a nfs/client.domain principal in its No. It doesn't need to have one. From man rpc.gssd(8) Previous versions of rpc.gssd used only "nfs/*" keys found within the keytab. To be more consistent with other implementations, we now look for specific keytab entries. The search order for keytabs to be used for "machine credentials" is now:

<HOSTNAME>$@<REALM>

root/<hostname>@<REALM>

nfs/<hostname>@<REALM>

host/<hostname>@<REALM>

root/<anyname>@<REALM>

nfs/<anyname>@<REALM>

host/<anyname>@<REALM>

A real life example. hh3.hh3.site is my server and HH6$@HH3.SITE is the machine principal for the client. On the client, issue a: mount -t nfs4 hh3:/foo /bar -o sec=krb5

Kerberos: ENC-TS Pre-authentication succeeded -- HH6$@HH3.SITE using arcfour-hmac-md5

Kerberos: AS-REQ authtime: 2012-02-06T19:44:47 starttime: unset endtime: 2012-02-07T05:44:47 renew till: 2012-02-07T19:44:47

Kerberos: Client supported enctypes: aes256-cts-hmac-sha1-96, aes128-cts-hmac-sha1-96, des3-cbc-sha1, arcfour-hmac-md5, des-cbc-crc, des-cbc-md5, des-cbc-md4, using arcfour-hmac-md5/arcfour-hmac-md5

Kerberos: Requested flags: renewable-ok

Kerberos: TGS-REQ HH6$@HH3.SITE from ipv4:192.168.1.10:45421 for nfs/hh3.hh3.site@HH3.SITE [canonicalize, renewable]

Kerberos: TGS-REQ authtime: 2012-02-06T19:44:47 starttime: 2012-02-06T19:44:47 endtime: 2012-02-07T05:44:47 renew till: 20

But remember from above, that the nfs server must be able to identify itself. In this example,

klist -ke /etc/krb5.keytab

Keytab name: WRFILE:/etc/krb5.keytab

KVNO Principal

  1 nfs/hh3.hh3.site@HH3.SITE (arcfour-hmac)  
  1 HH3$@hh3.site (arcfour-hmac)