> Or a way to grant access without relying on IP whitelists.

You can use Kerberos.

But then you must use Kerberos authentication (password only) and can't use SSH public key authentication.

Thats simply not true. GSSAPI allows you to forward kerberos tokens over ssh, with or without passwords or keys.

You misunderstood. The problem is not forwarding Kerberos tokens, the problem is obtaining Kerberos tokens. Unless some extensions are employed, you need to use password authentication. Even if kerberos extensions are employed, you must still use kerberos auth instead of ssh public keys. If you try to use ssh public key authentication (instead of telling ssh to use kerberos authentication) you can't log-in to the machine because you can't access your home filesystem, which is kerberised. In fact, depending on your configuration, you might not be able to log-in at all since the user's filesystem might not be mounted at all (waiting for the automounter).

If you want to store user directories on kerberized NFS, users must use kerberos authentication.

Kerberos actually operates on keys. The nfs service key is typically a random one stashed in the keytab.

I don't understand the objection to Kerberos tickets -- it's a single-sign-on system. You can obtain a ticket with a public key if you want, see e.g. http://www.h5l.org/manual/HEAD/info/heimdal/Setting-up-PK_00... I don't know how easy it aould be to use SSH keys, but I once designed an authentication system for a scientific facility that was based on PGP keys and a web of trust reflecting administrative/social structures in the days before things like Eduroam and (viable?) NFS4, but not before AFS, which has been successfully used in the same way for a long time.

I don't know why anyone would think "Kerberized" wouldn't involve Kerberos, but it's nothing specific to user directories.

OrangeFS (nee PVFS) is a userland parallel filesystem (with a kernel driver in Linux) that can use two types of public key security if you want that sort of thing, but I gather that's not widely used.

You can use kerberos for authentication, and also encrypt traffic [0].

> krb5p Use Kerberos for authentication, and encrypt all traffic between the client and server.

[0] https://wiki.debian.org/NFS/Kerberos

NFS tends to be living in the kernel, which sounds like a terrible place for TLS. That said, IPSec lives in the kernel to some extent, you could layer NFS on top of ipsec....

Linux and FreeBSD have both got kernel TLS support (not sure if freebsd got merged yet but Netflix have used it fir a while)

Netflix's TLS support is an extremely limited hack that suits their performance needs. It does not support initial session negotiation or rekeying. They do the former in userspace before handing off a symmetric key to the kernel, and drop connections in the latter case, relying on the client to reconnect. There's no chance it will be merged to FreeBSD; it's not a general solution.

As long as we're talking about TLS and IPSec, though, I'd point to Wireguard as maybe something viable for kernel use.

The Linux kernel TLS support does the same.

For what it's worth, NFS-Ganesha is a serious userland server.

NFS had (presumably still does) a private(?) key security option, but the Solaris fileservers I last used had given up on that in favour of Kerberos.