[Infrastructures] Distributing private key information at install time

[Daniel Clark]

On 10/2/06, Willemse, Menno <Menno.Willemse@johnguest.co.uk> wrote:
> Hello World,
>
> Here's a problem that I'm sure some of the larger sites have solved already, and that just isn't irritating enough for me to solve it here and now due to a lack of circular tuits. Since there is an infrastructure angle to this, I decided to post it here.
>
> Whenever I reinstall a machine, I set up secure shell on the box, and every time it will run ssh-keygen to make host keys. And then SSH gets all annoyed at me because the host key has changed and I have to remove it from known_hosts to assure SSH that it's allright really. Not just me, actually. Everybody has to do that for each name under which they ever accessed the box. So what you really need is a way to restore the original host keys, so that all the ssh clients will have the correct information already.
>
> This always gets me thinking: Is there a cryptographically sound way to restore the key information to the client from a file on the install server? You can't get it from an NFS server. My first instinct is to create an install image with a known private key, and to trust that key to fetch the real key at install time. But this is obviously vulnerable to the install image's key being stolen. It needs to be on an NFS server as I use NIM for AIX. For Linux, it's FAI.
>
> Now I know that the only truly secure method is to carry the key over to the machine in question on a floppy and then burn the floppy, but I'm willing to settle for "Reasonably Secure", as long as the whole method is hands-off. I may not have that many Unix boxes now, but we may get a lot of Linux workstations in the future.
>
> What is everybody else doing?

This is one one of the main plugins system example cases for the Bcfg2
(http://www.bcfg2.org) configuration management system.

"[This problem] makes the ideal case for the plugin interface, since
(a) all admins know the problem well, and (b) can easily envision a
solution to it, but (c) no one does."
-- Narayan Desai, primary developer of Bcfg2

>From ftp://ftp.mcs.anl.gov/pub/bcfg/papers/pay-as-you-go.pdf :

"""
5.2 SSHbase

SSHbase is a ssh key management system. It maintains a repository of ssh
public and private keys and constructs a comprehensive ssh known hosts file.
It functions entirely automatically; new keys are generated when one
is requested
for an unknown host. At this point, the ssh known hosts file is updated for all
clients.

The repository language used by this generator consists of a directory
containing
public and private keys for all clients. This system ensures two basic
properties. First, client keys persist beyond client rebuilds. Second,
client keys
can be centrally revoked, in case of a system compromise.
"""

I think sites that use Kerberos 5 can use Simon Wilkinson's OpenSSH
patches (www.sxw.org.uk/computing/patches/openssh.html) to sidestep
this issue by relying on Kerberos 5 for mutual authentication instead
of host keys. Of course, in that case you have the problem of keeping
a client's Kerberos 5 client credentials between rebuilds.

-- 
Daniel Joseph Barnhart Clark
http://www.pobox.com/users/dclark