How to Use SSHFP Records in DNS to Verify SSH Host Keys and Prevent Man-in-the-Middle Attacks

Whose.Domains

security SSHFP DNS SSH host key verification DNSSEC cybersecurity

James Chen July 16, 2026 1 views

The Hidden Danger in Every SSH Connection

Every time you SSH into a server, your client receives the server’s public key. On the first connection, you see a prompt: “The authenticity of host … can’t be established. Are you sure you want to continue connecting?” Most people type “yes” without a second thought. That single yes is the exact moment a man-in-the-middle attack can strike.

If an attacker intercepts that first connection, they can present their own key, and you’ll accept it blindly. From then on, they can decrypt, modify, or capture everything you send. This trust-on-first-use (TOFU) model is a well-known weakness in SSH. The solution? SSHFP records in DNS – a way to publish your server’s host key fingerprint so clients can verify it automatically, even on the very first connection.

What Are SSHFP Records?

SSHFP (SSH Fingerprint) is a DNS record type defined in RFC 4255. It stores the cryptographic fingerprint of a server’s SSH host key. When your SSH client resolves the hostname, it checks the DNS for SSHFP records, fetch the fingerprint, and compares it with the key the server presents. If they match, the connection proceeds without a prompt. If they don’t, SSH aborts the connection or warns you.

The record contains three pieces of information:

Algorithm: 1 for RSA, 2 for DSA, 3 for ECDSA, 4 for Ed25519
Fingerprint type: 1 for SHA-1, 2 for SHA-256
Fingerprint hash: The hex-encoded hash of the public key

Why Bother? Two Real-World Scenarios

Consider a developer working from a coffee shop. The public Wi‑Fi is untrusted. Without SSHFP, the first SSH connection could be hijacked by a rogue access point. With SSHFP, the client queries DNS (ideally secured with DNSSEC) and refuses to connect if the fingerprint doesn’t match.

Or picture a company managing 50 servers. The system administrator updates a key pair. Without SSHFP, every user sees a scary “host key changed” warning. They don’t know if it’s a legitimate rotation or an attack. With SSHFP, the DNS record is updated at the same time, and clients automatically accept the new key – no manual intervention required.

Step-by-Step: How to Set Up SSHFP Records

1. Generate the Fingerprint from Your Server

SSH into your server and use the ssh-keygen command with the -r (render) flag:

$ ssh-keygen -r example.com

This outputs one or more DNS record lines. For example:

example.com. IN SSHFP 4 2 d4ca... (for Ed25519 key)
example.com. IN SSHFP 1 2 7e2f... (for RSA key)

Pro tip: Include all active host key types on your server. If you use both RSA and Ed25519, add both records.

2. Add the Records to Your DNS Zone

Edit your DNS zone file (or your DNS provider’s interface) and add the SSHFP records. Example for BIND:

$ORIGIN example.com.
; SSHFP records
@   IN SSHFP 1 2 7e2f... (your RSA SHA-256 hash)
@   IN SSHFP 4 2 d4ca... (your Ed25519 SHA-256 hash)

If you’re using a cloud DNS provider like Cloudflare, Route53, or Google Cloud DNS, look for “SSHFP” in the record type dropdown. Paste the entire line (without the trailing dot if not needed).

After saving, verify the record propagated correctly using Whose.Domains DNS Analyzer. Enter your domain and look for SSHFP records in the results. The tool will also show you the TTL and answer section – everything you need to confirm it’s live.

3. Configure Your SSH Client to Check DNS

Edit your ~/.ssh/ssh_config or /etc/ssh/ssh_config and add:

Host *
    VerifyHostKeyDNS yes

Or, for a one-time test, use the command-line flag:

$ ssh -o "VerifyHostKeyDNS yes" [email protected]

With this setting, the client will automatically fetch and verify the SSHFP record. If the fingerprint matches, you’ll see no prompt. If it doesn’t, the connection is aborted with a warning.

4. Test It – Forward and Backward

First, confirm that a client with VerifyHostKeyDNS=yes can connect without prompting. Then, temporarily modify your server’s host key (e.g., ssh-keygen -A on a test server) and update the SSHFP record with a wrong hash. The client should refuse the connection, proving that the protection works.

Security Considerations: DNSSEC Is Strongly Recommended

SSHFP records are only as good as the DNS that delivers them. If an attacker can spoof DNS responses, they can also serve fake SSHFP records. The solution is DNSSEC. When the client (via a validating resolver) sees a DNSSEC‑signed SSHFP record, it can trust the answer hasn’t been tampered with. Many modern SSH clients respect this automatically.

To verify if your domain is DNSSEC‑signed, use the DNS Analyzer and look for the “DNSSEC” field. If it shows “Signed,” you’re covered. If not, consider enabling DNSSEC at your registrar and DNS provider.

Automating SSHFP Updates During Key Rotations

When you rotate a host key (a best practice every 6–12 months), you must also update the SSHFP record. Manual updates are error‑prone. Automate it with a script:

#!/bin/bash
SERVER="web01.example.com"
ssh-keygen -r "$SERVER" | while read line; do
    # Send this line to your DNS API (e.g., via nsupdate or provider API)
    echo "Updating SSHFP: $line"
done

If you use Infrastructure as Code (Terraform, Ansible), include SSHFP records as part of your server provisioning playbook. This ensures the DNS record is always consistent with the actual key.

When You Shouldn’t Use SSHFP (Yet)

SSHFP is supported by OpenSSH since version 5.4 (2010). Most modern clients include it, but some legacy systems (e.g., older enterprise SSH implementations) do not. Additionally, if your DNS isn’t secured by DNSSEC, SSHFP provides only partial protection – better than nothing, but not bulletproof. Also, SSHFP relies on the client having network connectivity to DNS. For offline or air‑gapped environments, alternative methods like known_hosts distribution are more appropriate.

Real-World Example: A Multi-Server Deployment

Let’s say you run five application servers behind a load balancer. Each server has its own host key (or you use a shared key). By adding SSHFP records for each FQDN (app1.example.com, app2.example.com, etc.), your team can SSH directly to any server without seeing a single warning. Later, when you replace app3 with a new server, you simply update the DNS record for that hostname. Everyone’s SSH client will trust the new key immediately.

Conclusion: Stop Clicking “Yes” Blindly

SSHFP records are a simple, powerful tool to eliminate the biggest security gap in SSH: the trust‑on‑first‑use problem. With a few minutes of setup and a commitment to keeping DNS records in sync with your keys, you can protect every SSH connection from man‑in‑the‑middle attacks, even on untrusted networks.

Start today:

Generate fingerprints with ssh-keygen -r
Add SSHFP records to your DNS zone
Verify propagation using Whose.Domains DNS Analyzer
Enable DNSSEC for your domain
Configure clients with VerifyHostKeyDNS yes

Your servers – and your users – will thank you.