Hi list members, does any one of you have a best practice on renewing ssh host keys on cloned machines? I have a customer who never thought about that, while cloning all VMs from one template. Now all machines have the exact same host key. My approach would be to store a machines MAC address(es). Then when starting the sshd.service, check if this MAC has changed. If so, remove all host keys, let sshd create new ones. Thanks for any thoughts and comments about that.
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) Both approaches worked well enough except when they didn?t. 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? Jan> On 24. 2. 2023, at 12:58, Keine Eile <keine-eile at e-mail.de> wrote: > > Hi list members, > > does any one of you have a best practice on renewing ssh host keys on cloned machines? > I have a customer who never thought about that, while cloning all VMs from one template. Now all machines have the exact same host key. > My approach would be to store a machines MAC address(es). Then when starting the sshd.service, check if this MAC has changed. If so, remove all host keys, let sshd create new ones. > > Thanks for any thoughts and comments about that. > _______________________________________________ > 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=1677844875000000&usg=AOvVaw1wDCGYuQ4a5KUjpWj0GLtO
Hey. Keep in mind that when you clone the template image and replace/delete the template image's SSH host keys (and the same applies to other such key material as well) in the clone... then chances are good that the data is nevertheless still accessible from within the clone (depending on the used fs, whether DISCARD is used, IO patterns and so on). If the subsequent owner of the clone is not fully trustworthy, and extraction of the template image's keys might be possible and could be used in subsequent attacks. Cheers, Chris.
On Fri, 24 Feb 2023, Keine Eile wrote:> does any one of you have a best practice on renewing ssh host keys on cloned > machines?Yes: not cloning machines. There?s too many things to take care of for these. The VM UUID in libvirt. The systemd machine ID. SSH hostkey and SSL private key. The RNG seed. The various places where the hostname is written to during software installation. The inode generation IDs, depending on the filesystem. Other things that are created depending on the machine and OS? such as the Debian popcon host ID, even. The effort to clean/regenerate these and possibly more, which, in addition, often needs new per-machine random bytes introduced, is more than just installing fresh machines all the time, especially if you script that (in which I personally even consider moving a? way from d-i with preseed and towards debootstrap with (scripted) manual pre? (partitioning, mkfs, ?) and post-steps). This is even more true as every new machine tends to get just the little bit of difference from the old ones that is easier to make when not cloning (such as different filesystem layout, software). I know, this is not the answer you want to hear, but it?s the one that works reliably, without investing too much while still being not 100% sure you caught everything. (Fun fact on the side, while doing admin stuff at $dayjob, I even didn?t automate VM creation as clicking through d-i those times I was installing some took less time in summary than creating auto? mation for it would?ve. I used xlax (like clusterssh, but for any X11 window) for starting installation, then d-i network-console + cssh for the remainder; a private APT repository with config pak? kages, to install dependencies and configure some things, rounded it off.) bye, //mirabilos -- Infrastrukturexperte ? tarent solutions GmbH Am Dickobskreuz 10, D-53121 Bonn ? http://www.tarent.de/ Telephon +49 228 54881-393 ? Fax: +49 228 54881-235 HRB AG Bonn 5168 ? USt-ID (VAT): DE122264941 Gesch?ftsf?hrer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg **************************************************** /?\ The UTF-8 Ribbon ??? Campaign against Mit dem tarent-Newsletter nichts mehr verpassen: ??? HTML eMail! Also, https://www.tarent.de/newsletter ??? header encryption! ****************************************************