SSH StrictHostKeyChecking: Choose a Safe Policy for Each Host

A script that connects to a new server can stall at an SSH fingerprint prompt. Setting StrictHostKeyChecking=no may seem like the easy fix, but it also weakens how SSH handles a server whose identity changes later.

The right choice depends on whether you want to approve new hosts manually, provision trusted keys ahead of time, or allow first connections automatically while still rejecting unexpected changes.

What SSH is checking

SSH verifies both sides of a connection. Your private key or password helps authenticate you to the server; the server's host key helps your client verify the server's identity.

On first connection, SSH has no saved key for that host. Once accepted, the key is recorded in a known-hosts file, typically ~/.ssh/known_hosts. On a later connection, SSH compares the presented key with the saved one. A mismatch can mean a legitimate rebuild or key rotation, but it can also mean you reached a different machine than expected.

StrictHostKeyChecking controls how OpenSSH responds to unknown and changed host keys. It does not decide whether the server accepts your login credentials.

If you want a deeper explanation of the client-side SSH configuration file, it can help to think of this option as a per-host policy rather than a global switch.

The four policies, in practical terms

Setting	New host	Changed host	Typical use
ask	Prompt before saving	Reject	Interactive connections; OpenSSH default
yes	Reject until key is provisioned	Reject	Strict environments with preloaded host keys
accept-new	Save automatically	Reject	Automation that permits first use but detects later changes
no / off	Save automatically	Allow connection, subject to restrictions	Deliberate, exceptional relaxation

For a person connecting at a terminal, ask is usually a sensible default. You see the fingerprint and decide whether to trust it. That approval is meaningful only if you can verify the fingerprint through a trusted source when needed.

For unattended jobs, accept-new often provides a useful compromise: no prompt on first contact, but a changed key still causes the connection to fail.

ssh -o StrictHostKeyChecking=accept-new user@host

Use yes when your process provisions known host keys ahead of time and should fail closed if a key is missing or different. This is stricter, but it requires that provisioning step to be reliable.

Set a policy for one connection or one host

The -o option applies a client configuration setting to a single SSH invocation:

ssh -o StrictHostKeyChecking=ask user@host

For a repeat connection, put the policy in ~/.ssh/config under a specific host alias:

Host staging
    HostName staging.example.com
    User deploy
    StrictHostKeyChecking accept-new

Then connect with:

ssh staging

Keeping the setting scoped to the hosts that need it avoids weakening host verification for every SSH connection. Be especially cautious about placing StrictHostKeyChecking no under Host *.

If a setting appears not to take effect, inspect what OpenSSH resolved for a host:

ssh -G staging | grep -i stricthostkeychecking

The same -o syntax can be used with SCP, for example:

scp -o StrictHostKeyChecking=accept-new ./file.txt user@host:/tmp/

When a host key changes, investigate first

A changed key can be expected after a server rebuild, host-key regeneration, or an IP address reassignment. It can also be a sign that the connection is reaching an unexpected machine. Don't remove the old record just to clear the warning.

First, confirm the new fingerprint through a trusted channel. An administrator with access to the server can inspect its Ed25519 host-key fingerprint with:

ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub

If the change is expected and the fingerprint matches, remove the obsolete entry for the hostname and reconnect:

ssh-keygen -R example.com
ssh [e-mail]

If you also connect to that server by IP address, check that entry separately. This safe workflow for a changed SSH host identity covers the trust-checking steps in more detail.

Why no is not the same as accept-new

This command is often copied into scripts to suppress a first-use prompt:

ssh -o StrictHostKeyChecking=no user@host

But no is not just a non-interactive version of ask. It relaxes how SSH handles changed host keys, whereas accept-new automatically records new hosts and still rejects a key change later.

OpenSSH may also restrict features when it detects an offending changed key, even with no. For example, authentication methods or forwarding features can be limited. If a connection behaves unexpectedly after a host-key warning, adding more options may hide the real problem rather than fix it.

You may also see UserKnownHostsFile=/dev/null paired with no. These settings do different things: StrictHostKeyChecking controls the checking policy, while UserKnownHostsFile controls where user host keys are read and stored. Sending that file to /dev/null prevents keeping a useful user-level trust history there, so it removes more protection than changing the checking policy alone.

A simple decision guide

• Interactive terminal: keep ask and review the fingerprint prompt.
• Automation with pre-provisioned host keys: use yes so missing or changed trust information fails.
• Automation that can trust first use: use accept-new to accept new keys while rejecting later changes.
• no: reserve it for cases where you deliberately accept weaker identity verification and understand the tradeoff.

A host key is how your SSH client recognizes the server. Avoid treating a changed-key warning as a nuisance to silence: verify the new identity, then update the trust record if the change is legitimate.

I originally published a more detailed version of this guide on the SSHFlow blog.

I'm also building SSHFlow — an SSH client where every server gets its own workspace for terminals, SFTP, code, and databases.