Automatically distributing nfs/ssh host principals
Simon Wilkinson
simon at sxw.org.uk
Tue Feb 9 12:41:55 EST 2010
On 9 Feb 2010, at 15:24, Ken Raeburn wrote:
> The idea has been kicked around before, and I believe one variant (registering a new host principal over a kadmin session protected by anonymous PKINIT) has been tried out in MIT's current development code.
What we do here is require the input of an administrator principal at installation time to create a hostclient/<hostname> principal. We then use kadmind ACLs to permit hostclient/<hostname> to create */<hostname> principals. This all has the big advantage that it works using the standard kadmind ACL syntax, and we don't need any additional logic.
We're planning on at some point moving over to Russ's wallet code to manage the creation of subsequent principals, and telling it with our configuration database which principals each machine is allowed to have.
>> Moreover, I don't think usurpating another host nfs principal has any
>> interest, and ssh has its own mechanism (host keys) to prevent spoofing.
>
> If you can change the NFS key, you can prevent people from accessing files.
Are these NFS server principals, or keys that are used by NFS clients for host-based trust?
> I don't think Kerberos-enabled SSH uses the SSH-style host keys; I think part of the point was avoiding having to have two authentication mechanisms at work. I could be wrong about that.
SSH supports either GSSAPI user authentication which still uses SSH host keys, and GSSAPI key exchange which doesn't. If you're a Kerberos site, and aren't using key exchange, you either don't have many machines, or you haven't thought hard enough about the problem.
S.
More information about the Kerberos
mailing list