[CentOS-virt] server host keys for kvm clones

Hi James,

depending on your use case:

if you source is a template VM: just delete the keys prior to cloning
in the source VM

if you source is a production VM: just delete the keys after cloning
on the newly cloned VM

The keys will be regenerated on next startup of openssh if they're
missing.

am Mittwoch, 4. Januar 2012 um 20:08 schrieben Sie:

you should script all that (and the rest of the uinique things you want)
into rc.local

isnt rc.local run quite a bit later down the run order ?

Personally, I hate images. Provisioning from fresh is easy enough, fast
enough and manageable enough that images are almost always either the
wrong solution or a by-product requirement from a third party tool that
does not understand provisioning ( hello, all those so-called-cloud
solutions .. )

I feel this way too. However, many people espousing imaging are so
adamant. I don't argue because it just isn't worth it. Whatever they
feel comfortable with as long as I'm not responsible for the result.

It depends heavily on the ending result . If you just need a fresh
machine, installing from fresh is ( was for me at least ) the fastest
way. OTOH when you also have a ton of additional applications (maybe not
all of them available as rpm packages) installed / configured... things
might be different.

I can accept that custom applications might be easier to include
in images. Creating a RPM or install script for a rarely installed
program may not make the top of the priority list. However, if it is
installed identically on multiple systems, it could be converted to rpm
or a scripted install, which could be included in an automated clean
install. As an example, I uuencode my current DHCP configuration, DNS
files, firewall rules and openvpn certificates into a kickstart file to
cleanly install my firewalls. Each is different but is scripted, partly
in the scripts that create my kickstart files and partly in the
kickstart post section.

My colleagues from the engineering dept ( I am IT... ) have to use a
commercial application which comes as 2 CD images plus 3 sets of 2 isos
with updates. All of which have to be installed (at last theoretically )
one after the other and only via their own Java-based installer.
Guess who is not going to rpm-ize the process of installing that 8*450
MB piece of wonderful software.

And by the way, there are 50% chances that this piece of software was
used in the process of design of your phone. At least if the phone was
engineered after 2000.

Nice. The company I work for uses some MS Windows software where the
vendor won't even give me install software. They insist the user must
call them to install. The user must log into their website to get
access to the install software. I don't have a log in, so I don't
pre-install that software. The users complain to me and I refer them to
the vendor. Yes, some vendors are annoying.

It sounds like maybe you'd prefer clean installs but, due to real
world compromises, you can't always do that.

In time trials at PMman, we can deploy a minimal CentOS 5 or
6 base image in under three minutes from a standing start,
already configured with local update archive addon, the needed
LVM details, the needed network config settings, and all the
rest; doing the same with anaconda and puppet takes about 15
minutes

There _are_ reasons for thoughtfully designed deployable
'stock' images

-- Russ herrold

Hi Karanbir,
well, there IS at least one valid scenario, where you want to deploy
an image in an environment not supported by anaconda/kickstart. A
prime example is the ALIX mainboard series, where the boards usually
come with soldered 128 or 256 MB RAM, CF Flash Reader and a AMD GeoDE
processor.

I had fun rebuilding anaconda once to even bootstrap those (AMD GeoDE
is somehow falsely recognized as i586 by CentOS 5.7), just to
find out I had to add an additional USB key for swap to even get it to
install. ( see http://bugs.centos.org/view.php?id%52 for details )

There are ready-made CentOS images for these type of boards available
on the net (ssh keys removed ;-) ) and these actually allow for an easy
provisioning of the CF cards.

Sadly CentOS6 does not even support the processor any more.

Is there a process for pre-generating keys so these keys
and .ssh/known_hosts can be pre-filled for all users/hosts?

I dislike upgrading servers. I use kickstart from updated sources
with integrated configuration files on a new virtual disk to produce an
upgraded server without touching the live server. This gives me the
chance to test the new server prior to making it live and verifies I can
reproduce a failed server at need. Also, this allows me to restage
firewalls automatically on a schedule. Let's see a rootkit survive a
clean install.

Currently, I'm allowing the keys to be regenerated, but it gets
annoying editing my known hosts to remove old entries.

There's got to be a better way.

yes there is..

look at the sshd initscript, and poke the do_*_keygen functions; they
will tell you exactly what happens when those keys are auto-build on
first boot, or when someone removes them.

I use config-management tools in the kickstart %post to drop in
pre-built keys, that also means my management infrastructure already
knows what key-signature to expect on a remote machine when it boots for
the first time and I can do some level of trust management based on
that. Keep in mind that you need to have your provisioning happen in a
fairly secure environment itself, if you are going to add trust points
on signatures like this - specially if they are 'generated' on demand.

Other than installing from a separate network, which is difficult with
multiple locations and virtual machines (creating them in a central
place then transferring them across the Internet seems unwieldy), what
steps can we take to secure the provisioning?

The init script /etc/rc.d/init.d/sshd handles it.

I discover that simply removing the existing ssh keys from
/etc/ssh and restarting the sshd service causes the host
keys to be regenerated.

Another step to add to post cloning housekeeping.