This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours

Bug 180277

Summary: enable VerifyHostKeyDNS in /etc/ssh/ssh_client
Product: [Fedora] Fedora Reporter: Paul Wouters <paul>
Component: opensshAssignee: Tomas Mraz <tmraz>
Status: CLOSED UPSTREAM QA Contact: Brian Brock <bbrock>
Severity: medium Docs Contact:
Priority: medium    
Version: rawhideCC: cweyl, david, mitr, steve
Target Milestone: ---Keywords: FutureFeature, Reopened
Target Release: ---   
Hardware: All   
OS: Linux   
See Also: https://bugzilla.redhat.com/show_bug.cgi?id=730558
Whiteboard:
Fixed In Version: Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2007-09-24 15:19:22 EDT Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:

Description Paul Wouters 2006-02-06 16:17:51 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.12) Gecko/20050922 Fedora/1.0.7-1.1.fc4 Firefox/1.0.7

Description of problem:
Openssh-4 has a new feature that allows verifying ssh fingerprints from DNS(SEC).
This function can be enabled by setting VerifyHostKeyDNS to yes in the client configuration (/etc/ssh/ssh_client).

this will produce:

$ host -t sshfp tla.openswan.org
tla.openswan.org has SSHFP record 1 1 023B462A48078FEDE5328D9BD9E7F1896CEF75A7
tla.openswan.org has SSHFP record 2 1 176851637907BFFD41D7E161A06D8F2EE14EF35D
$ ssh tla.openswan.org
The authenticity of host 'tla.openswan.org (193.110.157.130)' can't be established.
RSA key fingerprint is 3d:d1:34:ac:f6:ac:8f:eb:ca:1e:e7:02:8c:10:26:53.
Matching host key fingerprint found in DNS.
Are you sure you want to continue connecting (yes/no)? yes


Version-Release number of selected component (if applicable):
openssh-4.2p1-fc4.1

How reproducible:
Always

Steps to Reproduce:
It is a feature request. It should not impact any situation, since if the key is also in the known_hosts file, the DNS lookup is not used.
  

Additional info:
Comment 1 Tomas Mraz 2006-02-06 17:25:19 EST
This is definitely not something I'd like to enable by default.

Sorry.
Comment 2 Paul Wouters 2006-02-06 19:07:49 EST
Can you please explain why. As I explained:

This option does NOT blindly accept fingerprints from DNS. It only gives you
an EXTRA line of information about the fingerprint, that is whether or not it
exists in DNS and whether it matches. Thus if a MITM attack is happening and you
are connecting to a new site, the results will be MORE warnings about the attack.
I assume that soon it will also provide DNSSEC hooks for extra verification, now
that DNSSEC has been adopted as RFC, and the first two toplevel domains (.se and
the RIPE reverse zone) have been secured by DNSSEC and are fully in production now.

I have no idea what the possible negative impact could be for disabling this.
Could you describe a scenario where enabling this feature would lessen the
security of the ssh client?
Comment 3 Tomas Mraz 2006-02-07 03:09:07 EST
It at least means that there is one more dns lookup done.
And I'd like to keep as close as possible to upstream defaults.

You can change your configuration yourself. There is no need to force that on
everyone.
Comment 4 Paul Wouters 2006-02-07 14:54:44 EST
Okay. if extra security is not worth a DNS lookup, then I guess I have no more
arguments left to argue why to enable it. 

No wonder endusers don't use strong security and encryption tools. We don't make
it easy and transparent for them though :(

Guess you can close off this bug and I'll wait for openssh to change their default.
Comment 5 Tomas Mraz 2006-02-07 15:07:25 EST
You don't even have to only wait. You can open a bug report in
http://bugzilla.mindrot.org/ - openssh upstream bugzilla.
Comment 6 Steven Pritchard 2007-03-26 17:13:13 EDT
Obviously getting upstream to turn this on by default is the Right Answer, but 
since it has been over a year and that hasn't happened, perhaps we should 
reconsider enabling it in our default config?
Comment 7 Miloslav Trmač 2007-03-28 05:01:34 EDT
> This option does NOT blindly accept fingerprints from DNS.
This is true only if VerifyHostKeyDNS is "ask".  If it is "yes", as you
requested, and DNSSEC is used, the DNS admin can capture user's passwords when
logging in to a host for the first time.

In general, the "Matching host key fingerprint found in DNS." message may
provide false sense of security because the host administrator and DNS
administrator are often not the same person - especially if DNS is spoofed.

> Obviously getting upstream to turn this on by default is the Right Answer, but 
> since it has been over a year and that hasn't happened
Was it ever requested upstream?  I can't find anything on bugzilla.mindrot.org.
Comment 8 Paul Wouters 2007-03-29 01:59:25 EDT
> This is true only if VerifyHostKeyDNS is "ask".  If it is "yes", as you
> requested, and DNSSEC is used, the DNS admin can capture user's passwords when
> logging in to a host for the first time.

That is incorrect. Please test this yourself with a host like
'tla.openswan.org'. If you login to a host for the first time, you are presented
with the prompt as above: 

[paul@bofh ~]$ grep Verify /etc/ssh/ssh_config
VerifyHostKeyDNS        yes
[paul@bofh ~]$ grep Verify ~/.ssh/config 
[paul@bofh ~]$ ssh tla.openswan.org
The authenticity of host 'tla.openswan.org (193.110.157.130)' can't be established.
RSA key fingerprint is 3d:d1:34:ac:f6:ac:8f:eb:ca:1e:e7:02:8c:10:26:53.
Matching host key fingerprint found in DNS.
Are you sure you want to continue connecting (yes/no)? yes

If you have connected to this host in the past, and the DNS admin is redirecting
the host, then you will get a warning that the host key changed from your copy
in .ssh/known_hosts.

If you have connected to this host in the past, and its a hacker that is
redirecting you, you will get awrning that the jost key changed from your copy
in .ssh/known_hosts AND that the dns key is wrong.

If you have never connected to this host in the past, you are ALWAYS prompted,
so you are no worse of then without DNS records if you choose to be.
Comment 9 Tomas Mraz 2007-03-29 03:05:42 EDT
Paul, do you have DNSSEC setup correctly? Otherwise it always asks.

Comment 10 Miloslav Trmač 2007-03-29 17:53:59 EDT
AFAICS the glibc resolver doesn't support DNSSEC at all - see e.g.
http://sources.redhat.com/ml/libc-alpha/2006-09/msg00006.html .
Comment 11 Paul Wouters 2007-03-29 19:39:29 EDT
the ssh client is not aware of DNSSEC, so whether the resolver used is DNSSEC
aware is irrelevant for the "problem" of prompting for new host connects, which
as described above, is not a problem at all.

With a secure resolver, applications can be protected against receiving spoofed
names, even if not in a nice way. IETF is working on an API for this. Until
then, applications might need to do some things themselves. This can be via
BIND's lwres interface, or via libraries like libldns (ldns is a fedora package)
or via plugins, such as the firefox ldns plugin.

But all this discussion is really out of scope for this bug. The discussion here
is "should or should we not enable VerifyHostKeyDNS". The only two arguments
I've heard against it are:

1) the incorrect assumption that it would allow malicious DNS admins to steal
passwords.

2) if upstream isnt doing it, we shouldn't either.

3) it takes an extra DNS packet to connect to a server


1) is wrong, and I find the reasoning of 2) rather weak. If upstream didn't
believe in such a feature, it would not have the feature to begin with. 3) isn't
adding that much overhead to a crypto protocol in times of delay.

I thought Fedora was about using the community for testing and then creating
stable RHEL's. I'd say this is a good example of a feature that's been out there
for over a year, is starting to see good use, will get even better with DNSSEC,
and Fedora is ideal for testing this so that when markets actually move in on
DNSSEC later in the year, RHEL people know if this feature is desirable or not.

Again. there is see no harm, only potential benefits.
Comment 12 Tomas Mraz 2007-03-30 02:52:29 EDT
(In reply to comment #10)
> AFAICS the glibc resolver doesn't support DNSSEC at all - see e.g.
> http://sources.redhat.com/ml/libc-alpha/2006-09/msg00006.html .

I didn't know that. But that may change in future. So I think that putting 'ask'
there is more appropriate so the behaviour doesn't change silently with a glibc
upgrade. Thus it will be giving just a hint to the user - which he can accept
but doesn't have to. I think we can reconsider this bug for Fedora 8 giving
Fedora 7 is in feature freeze so we shouldn't be making feature changes.

BTW 1) is wrong only because DNSSEC is not supported in glibc. Otherwise it
would be very true.
Comment 13 Paul Wouters 2007-09-25 13:29:52 EDT
You are saying 1) would be WORSE with DNSSEC support?

First of all, DNSSEC does not have to be present in glibc. Running a caching
only bind 9.3 nameserver on localhost with resolv.conf pointing to it will do
fine to obtain secure dnssec protected answers without low level glibc dnssec
support.

Second, I have no idea how ADDING dnssec support will cause malicious DNS admins
to steal passwords. As I have stated numerous times now, the ssh client will
ALWAYS prompt when connecting to a brand new ssh public key to any dns name,
whether or not there are sshfp records, with:

The authenticity of host XXX can't be established.

The only additional text displayed will be:

Matching host key fingerprint found in DNS.

Or a big warning if the fingerprint does NOT match.

Please describe the attack you are seeing, so I can try to reproduce it, and
file a bug against openssh-client if I can reproduce it.
Comment 14 Tomas Mraz 2007-09-25 14:18:05 EDT
(In reply to comment #13)
> You are saying 1) would be WORSE with DNSSEC support?
> 
> First of all, DNSSEC does not have to be present in glibc. Running a caching
> only bind 9.3 nameserver on localhost with resolv.conf pointing to it will do
> fine to obtain secure dnssec protected answers without low level glibc dnssec
> support.
> 
> Second, I have no idea how ADDING dnssec support will cause malicious DNS admins
> to steal passwords. As I have stated numerous times now, the ssh client will
> ALWAYS prompt when connecting to a brand new ssh public key to any dns name,
> whether or not there are sshfp records, with:
> 
> The authenticity of host XXX can't be established.
> 
> The only additional text displayed will be:
> 
> Matching host key fingerprint found in DNS.
> 
> Or a big warning if the fingerprint does NOT match.
> 
> Please describe the attack you are seeing, so I can try to reproduce it, and
> file a bug against openssh-client if I can reproduce it.

If VerifyHostKeyDNS is yes and the glibc would support DNSSEC - that is set
proper flags on the DNSSEC validated replies - the openssh would not ask if the
reply was validated properly. Look at the source.

How DNS admin could steal passwords? With DNSSEC at least for domains for which
his DNS server is the authoritative server very easily. And when DNSSEC is not
used - if the user doesn't verify the ssh key fingerprint manually anyway also
very easily.

That's my final word on it. The configuration file is there - you can easily
enable this for you and it won't be overwritten on upgrades.