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
Details
Details
Diff Detail
Diff Detail
- Repository
- rG FreeBSD src repository
- Lint
Lint Not Applicable - Unit
Tests Not Applicable
Event Timeline
Comment Actions
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 ?
Comment Actions
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.