Summary

  • A DNSSEC-authenticated SSHFP match can bind one presented SSH host-key algorithm and fingerprint to one selected DNS owner name. It does not prove that name was the user's intended service or encode a port, user or command.
  • The decision remains a composition of name selection, DNSSEC validation state, exact algorithm and digest comparison, SSH possession proof and local client policy. Host-key rotation adds a second clock across DNS caches.

A correct answer to the wrong name

The opening connection contains no forged signature and no broken digest. The resolver selected a fully qualified name. A validating path authenticated its SSHFP RRset. The SSH server proved possession of the private key corresponding to the public key whose fingerprint appeared there.

The missing predicate is earlier: why was that owner name the right expansion of db?

RFC 4255 anticipates this failure. When clients use unqualified names, it recommends checking a local host-key database before SSHFP because an attacker can inject a resolver search path and direct the client to another host. A different defense is a trusted search path, but ordinary lookup interfaces do not necessarily reveal where that path came from.

DNSSEC can make an answer authentic without making the question wise. The trace must preserve the original command-line label, the effective canonical name, any CNAME decision, the queried SSHFP owner and the final address. Collapsing them into “host” erases the point at which intent was replaced.

Three values, one narrow association

SSHFP is DNS resource-record type 44. Its RDATA contains a public-key algorithm number, a fingerprint type and the fingerprint. The owner name sits in the DNS record outside that RDATA.

Verification requires both dimensions to agree. The algorithm of the public key received from the SSH server must match the SSHFP algorithm number. The digest of the public-key blob, computed with the registered fingerprint algorithm, must match the fingerprint bytes in the record.

That comparison does not replace SSH key exchange. The transport protocol still requires the server to sign exchange material with the host key, demonstrating control of the corresponding private key for that session. Nor does possession prove exclusivity. A copied or stolen private key can produce the same valid proof.

The record format also names its omissions. It carries no TCP port, username, command, IP address, organizational role or validity interval. A matching record for host.example cannot by itself answer whether the operator meant port 22, a second SSH daemon on another port, a jump host, a production role or an administrative account.

Secure is a validation state, not a mood

RFC 4255 says a key verified by SSHFP must not be trusted when the record used for verification was not authenticated by a trusted DNS signature. A client that validates locally follows DNSSEC validation procedures. A client that outsources validation needs a protected channel to the validator; accepting an asserted result bit across an untrusted path merely moves the attack.

Operations need the actual DNSSEC state. Secure means the relevant data validated through an accepted trust anchor. Insecure means the chain establishes that the data is not secured. Bogus means validation was expected but failed. Indeterminate means available trust information cannot support a determination.

Those states are not interchangeable versions of “DNS returned something.” A byte-for-byte SSHFP match under Insecure has informational value but does not earn automatic trust under RFC 4255. Bogus should not be silently downgraded to Insecure. Indeterminate should expose the missing trust context.

Even Secure remains bounded. DNSSEC authenticates the RRset under its owner name and chain. It does not prove that a DHCP-derived suffix, canonicalization rule or manually typed alias expressed the user's intended destination.

Algorithm agility needs a negative rule

The current IANA SSHFP registry assigns public-key algorithm numbers for RSA, DSA, ECDSA, Ed25519 and Ed448. It assigns fingerprint type 1 to SHA-1 and type 2 to SHA-256. Registration states how a record is represented; it does not prove that a particular client implements or enables that combination.

RFC 6594 supplies an important downgrade test. An SSHFP-aware implementation that supports SHA-256 must prefer it when SHA-1 and SHA-256 records coexist. If the SHA-256 fingerprint is tested and mismatches the received key, the client must reject the key rather than try to rescue it with a matching SHA-1 record.

That rule preserves the subject of the failure. A stronger record that disagrees is not an invitation to search for any weaker fact that says yes. Telemetry therefore needs every tested tuple—owner, key algorithm, fingerprint type, computed digest and result—not a single sshfp=match flag.

Local policy still owns the final branch

RFC 4255 deliberately allows clients to order SSHFP, local files and future verification methods through configurable policy. Current OpenSSH documentation makes that choice visible. VerifyHostKeyDNS defaults to no. With yes, OpenSSH implicitly trusts a key matching a secure DNS fingerprint; insecure fingerprints are treated like ask. With ask, match information is displayed, while acceptance of a new key still follows StrictHostKeyChecking.

The same client also has user and global known-host databases, hostname canonicalization, permitted CNAME rules and host-key update behavior. Enabling SSHFP changes part of that decision graph. It does not erase conflicting pins or prove which branch ran.

A useful incident record must therefore include the resolved configuration, not just the configuration file an operator expected to match. Command-line options, user config, system config, Host and Match clauses, canonicalization and first-value precedence can produce a different effective policy.

Port and path are outside the RR

OpenSSH's known-host maintenance can distinguish [hostname]:port. Its SSHFP generation command emits a record named by hostname. This is executable evidence of a structural difference: a local pin database can carry a port-qualified identity, while SSHFP RDATA cannot.

The absence does not make SSHFP defective. It defines the unit it authenticates. If one DNS name serves different SSH host keys on different ports, application policy must decide whether that arrangement is valid and how each service is pinned. Pretending that the DNS match selected the port grants the record authority it does not contain.

A jump route adds more names and keys. Authentication of the final destination does not authenticate a separately operated bastion merely because traffic traverses it. Each material SSH transport leg needs its own host-key evidence and policy result.

Rotation is a two-clock operation

RFC 4255 notes that replacing SSHFP can distribute a new host key and, where policy requires SSHFP, removing a record can participate in revocation. Both statements depend on running client policy.

DNS adds time. Old RRsets remain in recursive caches until their TTLs expire, and their RRSIG validity has its own interval. SSH clients may also retain local known-host pins. Changing the daemon's host key before the new fingerprint is visible creates avoidable rejection. Removing the old fingerprint at the authoritative server does not prove that every resolver stopped returning it.

A safe rotation publishes the new fingerprint through the authenticated enrollment path, observes it through material validating resolvers, overlaps old and new keys for a bounded period, changes service presentation, then removes the old record and proves refusal after relevant caches expire. Emergency compromise may require faster refusal and accepted unavailability; that is a named risk decision, not a reason to label caches current.

Server identity is not user authority

SSH architecture separates server authentication in the transport layer from user authentication. An accepted host key can protect the channel to the selected server. It does not authenticate the person or workload connecting, accept a user public key, grant a shell, permit port forwarding or authorize a command.

This is the final promotion error. Automation often treats “SSH host verified” as permission to deploy, rotate secrets or run privileged maintenance. Those actions need their own account identity, authorization policy, change scope and transaction record. A correct SSHFP decision can precede a denied login or forbidden command without contradiction.

Negative tests that keep every noun

Resolve the same short label under two search paths and require different owner names to remain visible. Test an exact fingerprint match under Secure, Insecure, Bogus and Indeterminate states. Publish SHA-1 and SHA-256 fingerprints, make only the stronger record mismatch and require rejection.

Rotate keys across pre-publication, overlap, authoritative deletion and cache expiry. Connect to two ports with different host keys. Create a conflict between a local pin and a new Secure SSHFP match. Pass through a jump host. Copy the private host key to a second endpoint. Authenticate the server, then separately fail the user and the requested command.

The purpose is not universal rejection. It is to ensure every pass states which name, RRset, trust anchor, key, port, transport leg, client policy and later permission actually earned it.