The StrictHostKeyChecking blindspot: Why disabling SSH host key verification in automation invites trivial man-in-the-middle attacks across your fleet.

When automating infrastructure deployments using Ansible, CI/CD pipelines, or bastion jump hosts, engineers frequently encounter the dreaded OpenSSH prompt: ``The authenticity of host '10.0.1.5' can't be established. Are you sure you want to continue connecting (yes/no)?``

Because interactive prompts break unattended automation, developers routinely disable host key checking in their Ansible configs, CI runner scripts, or user profiles: ``StrictHostKeyChecking=no`` and ``UserKnownHostsFile=/dev/null``.

This single operational shortcut completely dismantles SSH security:

1. Elimination of Mutual Authentication: SSH provides end-to-end encryption only if the client cryptographically verifies that the server is genuinely who it claims to be. Setting ``StrictHostKeyChecking=no`` blinds the client: any attacker capable of performing ARP poisoning, DNS spoofing, or BGP route hijacking can position themselves as an active man-in-the-middle (MITM). 2. Transparent Credential Interception: The attacker's rogue SSH server terminates the connection, intercepts user passwords or forwards private SSH agent requests, and transparently logs all interactive keystrokes before forwarding traffic to the real target. 3. The "accept-new" Half-Measure: Setting ``StrictHostKeyChecking=accept-new`` blindly trusts the server on first connection (TOFU). If the attacker intercepts the initial provisioning run of a newly created node, that fraudulent key is permanently trusted.

Hardening enterprise SSH requires eliminating manual host key prompts through cryptographic infrastructure: • Publish Cryptographic SSHFP Records in DNSSEC: Use OpenSSH ``ssh-keygen -r <hostname>`` to generate SSHFP records containing SHA-256 fingerprints of your host public keys. Publish these records in your DNSSEC-validated zone and configure clients with ``VerifyHostKeyDNS=yes``. Clients automatically verify the server's public key against DNSSEC with zero interactive prompts. • Deploy an Enterprise OpenSSH Certificate Authority (CA): Create a dedicated offline SSH Host CA in FreeIPA. Sign all newly provisioned server host public keys during cloud-init/kickstart deployment (``HostCertificate /etc/ssh/ssh_host_rsa_key-cert.pub``). • Single Fleet-Wide Trust Anchor: In client ``/etc/ssh/ssh_known_hosts``, add a single entry declaring the CA public key: ``@cert-authority *.example.com ssh-ed25519 AAAAC3...``. Clients now trust every present and future server signed by the CA automatically, with zero prompts and zero MITM risk. • Automated Host Key Rotation: Centralized CAs enable automated expiration dates and effortless host key rotation across thousands of bare-metal and cloud nodes.

Eliminate manual prompts, stop blind SSH bypasses, and secure remote administrative access.

Deploy enterprise identity and PKI infrastructure with our 2-week Enterprise FreeIPA HA & Centralized PKI/CA Sprint on Contra: https://contra.com/s/ALrNLqlg-enterprise-free-ipa-ha-and-centralized-pkica-infrastructure

#Security #CyberSecurity #Linux #DevOps #Infrastructure #IdentityManagement #SRE