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
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
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
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev