The SSHFP record contains fingerprints for public keys, used for Secure Shell (SSH). The SSHFP record is usually used with DNSSEC enabled domains. When a SSH client connects to a server it checks the corresponding SSHFP record. If the records fingerprint matches the servers, the server is legit and it is not a problem and it is safe to connect to it.
Each SSHFP record contains three important components:
Together, these three components form an SSHFP record that can be queried by an SSH client when attempting to establish a connection.
When an SSH client connects to a server, it can query the DNS for SSHFP records. If it finds one, and DNSSEC validation is enabled, it can compare the SSH key provided by the server to the fingerprint in the DNS. If these match, it's a good indicator that the client is connecting to the intended server.
SSHFP records are just the beginning; understanding how to manage and configure these records for specific environments is key for advanced users. For instance, SSH clients can be configured to verify SSHFP records by adding VerifyHostKeyDNS yes to the SSH configuration. Also, managing SSHFP records in larger, more complex environments might require automation or use of DNS management tools to handle multiple records efficiently.
An SSHFP (SSH Fingerprint) record enhances the security and efficiency of SSH connections. By using DNSSEC, SSHFP records ensure the authenticity and integrity of DNS responses, protecting against man-in-the-middle attacks by verifying the server’s public key.
SSHFP records simplify SSH key management by centralizing SSH key fingerprints in DNS, reducing the need for known_hosts files and automating the verification process during SSH connections. This reduces the risk of human error and key spoofing by securely matching the server's public key fingerprint.
Additionally, SSHFP records streamline key updates, making it easy to add or remove keys, which supports efficient key management, especially in dynamic environments. This method also provides a transparent and auditable process for managing SSH keys, aiding in compliance with security standards and regulations.
Let's walk through a practical example. Say you have a remote server, server.example.com, with an RSA public key. Using ssh-keygen, you generate an SSHFP record and add it to your domain. Now, when an SSH client tries to connect to server.example.com, it will verify the server's identity using the SSHFP record, making sure that it is connecting to the legitimate server.
Question: Can SSHFP records coexist with SSH keys stored in known_hosts files?
Answer: Yes, SSHFP records can coexist with SSH keys stored in the known_hosts files on client systems. When a client connects to an SSH server, it will check both the SSHFP record in DNS (if available) and the known_hosts file to validate the server's fingerprint. If the fingerprint matches in either source, the connection proceeds; otherwise, the client may issue a warning or deny the connection.
Question: I've created an SSHFP record, but my SSH client doesn't seem to be verifying it. What could be the issue?
Answer: One common reason for this could be that your SSH client is not configured to check for SSHFP records. By default, most SSH clients do not verify SSHFP records. To enable this, you need to add VerifyHostKeyDNS yes to your SSH client configuration. Keep in mind that for SSHFP verification to work, DNSSEC must be enabled and correctly set up for your domain.
Question: What should I do if the fingerprint in the SSHFP record doesn't match the server's public key?
Answer: If the fingerprint in your SSHFP record doesn't match the server's public key, there are a few potential causes. It could be that the SSHFP record is outdated, incorrectly added, or the server's public key might have changed. In any case, you would need to generate a new fingerprint from the server's current public key using ssh-keygen -r hostname, and then update the SSHFP record in your DNS settings with the new fingerprint.