What Is an SSHFP Record

An SSHFP (SSH Fingerprint) record publishes the fingerprint of an SSH server's host key in DNS. This allows SSH clients to verify a server's identity through DNS instead of relying solely on the "trust on first use" (TOFU) model.

How SSHFP Records Work

When you first connect to an SSH server, you see a message like:

The authenticity of host 'server.example.com' can't be established.
ED25519 key fingerprint is SHA256:abc123...
Are you sure you want to continue connecting (yes/no)?

Most users type "yes" without verifying the fingerprint, which leaves them vulnerable to man-in-the-middle attacks. SSHFP records solve this by publishing the expected fingerprint in DNS:

server.example.com.    3600    SSHFP    4 2 e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855

SSH clients configured to use SSHFP will verify the server's key against DNS automatically, eliminating the prompt entirely when the fingerprint matches.

Record Components

Algorithm Values

Ed25519 (algorithm 4) is the recommended choice for new deployments. It produces shorter keys and fingerprints while providing strong security. RSA remains necessary for compatibility with older clients. DSA (algorithm 2) is deprecated and should not be used for new SSHFP records.

Fingerprint Type Values

Always use fingerprint type 2 (SHA-256). SHA-1 (type 1) is considered cryptographically weak and should not be relied upon for security. Many modern SSH clients will ignore SHA-1 SSHFP records entirely.

Common Use Cases

Single SSH Server

Publish all key types for comprehensive coverage:

server.example.com.    3600    SSHFP    1 2 abc123...  ; RSA
server.example.com.    3600    SSHFP    3 2 def456...  ; ECDSA
server.example.com.    3600    SSHFP    4 2 ghi789...  ; Ed25519

Publishing multiple algorithm types ensures that clients can verify the connection regardless of which key algorithm is negotiated during the SSH handshake.

Multiple Servers

server1.example.com.    3600    SSHFP    4 2 hash1...
server2.example.com.    3600    SSHFP    4 2 hash2...
git.example.com.        3600    SSHFP    4 2 hash3...

Bastion/Jump Host

bastion.example.com.    3600    SSHFP    4 2 abc123...
bastion.example.com.    3600    SSHFP    3 2 def456...

Bastion hosts are particularly good candidates for SSHFP because they are typically the first point of SSH access into your infrastructure and benefit most from strong identity verification.

Record Format

Generating SSHFP Records

Using ssh-keygen

The easiest method is ssh-keygen -r, which reads the host keys from the local system and outputs them in DNS record format:

# Generate SSHFP records for all host keys on the local machine
ssh-keygen -r server.example.com
 
# Output:
# server.example.com IN SSHFP 1 1 abc123...  (RSA, SHA-1)
# server.example.com IN SSHFP 1 2 abc456...  (RSA, SHA-256)
# server.example.com IN SSHFP 3 1 def123...  (ECDSA, SHA-1)
# server.example.com IN SSHFP 3 2 def456...  (ECDSA, SHA-256)
# server.example.com IN SSHFP 4 1 ghi123...  (Ed25519, SHA-1)
# server.example.com IN SSHFP 4 2 ghi789...  (Ed25519, SHA-256)

The command produces records for both SHA-1 and SHA-256. Only publish the SHA-256 (type 2) records -- ignore the SHA-1 lines.

From a Specific Key File

If you want to generate an SSHFP record for a specific key rather than all host keys:

# Generate from a specific public key file
ssh-keygen -r server.example.com -f /etc/ssh/ssh_host_ed25519_key.pub

From Remote Server

# Get fingerprint from remote server
ssh-keyscan server.example.com | ssh-keygen -r server.example.com -f /dev/stdin

When using ssh-keyscan, verify the output through a trusted channel before publishing. If the server is already compromised, ssh-keyscan will return the attacker's keys.

Manual Calculation

# For a specific key file
awk '{print $2}' /etc/ssh/ssh_host_ed25519_key.pub | \
  base64 -d | \
  sha256sum | \
  awk '{print $1}'

DNSSEC Requirement

For SSHFP to provide real security, your zone must be DNSSEC-signed. This is not optional -- it is a fundamental requirement:

• With DNSSEC: SSHFP provides cryptographic proof of server identity. The SSH client can trust the fingerprint because the entire DNS chain is authenticated.
• Without DNSSEC: SSHFP is informational only. An attacker who can spoof DNS responses can also spoof SSHFP records, making the verification meaningless.

OpenSSH's VerifyHostKeyDNS setting will report SSHFP matches as "verified" only when the DNS response is DNSSEC-validated. Without DNSSEC, it reports "unverified" and still prompts the user.

Check DNSSEC status:

# Verify DNSSEC validation on the SSHFP response
dig +dnssec server.example.com SSHFP
 
# Look for the 'ad' (authenticated data) flag in the response header
dig +dnssec +short server.example.com SSHFP

For more on DNS security, see DNS Attacks and Threats.

Adding an SSHFP Record

Using the Dashboard

1. Navigate to your zone in the DNScale dashboard
2. Click Add Record
3. Configure the record:
   • Name: Enter the server hostname (e.g., server)
   • Type: Select SSHFP
   • Algorithm: Select the key algorithm (RSA, ECDSA, Ed25519)
   • Fingerprint Type: Select SHA-256 (recommended)
   • Fingerprint: Enter the hex-encoded fingerprint
   • TTL: Set the cache duration (default: 3600)
4. Click Create Record

Using the API

Create an SSHFP record:

curl -X POST "https://api.dnscale.eu/v1/zones/{zone_id}/records" \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "server",
    "type": "SSHFP",
    "content": "4 2 e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855",
    "ttl": 3600
  }'

Add multiple key types:

# Ed25519 key
curl -X POST "https://api.dnscale.eu/v1/zones/{zone_id}/records" \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "server",
    "type": "SSHFP",
    "content": "4 2 e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855",
    "ttl": 3600
  }'
 
# ECDSA key
curl -X POST "https://api.dnscale.eu/v1/zones/{zone_id}/records" \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "server",
    "type": "SSHFP",
    "content": "3 2 abc123def456789...",
    "ttl": 3600
  }'

API Response:

{
  "status": "success",
  "data": {
    "message": "Record created successfully",
    "record": {
      "id": "encoded-record-id",
      "name": "server.example.com.",
      "type": "SSHFP",
      "content": "4 2 e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855",
      "ttl": 3600,
      "disabled": false
    }
  }
}

Configuring SSH Client

To enable SSHFP verification, configure your SSH client:

~/.ssh/config

Host *.example.com
    VerifyHostKeyDNS yes

Command Line

ssh -o VerifyHostKeyDNS=yes server.example.com

Verification Levels

When set to yes and DNSSEC is validated, SSH will automatically accept the host key if it matches the SSHFP record. When DNSSEC is not present, SSH will note the match but still prompt the user because the DNS response cannot be trusted.

SSHFP Compared to TLSA

SSHFP and TLSA records serve a similar purpose: publishing cryptographic identity information in DNS. TLSA does this for TLS certificates (used by HTTPS, SMTP, and other TLS-protected services), while SSHFP does it for SSH host keys. Both rely on DNSSEC for security and both are part of the broader DANE (DNS-based Authentication of Named Entities) framework.

Best Practices

1. Use SHA-256 -- Always use fingerprint type 2 (SHA-256), not SHA-1

2. Publish all key types -- Add SSHFP records for all host keys your server offers (RSA, ECDSA, Ed25519)

3. Enable DNSSEC -- Without DNSSEC, SSHFP provides limited security benefit

4. Update on key rotation -- When you regenerate host keys, update SSHFP records immediately

5. Use Ed25519 keys -- Modern, secure, and produces shorter fingerprints

6. Automate record generation -- Include SSHFP record creation in server provisioning scripts. Tools like Ansible, Terraform (DNScale Terraform provider), or DNSControl can automate this

7. Set appropriate TTLs -- Use moderate TTL values (3600-86400). Too short creates unnecessary DNS traffic; too long delays key rotation

Host Key Rotation

When rotating SSH host keys:

1. Generate new keys on the server
2. Add new SSHFP records (keep old ones temporarily)
3. Wait for DNS propagation (at least the TTL duration)
4. Replace keys on the server
5. Remove old SSHFP records

# Step 1: Generate new keys
ssh-keygen -t ed25519 -f /etc/ssh/ssh_host_ed25519_key_new -N ""
 
# Step 2-3: Add new SSHFP and wait
 
# Step 4: Replace keys
mv /etc/ssh/ssh_host_ed25519_key_new /etc/ssh/ssh_host_ed25519_key
systemctl reload sshd
 
# Step 5: Remove old SSHFP records

During the overlap period (steps 2-4), both old and new SSHFP records should exist in DNS. This ensures that clients can verify the connection regardless of whether they reach the server before or after the key swap.

Testing SSHFP Records

# Query SSHFP records
dig SSHFP server.example.com
 
# Verify SSH connection with SSHFP
ssh -v -o VerifyHostKeyDNS=yes server.example.com
 
# Compare local fingerprint with DNS
ssh-keygen -r server.example.com
 
# Check DNSSEC validation
dig +dnssec SSHFP server.example.com @ns1.dnscale.eu

Related Record Types

• TLSA -- TLS certificate fingerprints (similar concept for HTTPS/SMTP)
• A -- Server IPv4 address
• AAAA -- Server IPv6 address
• CAA -- Certificate authority authorization
• TXT -- General-purpose text records
• DNS Record Types -- Overview of all DNS record types

Conclusion

SSHFP records provide a DNS-based method for SSH host key verification, reducing reliance on the "trust on first use" model. When combined with DNSSEC, SSHFP offers strong cryptographic proof of server identity. DNScale makes it easy to publish SSHFP records for your servers, with dedicated fields for algorithm and fingerprint type selection.