How to select the private key used by a remote machine to create the known_hosts entry given to my local server - ssh

Question

Passwordless ssh has two components, user authentication and server authentication. My user authentication is fine. I have created a public private key pair and place my public key in the authorized_keys file. My question is about the public key my local machine obtains from the remote machine which is used to authenticate the remote machine I'm connecting to:
How do I select the private key used by the remote server that goes into my local server's known_hosts?
I am constantly creating and deleting remove VMs on a cloud provider on demand to save money. Unfortunately, the new VM which replaces the delete one has generated a new private-public key pair used in the known_hosts
I do not want to have to manually type ssh-keygen -R <host> for each host. I thought the easiest would be if I have a hardcoded private key on the remote server already.
Please note this is related to previous public-private key questions like ssh remote host identification has changed , but is not duplicated! I know that you can manually fix the issue with ssh-keygen -R <host>. I am looking for a more automatic approach.
Diagram:
-------------------- -----------------------
| My machine | | Remote Machine |
| - - - - - - - - -| | - - - - - - - - - - |
| Host Public Key |<---host-authentication---| ** Host Private Key |
| (known_hosts) | | |
| - - - - - - - - -| | - - - - - - - - - - |
| User Private Key |----user-authentication-->| User Public Key |
| | | (authorized_hosts) |
-------------------- -----------------------
** : How do I change this part?

Answer 1

META: this is really SysOps not programming and probably belongs on serverfault or superuser, or maybe unix.SX.
You don't say which SSH server(s) your VMs are using, although I expect cloud providers probably use OpenSSH to avoid possible license issues. IF this guess is correct sshd normally has its configuration and key files in /etc/ssh although this can be changed. See the man page on any system or on the web under FILES, duplicated here per SO convention:
/etc/ssh/ssh_host_dsa_key
/etc/ssh/ssh_host_ecdsa_key
/etc/ssh/ssh_host_ed25519_key
/etc/ssh/ssh_host_rsa_key
These files contain the private parts of the host keys. These files should only be owned by root, readable only by root, and not accessible to others. Note that sshd does not start if these files are group/world-accessible.
/etc/ssh/ssh_host_dsa_key.pub
/etc/ssh/ssh_host_ecdsa_key.pub
/etc/ssh/ssh_host_ed25519_key.pub
/etc/ssh/ssh_host_rsa_key.pub
These files contain the public parts of the host keys. These files should be world-readable but writable only by root. Their contents should match the respective private parts. These files are not really used for anything; they are provided for the convenience of the user so their contents can be copied to known hosts files. These files are created using ssh-keygen(1).
A host can have up to four keypairs for protocol v2: RSA, DSA, ECDSA, and ED25519. Very old versions only support RSA and DSA. Oldish versions don't support ED25519. Newish versions don't use DSA by default but do support it. The code still supports protocol v1 with ssh_host_key[.pub] (no algorithm in name) but v1 is way obsolete and broken and you shouldn't use it.
The man page doesn't say so that I can see, but in practice for some years now OpenSSH server usually autogenerates host keys if they are missing, either in code or in the package install/startup scripts, so just deleting keytypes you don't want may not work. Your client may be able to control which of the supported pubkey algorithms the host uses; for fairly recent versions of OpenSSH see the man page for ssh_config under HostKeyAlgorithms. Otherwise either upload all supported key types, or upload the one(s) you want and tweak the sshd_config file to not use the others or create invalid but unwritable and undeletable files for the others so sshd can't use them.
ASIDE: I would reverse your diagram. Host auth always occurs first and in practice is always pubkey (the standard has other options but they aren'[t used); client auth usually occurs second, but can be skipped, and can be either pubkey or password.

Answer 2

I ended up hacking my scripts with (which is insecure):
ssh -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null <hostname>
-o StrictHostKeyChecking=no : will accept connect to a new host
-o UserKnownHostsFile=/dev/null : saves new hosts to /dev/null so every time you ssh, it's a new host
This was originally suggested in https://askubuntu.com/questions/87449/how-to-disable-strict-host-key-checking-in-ssh to solve a similar problem.