On Tue, 2019-09-24 at 08:27 +0200, Erik Skultety wrote:
> On Mon, Sep 23, 2019 at 04:47:06PM -0400, Laine Stump wrote:
> > On 9/23/19 1:27 PM, Erik Skultety wrote:
> > > The nwfilter 220-no-ip-spoofing.t test relies on an SSH connection to
> > > the test VM. However, because the domain definition passed to libvirt
> > > lacks an RNG device, the SSH server isn't started inside the guest
> > > (even though that is the default on virt-builder images) and therefore:
> > >
> > > "ssh: connect to host 192.168.122.227 port 22: Connection refused"
> >
> > Strange that this has never happened to me. Is it perhaps because I'm using
> > a very old cached image from virt-builder, and had started it up manually at
> > some time in the past (thus giving it a long enough time to generate the
> > keys, which are now stored away for posterity)?
>
> Btw I always thought that the keys are generated during the package
> installation rather than first execution of the daemon, clearly I was wrong.
I'm going to go out on a limb and assume virt-builder templates get
their keys ripped out explicitly as part of the building process,
because of course you wouldn't want all guests created from the same
virt-builder template to share a single set of SSH keys, now would
you? :)
My recollection about sshd was that it did this the first time the service was started, but of course that me.ory is at least 10 years old, and so is suspect from the start!
This has started me thinking again about the problem we have with the creation of the default network at package installation time (I don't have access to bugzilla right now to reference the BZ, but want to write this down before I forget - I'm talking about the deal where we decide on the subnet to use during a postinstall script, and that potentially creates a conflict if libvirtd is later run in a different network environment than when it was installed).
Anyway, maybe we should try mimicking what sshd does for it's initial run (or maybe not, since we need to do our stuff after the host networking has completely started and settled, but sshd has no such dependency. On the other hand, sshd does manage to properly delay setting up it's keys until it is running on the "final destination" system rather than doing it e.g. when a booting a live image (which will then be used to do a "copy everything en masse" install to the final destination).