Ask Your Question

NFS server: How to realize authentication?

asked 2016-08-03 10:08:49 -0500

gobigobi66 gravatar image

Hi, I set up an NFS server as central file server on one of my machines. Besides the transfer being super slow (~300kB/s), which I will have to find a solution for, I would like to enable authentication. How to do that?

I know I can use hosts.allow or hosts.deny and define an IP range of my home network, and in exports I can also define which IP/host/IP range can access the share. That's OK, but in a DHCP environment not a really good measure to exclude others that using the network from my share.

Is there simple solution to use authentication (preferably based on the server's user accounts) like I do with samba?

Thanks, Matt

edit retag flag offensive close merge delete

2 Answers

Sort by ยป oldest newest most voted

answered 2016-08-03 15:00:54 -0500

Problem Overview

Unfortunately, NFS security solutions are few and complex. Originally, the NFSv4 specification designers had intended to make mandatory support for the Simple Public Key Mechanism (SPKM3) and the Low-Infrastructure Public Key mechanism (LIPKEY) which would have allowed for the use of simple username/password authentication from a client to an arbitrary database accessible to the NFSv4 server. However, flaws were found in SPKM3/LIPKEY which could not be resolved, and so the supporting code was removed from the Linux kernel.

Now, all we're left with is roughly two layers of controls:

  1. Standard IP-based controls (which can be combined with IPsec to address network-based attacks such as router compromises or IP/MAC spoofing by connecting client systems). You mention TCP wrappers, but using firewalld rules to limit client access and stuff like that is ok, too.
  2. Client authentication using either the AUTH_SYS (UID/GID-based authentication, relying on the integrity of client systems) or Kerberos services.

You could set up a Kerberos environment for your home network if you're enterprising, but unless you'd benefit from the learning exercise, it's probably not worth the time and effort. Currently, however, that's the only solution of which I am aware when it comes to authenticating clients for NFSv4 in Fedora (and any other Linux-based distribution).

It may not work for all use cases, but for standard home network use cases, I'd recommend securing your routing device, ensuring strong LAN security, and then reserving IP addresses for client systems based on their MAC addresses. Then, narrowly define your NFS shares (i.e. limit the data accessible to any given client) and your attack surface will be pretty limited.

SSH Port Forwarding Solution for the Desperate

If you really, really need user-based authentication for your NFS shares, you could do the following:

  1. Configure NFS shares on your file server, but do not permit any clients other than the local host.
  2. Configure sshd on your file server to allow local TCP port forwarding.
  3. Configure client systems to establish SSH tunnels to the file server's port 2049 (e.g. ssh -L 2049:localhost:2049 username@fileserver)
  4. After establishing the port forward using SSH, mount the NFS share on the client using the port forward (e.g. mount localhost/whatever /mnt)

It works (I use a similar process for establishing remote connections to a home server when I am away from home), and you end up with the encryption and authentication capabilities of OpenSSH supporting your NFS share. Given that sshd works with PAM, you can probably get this to work with just about any authentication scheme you can imagine. So long as you keep port 2049 firewalled on your file server, no one can access your NFS shares unless they first make use of the SSH port forwarding solution to get to them.

Though it seems weird (and it is), it's actually pretty simple to use once it's set up. You can even write a simple little script ... (more)

edit flag offensive delete link more


@bitwiseoperator: Thanks for your detailed answer. The SSH solution would be really nice, maybe it's a bit exaggerated in my case. I guess, I am going back to IP based access control for now. I am not yet comfortable setting up Kerberos (it would be a nice exercise though - but I doubt I find the time). What's behinde AUTH_SYS?

And, would you guys actually recommend me using SMB? That has relatively easy access control. Though, not sure about performance (but my NFS has been slooooow too so far). Thanks everyone for your assistance!

gobigobi66 gravatar imagegobigobi66 ( 2016-08-04 09:40:54 -0500 )edit

What I am learning here: NFS is not the most secure file transfer protocol per se.

Can anyone point to a easy guide on how to implement AUTH_SYS with NFSv4? Thanks!

gobigobi66 gravatar imagegobigobi66 ( 2016-08-04 09:44:39 -0500 )edit

AUTH_SYS is a reference to the built-in (to the Linux kernel) authentication mechanism. It is the subsystem which accepts UIDs and GIDs (albeit in ASCII name form for NFS) and managed permissions thereby.

NFS alone is a clear-text protocol, just like SMB. The authentication information is encrypted if using Kerberos, but if using AUTH_SYS, it's a plain-text rendering of the user name and group name under which the NFS request is to be processed. NFS is intended for use on a secure local area network (just like SMB), so that's why it's designed that way (just like SMB).

bitwiseoperator gravatar imagebitwiseoperator ( 2016-08-08 13:34:04 -0500 )edit

So basically, you're not getting superior security in terms of data encryption if you choose SMB over NFS. AUTH_SYS is the default authentication mechanism for NFS.

bitwiseoperator gravatar imagebitwiseoperator ( 2016-08-08 13:37:47 -0500 )edit

If you would elaborate on the particular attack vector which concerns you, we can discuss in more detail whether or not NFS is suitable for use when facing a heightened risk across that vector. Generally speaking, NFS is not recommended for use when dealing with secure data, especially over a hostile network such as the Internet. With SSH encryption, it can be made more suitable, but without Kerberos, compromised client systems are still big risks, since they dictate to the NFS server which permissions should be applied to their requests.

bitwiseoperator gravatar imagebitwiseoperator ( 2016-08-08 13:38:31 -0500 )edit

answered 2016-08-03 18:47:46 -0500

sixpack13 gravatar image

nfs speed: man nfs => resize and wsize

tested month/years ago (maybe outdated): best was with rsize=32768,wsize=32768

edit flag offensive delete link more


Thanks. I will try this!

gobigobi66 gravatar imagegobigobi66 ( 2016-08-04 09:29:58 -0500 )edit

in recent versions of NFS (v3, and v4), client and server negotiate rsize and wsize. I would not recommend setting it manually. run grep "nfs" /proc/mounts to see the negotiated values (of course after mounting)

florian gravatar imageflorian ( 2017-05-05 12:18:57 -0500 )edit

Question Tools



Asked: 2016-08-03 10:08:49 -0500

Seen: 8,664 times

Last updated: Aug 03 '16