Home / server / Questions / 604618
Accepted
Cosmic Ossifrage
Asked: 2014-06-13 03:45:03 +0800 CST

NFS client keytab: multiple machines

  • 772

How should one go about setting up client-side keytab files for each client machine to access network services? My working example is NFSv4, which requires each client to have a Kerberos keytab locally on the client machines (as well as the NFS server hosts).

  1. What badness, if any, could result from sharing the same key in a generic keytab file (for NFS purposes) between all client machines requiring access to the NFS host(s)?

  2. If, from the result of #1, we really do need to use a separate key in a different keytab on every client, what is an effective -- and, more importantly, secure -- way to automate the creation of the keytab for each of several thousand machines? I don't want to have to generate and export a key on every box!

linux

2 Answers

  1. Best Answer

    A generic keytab is no use at all - the Kerberos Service Principle is tied to hostname. So a generic keytab simply won't work. You don't necessarily need an NFS specific key - depending which OS version you're using. We can use HOST/full.qualified.hostname to authenticate NFS on RHEL 6+.

    So yes, you do need a keytab on each machine. I know that's horrible, but that's the way of things.

    Bear in mind that in a Windows domain, you have to do effectively the same thing with your 'domain join' process - one of the major things that does is create a keytab on Windows clients.

    We've started down the road of integrated domains - binding our Linux clients to a Windows AD. With that approach, you can use the net command on Linux e.g. net ads join which is I think part of SAMBA. You can embed into it a username and password, and run it via whatever existing automation mechanism you have already. (net ads keytab create also does .... well exactly what it says on the tin. )

    If you're not using an AD, then I'm afraid I don't know. I would imagine that something similar exists for generating a keytab.

    • 2

  2. I have written code to solve your problem, but it won't work for everybody. The problem is that you have to figure out some way to extend trust to untrusted hardware. Every site will have a slightly different way to do that.

    I use an ssh key that is installed by our configuration management to extend trust to untrusted machines.

    The code I wrote is in

    https://github.com/bbense/aeakos

    But it's really more of an outline of how to solve the difficult problem of automated install of keytabs.

    As far as using a generic keytab for a client, that can work for some kerberos based services, but I have never seen that used for kerberized NFS. And in general you want at least a host/foo.com on every machine to take full advantage of what kerberos can offer. If you can't do that, there is little point in deploying kerberos.

    In theory a generic client keytab should work if you want every machine to have access to the same servers/files. In practice, you'd have to do a through analysis of how the nfs server uses kerberos authentication to implement authorization to make sure that everything works correctly.

    Part of using kerberos successfully is to remember it only does authentication, authorization is always specific to the application. Everything I've done with NFSV4 suggests that it expects a unique kerberos id per client host, but I've no evidence that it requires one.

    • 1