Regenerating SSH host keys and the machine ID on a cloned Linux host

Goal

Give a newly cloned Linux host its own unique SSH host keys and machine ID, and confirm no other host in the fleet shares either one.

Prerequisites

Root access on the clone; the image should already have had its host keys removed and /etc/machine-id emptied before cloning (a separate cleanup step), since this methodology assumes those files are missing or empty, not populated with the reference machine's values.

Steps

1. Check whether host keys are already present: ls -l /etc/ssh/ssh_host_*. If files exist and were carried over from the reference image rather than generated on this boot, remove them first (rm -f /etc/ssh/ssh_host_*).
2. Generate a fresh set: ssh-keygen -A. The manual page documents -A as generating "host keys of all default key types (rsa, ecdsa, and ed25519) if they do not already exist," using the default file path, an empty passphrase and default bits per type — it skips any key type that is already present, so removing stale keys first (step 1) is what makes this idempotent-looking command actually regenerate them.
3. Validate, then restart the SSH daemon so it loads the new keys: sshd -t && systemctl restart sshd on RHEL/Fedora/SUSE, sshd -t && systemctl restart ssh on Debian/Ubuntu (the sshd alias there only exists while the unit is enabled). Established sessions survive the restart; clients that know the old key will see a host-key mismatch and need ssh-keygen -R <host>.
4. Check the machine ID: cat /etc/machine-id. On a clone of a properly emptied image, systemd generated and saved a new ID at boot. systemd-machine-id-setup "may be used by system installer tools to initialize the machine ID"; it only acts if the file is missing or empty, and it reuses a valid ID from /run/machine-id or the D-Bus machine ID before generating a random one. On a running clone with a duplicated ID, write a fresh value instead: systemd-id128 new > /etc/machine-id (systemd 240+; otherwise dbus-uuidgen > /etc/machine-id). Make /var/lib/dbus/machine-id a symlink to it, then reboot.
5. Verify uniqueness across the fleet: collect sha256sum /etc/ssh/ssh_host_ed25519_key.pub /etc/machine-id from every host (hash the machine ID, since the raw value is confidential) (via configuration management or a simple SSH loop) and confirm no two hosts return the same value for either.

Expected result

Each host has its own host key fingerprints (visible to clients as a different fingerprint prompt on first connection) and a distinct 32-character machine ID; no duplicate values appear across the fleet inventory.

Limits and test basis

ssh-keygen -A does nothing to a key type that already has a file present, so it cannot fix a fleet where clones already share copied keys — those must be deleted first. The machine ID manual page states it "must not be exposed in untrusted environments, in particular on the network," and that it must not be used directly as a stable identifier for other applications; if something needs a per-machine identifier, hash the machine ID with an application-specific key rather than exposing it as-is. Host-key regeneration needs no reboot. A changed machine ID does: journald, D-Bus and systemd-networkd read it at startup, and networkd derives its default DHCP DUID from it.