SSH known_hosts and host key verification for automation: ssh-keyscan plus an out-of-band check

Goal

Populate known_hosts for a server an automated process (an agent, a deploy pipeline) must connect to over SSH, without leaving the connection open to a machine-in-the-middle on first contact, and without an interactive "yes/no" prompt that breaks unattended runs.

Prerequisites

Network access to the target host's SSH port; a way to obtain the host's key fingerprint from a channel other than the SSH connection itself (cloud provider console output, configuration management inventory, the host's own provisioning log).

Steps

1. Harvest the key into a staging file, not straight into known_hosts: ssh-keyscan -H targethost > targethost.keys (add -p <port> for a non-default port). The -H flag hashes the hostname in the stored entry so a leaked file does not reveal which hosts are trusted. The man page warns that a known_hosts file built with ssh-keyscan without verifying the keys leaves users open to machine-in-the-middle attacks — it records whatever key the host presents.
2. Verify out-of-band, then append: ssh-keygen -lf targethost.keys prints the fingerprints of exactly what was scanned; compare them against a fingerprint obtained independently, and only on a match run cat targethost.keys >> ~/.ssh/known_hosts. Independent sources: a cloud provider's instance console log, a value recorded at provisioning time, or an SSHFP DNS record if the zone is signed. RFC 4255 defines the SSHFP resource record for exactly this: publishing a host key fingerprint in DNS so a client can check it without a prior manual trust decision, and ssh can be configured to consult it via VerifyHostKeyDNS.
3. Configure the client's behaviour for unattended connections in ssh_config: StrictHostKeyChecking accept-new (OpenSSH 7.6 and later, documented in ssh_config(5)) adds keys for hosts not yet in known_hosts without prompting, but still refuses to connect if a known host presents a different key — unlike StrictHostKeyChecking no, which also lets connections to a host with a changed key proceed (with a warning and some restrictions) and should not be used for automation.
4. Set HashKnownHosts yes (also in ssh_config(5)) so any known_hosts file that leaks or is committed by mistake does not enumerate the infrastructure's hostnames. The upstream default is no (Debian/Ubuntu's shipped /etc/ssh/ssh_config sets yes), and it only affects newly added entries; ssh-keygen -H hashes an existing file.

Expected result

A first connection to a newly provisioned host succeeds non-interactively once its key has been recorded and out-of-band verified; a later connection to the same address after its host key changes unexpectedly (host reimaged, or a genuine machine-in-the-middle) fails loudly instead of silently updating.

Limits and test basis

accept-new protects against a key that changes after first trust, not against a bad key accepted the first time — the out-of-band check in step 2 is what step 3 cannot provide on its own. SSHFP verification is only as trustworthy as the DNS zone. VerifyHostKeyDNS defaults to no; set to yes, ssh_config(5) says keys matching a secure (DNSSEC-validated) fingerprint are trusted implicitly, while insecure fingerprints are handled as if the option were ask, i.e. the answer is only shown and StrictHostKeyChecking still decides. A result counts as secure only if a validating resolver sets the AD flag and the client accepts it — with glibc 2.31 and later that requires options trust-ad in /etc/resolv.conf.