An SSH private key authenticates a client; it does not tell the client which server it reached. The server’s host key and the local known_hosts database provide that second half of the identity check.

Separate first contact from rotation

With StrictHostKeyChecking=yes, SSH refuses unknown hosts and changed keys. That is the safest default for a fixed production endpoint, provided the expected key is installed through a trusted channel. accept-new is a narrower convenience for a fleet where new hosts are expected: it accepts a never-seen key but still refuses a changed key.

Host production-site
    HostName www.example.test
    User deploy
    IdentityFile ~/.ssh/site_ed25519
    StrictHostKeyChecking yes
    UserKnownHostsFile ~/.ssh/known_hosts

Do not “fix” a warning by adding StrictHostKeyChecking=no to a deployment script. That converts a useful signal into silent acceptance. If a host is rebuilt, record the replacement fingerprint and review why the old key is no longer valid.

Make the fingerprint reviewable

Obtain the fingerprint from the host owner or console before the first connection, then compare it with what the client sees. A key change should have a ticket, maintenance note, or other explanation that another operator can inspect.

The same rule applies to automation: the known-hosts file is configuration with security consequences, not disposable cache data. Back it up with the deployment record, but do not publish private keys or copied credentials with the site artifact.

Sources