Description of problem: I tried to check whether SSHFP work on Fedora infrastructure. First I tried fedorapeople.org, then pkgs.fedoraproject.org. I always asked for fingerprint confirmation, even I had "VerifyHostKeyDNS yes" in client configuration. According to manual, yes should accept dnssec signed sshfp. Which fedora packages has and my system is able to validate. Just then I were told it works on Ubuntu, where ldns support is built-in. I think it should print some message to the user, when ldns support is not compiled in. Something like: DNSSEC support not built-in, VerifyHostKeyDNS ask is used instead. Version-Release number of selected component (if applicable): openssh-8.3p1-3.fc32.x86_64 How reproducible: reliable Steps to Reproduce: 1. pkgs.fedoraproject.org missing in ~/.ssh/known_hosts 2. ssh -o "VerifyHostKeyDNS yes" pkgs.fedoraproject.org 3. Actual results: ssh -o "VerifyHostKeyDNS yes" pkgs.fedoraproject.org load pubkey "/root/.ssh/id_rsa": invalid format The authenticity of host 'pkgs.fedoraproject.org (38.145.60.17)' can't be established. RSA key fingerprint is SHA256:Q12OTyTeOHWlS54dTzy2BNu7wB8UKNf18+7WHIDsORc. Matching host key fingerprint found in DNS. Are you sure you want to continue connecting (yes/no/[fingerprint])? Expected results: ssh -o "VerifyHostKeyDNS yes" pkgs.fedoraproject.org load pubkey "/root/.ssh/id_rsa": invalid format The authenticity of host 'pkgs.fedoraproject.org (38.145.60.17)' can't be established. RSA key fingerprint is SHA256:Q12OTyTeOHWlS54dTzy2BNu7wB8UKNf18+7WHIDsORc. Matching host key fingerprint found in DNS, unable to validate. DNSSEC support not built-in, VerifyHostKeyDNS ask is used instead. Are you sure you want to continue connecting (yes/no/[fingerprint])? Additional info: I have prepared also pull request with ldns support enabled [1]. Once that is built, it no longer asks for fingerprint. 1. https://src.fedoraproject.org/rpms/openssh/pull-request/12
I have even filled instrastructure ticket[1] first, because I thought these records were invalid. 1. https://pagure.io/fedora-infrastructure/issue/9380
Thank you for the bug report and pull request. I am no DNS expert so please bear in mind my understanding might not be right. We had a recently a bug #1878166, which I believe is an issue of configuration as openssh requires ends0 enabled in /etc/resolv.conf (which is not default in fedora) to work with the FPs from DNS (unless the ldns is linked in). Please, share also debug log of your connection, which might provide more details. On a side note, we have a test that worked fine with Fedora 32 and fails with Fedora 33 for some reason, but looks like related to local dns resolver rather than openssh (can share more information offline). Checking the last builds for Fedora 32 and 33 does not list any differences in dependencies (that we would drop ldns unintentionally). Can you submit the (configure) patch upstream, as it looks like you understand the problem better than me.
Created attachment 1721044 [details] Report warning patch
Made patch warning in build without ldns, when edns0 is missing from options and VerifyHostKeyDNS yes is configured. If ask is configured, no new message is shown. Should help those running local validating resolver.
(In reply to Jakub Jelen from comment #2) > On a side note, we have a test that worked fine with Fedora 32 and fails > with Fedora 33 for some reason, but looks like related to local dns resolver > rather than openssh (can share more information offline). Checking the last > builds for Fedora 32 and 33 does not list any differences in dependencies > (that we would drop ldns unintentionally). Reason for the failure in f33 would be two things. First, it has missing edns0 in resolv.conf it manages. Second, it turned off dnssec by default to work around some problems. Try: resolvectl dnssec eth0 yes Replace eth0 to whatever is actually used. Or use at least DNSSEC=allow-downgrade in /etc/systemd/resolved.conf and restart systemd-resolved. And fill a bug. :) > > Can you submit the (configure) patch upstream, as it looks like you > understand the problem better than me. Done
There are various bugs with systemd-resolved on fedora 33 with respect to DNSSEC - specifically getting/setting the DO/AD bits. Since sshfp records need the AD bit for the client to want to trust them, this causes problems. But also worse, systemd-resolved might set the AD bit on SSHFP records it has NOT validate.
This bug appears to have been reported against 'rawhide' during the Fedora 34 development cycle. Changing version to 34.
Is this issue still relevant?
No response since November. Closing.