When an SSH host key changes, is it rotation or interception?

An OpenSSH client refuses or prompts when a server presents a host key that differs from the entry in known_hosts. The protocol itself cannot tell whether the change is a controlled re-provisioning or a man-in-the-middle attack, so the decision falls entirely on the operator at that moment.

The client-side settings are documented but easy to misread. StrictHostKeyChecking yes blocks changed keys outright; accept-new trusts keys never seen before but still rejects replacements; ask leaves the choice to whoever is at the terminal. None of these modes explains why a key changed, and exact defaults vary across OpenSSH versions and vendor builds.

For a team managing many hosts, the unresolved question is what policy should govern the moment a mismatch appears.

• Should every mismatch be treated as a potential incident, with the replacement key confirmed through an out-of-band channel before known_hosts is edited?
• Is accept-new a reasonable default for ephemeral infrastructure where re-provisioning is routine, or does it train people to approve key changes reflexively?
• Can automated key distribution remove the human judgment call entirely, and what does that imply for detecting a compromised endpoint?