Description of problem:
in combination with hashicorp packer and cloud-init, SSH host keys are not regenerated, when new VM instances are created. This could lead to the MITM attack.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Create a simple rhel7 image using packer
2. Create instances using this image
3. Notice that all these images share the same SSH host keys
SSH keys are not regenerated when new instance is created
SSH keys should be regenerated
When cloud-init was created for rhel, the "ssh_deletekeys" option was explicitly set to "false" and "ssh_genkeytypes" option was set to be empty (https://git.centos.org/blob/rpms!cloud-init.git/c7/SOURCES!0001-configuration-changes-for-RHEL-package.patch#L66). Most probably it was done because "cloud-init.service" has "Wants=sshd-keygen.service" (https://github.com/cloud-init/cloud-init/blob/master/systemd/cloud-init.service.tmpl#L6), which actually is responsible to regenerate ssh keys (https://git.centos.org/blob/rpms!openssh.git/c7/SOURCES!sshd-keygen.service). However "sshd-keygen.service" doesn't have a logic to detect whether current VM instance was just created or not. "cloud-init" has this logic.
Other distors, like SLES or Ubuntu, both rely on cloud-init logic, but not on "sshd-keygen.service" to regenerate SSH host keys.
Tested with rhel-7.9(3.10.0-1128.el7.x86_64) + cloud-init-19.4-2.el7.x86_64, the issue is fixed.
1. There's "ssh_deletekeys: 1" and "ssh_genkeytypes: ~" in /etc/cloud/cloud.cfg.
2. Compare the content of /etc/ssh/ssh_host_*key* between VM1 and image:
The content are different between VM1 and image.
SSH host keys are regenerated for the new instance.
Change the status to VERIFIED.