Accessing Kerberos NFS version 4 (not 2, 3) via /net automounter with kinit only (no /etc/krb5.conf access)

Simo Sorce simo at redhat.com
Tue Apr 15 15:13:09 EDT 2014


On Tue, 2014-04-15 at 13:48 -0500, Will Fiveash wrote:
> On Tue, Apr 15, 2014 at 11:36:34AM -0500, Nico Williams wrote:
> > Will,
> > 
> > Mobile devices don't really have stable hostnames, so the system
> > should support non-hostbased host/root credentials.
> 
> If you are referring to the NFS v4 client requiring root have a krb cred
> in order to function as I described in an earlier e-mail I would ask why
> NFS v4 clients require root to have a krb cred in the first place (NFS
> v3 doesn't as you may recall)?  As you can imagine, many IT departments
> would balk (putting it mildly) if they were asked to provision keytabs
> on laptops or other mobile devices that need access to krb protected NFS
> v4 shares.
> 
> As to how that requirement happened, according to one of the NFSv4
> developers here that regularly attends Connectathon, the consensus among
> the NFS v4 implementors for various Linux platforms was that a properly
> configured NFS v4 client meant it had a keytab containing host service
> princ keys which could then be leveraged to protect the lease renewal
> traffic.  My opinion is that unless there is a very good reason to
> protect that traffic, krb protection for lease renewal traffic should be
> optional, depending on configuration.


There is a good reason to require a keytab on a client if you use
kerberos for authentication to the machine, and that is that you need
validation for login.

You also need a host key if you want to allow to use gssapi
authentication for ssh.

So it is not too far fetched to expect to find a host key on every
machine participating to a kerberos REALM.

That said it is unclear to me why the NFSv4 server should try to use a
new channel to communicate with the client instead of just using the
existing channel the client opened against the server.

Opening back channels from servers have been proven brittle (firewalls,
NAT, etc.. all get in the way) time and again since ages, seem someone
hasn't learned their lesson.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York



More information about the Kerberos mailing list