Bug 688988

Summary: FR: Add local DNSSEC validation to OpenSSH
Product: [Fedora] Fedora Reporter: Kenny Root <kenny>
Component: opensshAssignee: Jakub Jelen <jjelen>
Status: NEW --- QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: rawhideCC: cra, mattias.ellert, mgrepl, pwouters, rs, rvokal, tmraz, wjhns174
Target Milestone: ---Keywords: FutureFeature
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:

Description Kenny Root 2011-03-18 14:10:04 EDT
This is a feature request (FR) for OpenSSH

There is no security between the resolver and the host running an SSH client, so add local DNSSEC validation to requests. Currently it just appears to check the AD bit is set and trusts that, but the response could have been altered via MITM attack.

Luckily someone has already done all the hard work and provided patches:
https://www.dnssec-tools.org/svn/dnssec-tools/trunk/htdocs/readme/README.ssh
Comment 1 Jan F. Chadima 2011-03-18 15:47:09 EDT
was these patches sent to upstream?
what upstream said to them?
is there upstream bz# or mail thread about it?
Comment 2 Jan F. Chadima 2011-04-18 08:47:29 EDT
ping
can you respond please?
Comment 3 Kenny Root 2011-04-19 05:55:39 EDT
Sorry, I was waiting for the author to respond to an email. I've attached the upstream bugzilla URL to this ticket.
Comment 4 Jan F. Chadima 2011-04-20 04:57:48 EDT
I suggest to wait while upstream does not respond to their bugzilla.
Comment 5 Fedora Admin XMLRPC Client 2011-11-30 07:25:19 EST
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.
Comment 6 Paul Wouters 2012-07-18 16:24:21 EDT
note that fedora is moving to having a dnssec validating resolver on localhost, so ssh whould not need to do anything specific
Comment 7 Paul Wouters 2012-11-28 09:24:57 EST
I would not add these patches but instead trust the localhost resolver. Especially since we reconfigure the local resolver using dnssec-trigger/unbound (to move migrated into networkmanager). If you patch ssh, then it will not know about any locally configured trust anchors anyway, and it will not do any workarounds for getting a working dnssec capable upstream resolver, something that the current dnssec-trigger+unbound does do for us.
Comment 8 Wes Hardaker 2012-11-28 13:56:32 EST
Paul: I disagree with your notion that SSH doesn't need in-application validation.  Yes, it's great that the local resolver SHOULD have DNSSEC support, but the reality is that an application can't trust that and has no signaling mechanism available to be sure that the response actually came from the local resolver.  It may be that future versions of Fedora will come with a default local validating resolver, but in order for a security critical application (such as SSH querying for remote fingerprints) you can't trust that an administrator hasn't changed the packaging or DNS setup.  And there is no way to tell, so IMHO: it's critical that doing in-application validation is better in general and critical for cases where you're making security decisions based on the results of a DNS lookup.
Comment 9 Paul Wouters 2012-12-02 13:33:21 EST
Does ssh trust the AD bit even when the resolver is not localhost? I thought there was a check for that to prevent this exact scenario? If so, then protecting against a modified local dns server seems silly, as the attacker an then also just modify the local ssh client.

But I know some of the ssh behaviour also depending on GLIBC settings, so I am not entirely sure what the current ssh client allows for giving it an AD bit it trusts. I thought it would treat "yes" as "ask" for VerifyHostKeyDNS if the resolver was not localhost, but I'd have to double check that with the current code.

But I guess you're right in that it does not hurt in this case, if the only difference is ssh treating a response more insecure then it really is and giving the user the additional text in the prompt before accepting.
Comment 10 Fedora Admin XMLRPC Client 2016-01-08 08:43:05 EST
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.