Oli Schacher
2022-Mar-11 12:55 UTC
multiple SSHFP records for the same hostname and key type
Dear list I have two servers with different host keys which provide a ssh service under a shared host name, in an active-passive setup. When connecting to ssh-service.einbeispiel.ch you reach either server A or B. This service name has two SSHFP records: ssh-service.einbeispiel.ch SSHFP 4 2 <ED25519 hostkey from server A> ssh-service.einbeispiel.ch SSHFP 4 2 <ED25518 hostkey from server B> This has worked previously, but openssh has changed its implementation in 8.7., so that apparently *ALL* SSHFP records must match or the Host key will not be accepted. [1] # example with OpenSSH_8.4p1 Debian-5, OpenSSL 1.1.1k 25 Mar 2021 ssh -v -o HostKeyAlgorithms=ssh-ed25519 -o VerifyHostKeyDNS=yes ssh-service.einbeispiel.ch [...] debug1: found 2 secure fingerprints in DNS debug1: matching host key fingerprint found in DNS # example with OpenSSH_8.9p1, OpenSSL 1.1.1m 14 Dec 2021 ssh -v -o HostKeyAlgorithms=ssh-ed25519 -o VerifyHostKeyDNS=yes ssh-service.einbeispiel.ch [...] debug1: verify_host_key_dns: failed SSHFP type 4 fptype 2 debug1: verify_host_key_dns: matched SSHFP type 4 fptype 2 debug1: mismatching host key fingerprint found in DNS [...] No matching host key fingerprint found in DNS. It seems to me that this change breaks two use cases: a) the one described above , i.e. using SSHFP records for a common service name provided by multiple backends with different host keys b) the possibility to seamlessly replace a host key without breaking SSHFP validation, as this would require the SSHFP record to be changed *exactly* at the same time as the host keys. But due to DNS TTLs / replication delay this is not possible and there will always be a time frame where these records are out of sync. With the earlier behavior I could just add the new SSHFP record in the DNS and have both old and new keys active, then replace the host key on the server, then remove the old key from DNS SSHFP. rfc4255[2] says "If the algorithm and fingerprint of the key received from the SSH server match the algorithm and fingerprint of *one of* the SSHFP resource record(s) returned from DNS, the client MAY accept the identity of the server." note the "one of" So I'm wondering if the change in 8.7 from "one of" to "all" did consider these two cases at all. Should I change my use cases or is this a breakage in openssh that could be considered to be reverted? Thanks for your help and best regards Oli [1] https://www.openssh.com/txt/release-8.7 [2] https://datatracker.ietf.org/doc/html/rfc4255#section-2.1