How to configure SSH host key checking for automation

SSH automation cannot stop for the first-connection authenticity prompt, but disabling host-key checks globally hides the changed-key warning that should stop a deployment job. OpenSSH can learn a new host key without a prompt while still refusing a key that changes after it has been trusted.

OpenSSH reads client settings from command-line options, then the user's config file, then the system-wide config. A host-specific block keeps the automation policy limited to one destination or host pattern instead of weakening interactive sessions or every host matched by Host *.

A dedicated UserKnownHostsFile gives the job its own trust store. Pair StrictHostKeyChecking accept-new with BatchMode yes so unknown host keys are saved without a prompt, password and confirmation prompts fail fast, and changed host keys still stop the run.

1. Create the automation account's SSH directory if it does not already exist.

   $ install -d -m 700 ~/.ssh

2. Create a dedicated known_hosts file for the automation job.

   $ install -m 600 /dev/null ~/.ssh/known_hosts_deploy

   Use a separate file per job, environment, or service account when learned host keys should not be shared across unrelated automation.

3. Open the automation account's OpenSSH client config.

   $ vi ~/.ssh/config

4. Add a host-specific block for the automation destination.

   ~/.ssh/config

   Host deploy01.example.net
       User deploy
       IdentityFile ~/.ssh/id_ed25519_deploy
       UserKnownHostsFile ~/.ssh/known_hosts_deploy
       StrictHostKeyChecking accept-new
       BatchMode yes
       IdentitiesOnly yes

   IdentityFile should point at the private key that the remote account already accepts. IdentitiesOnly yes prevents an agent with many keys from offering unrelated identities.
   Related: How to connect with SSH using a private key
   Tool: SSH Config Snippet Generator

5. Print the effective client configuration for the automation host.

   $ ssh -G deploy01.example.net
   host deploy01.example.net
   user deploy
   hostname deploy01.example.net
   port 22
   batchmode yes
   ##### snipped #####
   identitiesonly yes
   stricthostkeychecking accept-new
   identityfile ~/.ssh/id_ed25519_deploy
   userknownhostsfile ~/.ssh/known_hosts_deploy
   ##### snipped #####

   ssh -G shows the resolved settings after Host and Match rules have been evaluated.
   Related: How to show SSH client configuration

6. Run a noninteractive smoke test through the host block.

   $ ssh deploy01.example.net whoami
   Warning: Permanently added 'deploy01.example.net' (ED25519) to the list of known hosts.
   deploy

   Let automation learn a first key only for hosts whose DNS name, address, and provisioning source are controlled. Prefill and verify the host key first when the first connection crosses an untrusted network.
   Related: How to verify SSH host key fingerprints before connecting
   Related: How to prefill SSH known_hosts with ssh-keyscan

7. Confirm that the host key was written to the dedicated known_hosts file.

   $ ssh-keygen -F deploy01.example.net -f ~/.ssh/known_hosts_deploy
   # Host deploy01.example.net found: line 1
   ##### snipped #####

8. Treat changed host keys as a stop condition for the automation job.

   $ ssh deploy01.example.net whoami
   @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
   @    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
   @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
   ##### snipped #####
   Offending ED25519 key in /home/deploy/.ssh/known_hosts_deploy:1
   Host key for deploy01.example.net has changed and you have requested strict checking.
   Host key verification failed.

   Replace the saved key only after the new fingerprint matches a trusted source such as console output, inventory, or a signed change record.
   Related: How to fix the SSH remote host identification has changed warning