Am 24.02.23 um 13:11 schrieb Jan Schermer:> One solution I used was simply scripting the deletion of the host key after cloning it. > Another solution is to delete them in the golden image you create (which could be a different scenario from cloning whatever machine you need)The golden image can not have a hard wired magic which generates new host keys, as it is maintained from time to time using ssh.> Both approaches worked well enough except when they didn?t.I think, I have seen this, too.> It would be great to be able to specify path to hostkey including some sort of $hostname variable, so it would be regenerated if hostname changes, but that is probably better solved in a startup script. Maybe modifying it to create a symlink from the hostkey to a filename including hostname? I wonder how fragile that would be and if something like that already exists. Not sure if MAC or hostname are the right distinguishing parameters, though, maybe something like dmidecode UUID?The MAC is my weapon of choice, because no matter what virtualization you have, this will (in a sense, it hast to) change. Changing the hostname comes with the Ansible stuff, but this is already too late.> JanThanks Jan.
> On 24. 2. 2023, at 13:25, Keine Eile <keine-eile at e-mail.de> wrote: > > Am 24.02.23 um 13:11 schrieb Jan Schermer: >> One solution I used was simply scripting the deletion of the host key after cloning it. >> Another solution is to delete them in the golden image you create (which could be a different scenario from cloning whatever machine you need) > > The golden image can not have a hard wired magic which generates new host keys, as it is maintained from time to time using ssh.Right, that is what I did - stuff like apt update/upgrade or yum upgrade, pushing new versions of other stuff and then right before shutdown and turning it back into golden image I deleted the hostkeys, dhcp leases, logs and other state files.> >> Both approaches worked well enough except when they didn?t. > > I think, I have seen this, too. > >> It would be great to be able to specify path to hostkey including some sort of $hostname variable, so it would be regenerated if hostname changes, but that is probably better solved in a startup script. Maybe modifying it to create a symlink from the hostkey to a filename including hostname? I wonder how fragile that would be and if something like that already exists. Not sure if MAC or hostname are the right distinguishing parameters, though, maybe something like dmidecode UUID? > > The MAC is my weapon of choice, because no matter what virtualization you have, this will (in a sense, it hast to) change. Changing the hostname comes with the Ansible stuff, but this is already too late. >Hmm, I usually get hostnames from DHCP/cloud-init etc. This is where this magic should happen in theory. I guess looking for cloud-init hooks could turn up something that already exists?>> Jan > > Thanks Jan. > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://www.google.com/url?q=https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev&source=gmail-imap&ust=1677846468000000&usg=AOvVaw3QfyRqSVP6ds-YjBi_a9iN
Are you doing any other first-boot initialization on the cloned VMs? Are you (or could you) use cloud-init for this? If so, you can run: ??? cloud-init clean [--seed] [--logs] [--machine-id] before cloning - or inside the cloned image using guestfish etc. I'm not sure if this actually removes the existing host keys, but if it doesn't, you could manually rm them as well. Then optionally you can provide cloud-init metadata when the clones boot if you want to set different network parameters, or perform other initialization like creating additional user accounts etc.
On 2023/02/24 13:25, Keine Eile wrote:> The MAC is my weapon of choice, because no matter what virtualization > you have, this will (in a sense, it hast to) change. Changing the > hostname comes with the Ansible stuff, but this is already too late.Regenerating host keys if the MAC changes is no good in the general case. Firstly, *which* MAC, there can be more than one. Secondly, if you legitimately replace a NIC/motherboard due to hardware failure (or move disks between motherboards etc) you'll generate new keys when you shouldn't. This isn't unique to SSH; there are other files depending on the software involved which might include /etc/machine-id, saved RNG seeds, IPv6 SOII keys, which need removing when preparing to clone.