Page MenuHomeFreeBSD

ssh: default VerifyHostKeyDNS to no, following upstream
ClosedPublic

Authored by emaste on Feb 17 2023, 1:35 AM.
Tags
None
Referenced Files
Unknown Object (File)
Mon, Oct 21, 2:07 AM
Unknown Object (File)
Mon, Oct 21, 2:02 AM
Unknown Object (File)
Mon, Oct 21, 2:02 AM
Unknown Object (File)
Sun, Oct 20, 11:18 PM
Unknown Object (File)
Fri, Oct 18, 8:14 PM
Unknown Object (File)
Tue, Oct 8, 6:15 AM
Unknown Object (File)
Sep 26 2024, 1:32 PM
Unknown Object (File)
Sep 24 2024, 9:06 AM
Subscribers

Details

Summary
Revert to upstream's default.  Using VerifyHostKeyDNS may depend on a
trusted nameserver and network path.

This reverts commit 83c6a5242c80160fff76fb85454938761645b0c4.

Reported by:    David Leadbeater, G-Research
Relnotes:       Yes
Sponsored by:   The FreeBSD Foundation

Diff Detail

Repository
rG FreeBSD src repository
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

emaste created this revision.
3. If an SSHFP record was found:
     1. If it matches the server’s key:
         1. If it has a valid DNSSEC signature and VerifyHostKeyDNS is “yes”, continue connecting
         2. Otherwise, set a flag to indicate that a matching SSHFP record was found
     2. Otherwise, warn about the mismatch

I've not looked into OpenSSH's source code, but the logic seems not right.

IMO a SSHFP record should be used only when its DNSSEC signature is validated and valid, otherwise the record is not trusted and should be not be used and ignored.
So the step 3 should be If an SSHFP record was found and has a valid DNSSEC signature.

A landscape:

3. If an SSHFP record was found and has a valid DNSSEC signature:
     1. If it matches the server’s key:
         1. If VerifyHostKeyDNS is “yes”, continue connecting
         2. Otherwise, set a flag to indicate that a matching SSHFP record was found
     2. Otherwise, warn about the mismatch

Back to this topic, any chance that the logic could not be fixed ? Or this is only a temporary fix ?

gordon added a subscriber: gordon.

Looks good to me.

This revision is now accepted and ready to land.Feb 27 2023, 3:14 PM

Back to this topic, any chance that the logic could not be fixed ?

Yes, we should fix OpenSSH's host key handling, and also improve the resolver.