Bug 730558 - Set set VerifyHostKeyDNS to 'yes'
Summary: Set set VerifyHostKeyDNS to 'yes'
Alias: None
Product: Fedora
Classification: Fedora
Component: openssh
Version: 15
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
Assignee: Jan F. Chadima
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2011-08-14 13:31 UTC by wildfire
Modified: 2013-12-16 16:44 UTC (History)
6 users (show)

Fixed In Version: openssh-5.9p1-11.fc17
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2011-10-18 09:53:51 UTC

Attachments (Terms of Use)

System ID Priority Status Summary Last Updated
Red Hat Bugzilla 180277 None None None Never

Internal Links: 180277

Description wildfire 2011-08-14 13:31:16 UTC
Description of problem:

openssh has the ability to check the DNS for a record (SSHFP) containing the key of the host you intend to connect to. Currently this feature is turned off.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. install SSHFP records into DNS
2. ssh <host>
3. you are prompted to accept the key
Actual results:

Expected results:

If the DNS connection is secured via DNSSEC, you should not be prompted if the host key and the key specified in the DNS match.

If the connection it NOT secure, you will be prompted (but also informed that the DNS records DO match).

If there are no DNS records, that will be noted in the output and connection can proceed as normal.

Additional info

Please set the 'VerifyHostKeyDNS yes' in /etc/ssh/ssh_config

Comment 1 Tomas Mraz 2011-08-15 10:16:46 UTC
I propose to change this to 'ask' only. This will improve the security and will not make the ssh security fully dependent on DNSSEC.

Comment 2 wildfire 2011-08-16 01:18:57 UTC
Hi Tomas,

That's great. Could you clarify what you mean by "fully dependent on DNSSEC".

As I understand things, when set to 'yes', if DNS is not available (or insecure) ssh will fall back to TOFU - Trust on First Use - i.e. prompting about the fingerprint and asking whether or not to accept.

Only if the host has a key matching the SSHFP record
the DNS record was retrieved via DNSSEC
will 'yes' act differently (in this case auto accepting the key).

I'm struggling to see what the issue what that might be, since a malicious server (advertising itself via SSHFP and DNSSEC) will simply cause an additional entry to be stored in the known_hosts file and might cause your public ssh key to be sent over anyway.

Are you aware of another kind of potential problem, could you elucidate your thinking?


Comment 3 Tomas Mraz 2011-08-16 08:37:32 UTC
If your DNSSEC trust is misconfigured or broken then with using 'yes' you fully depend on the security of the DNS records. We do not want to make that default, at least not anymore soon than OpenSSH upstream decides so.

With having it set to 'ask' you can still verify the host key by other means and the DNSSEC just gives you another hint of the host key security.

Comment 4 Paul Wouters 2011-10-12 19:41:42 UTC
We've gone over this back in 2006. See #180277

[paul@bofh paul]$ grep VerifyHostKeyDNS /etc/ssh/ssh_config .ssh/config 
/etc/ssh/ssh_config:VerifyHostKeyDNS yes

[paul@bofh paul]$ sed -i 's/mail.xelerance.com/delme.xelerance.com/' .ssh/known_hosts

[paul@bofh paul]$ grep mail.xelerance.com .ssh/known_hosts
[paul@bofh paul]$ 

[paul@bofh paul]$ dig +dnssec sshfp mail.xelerance.com 

; <<>> DiG 9.7.4b1-RedHat-9.7.4-0.3.b1.fc14 <<>> +dnssec sshfp mail.xelerance.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 63197
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 3, AUTHORITY: 5, ADDITIONAL: 5

; EDNS: version: 0, flags: do; udp: 4096
;mail.xelerance.com.		IN	SSHFP

mail.xelerance.com.	3423	IN	SSHFP	1 1 35986CB1EDC535E0A216CA2595E4132D7DB6C767
mail.xelerance.com.	3423	IN	SSHFP	2 1 10D9F8AEC3AD276A8D9782E5C31D693962428968
mail.xelerance.com.	3423	IN	RRSIG	SSHFP 5 3 3600 20111104225846 20111012181411 42515 xelerance.com. aoSi9I6s9OSE3tN+RlakRuwpPRjhZrf2OMazUqXCW8chbblyma6sQuTQ uNdvQc1CpXsLb0TRYcKlTsJ2DH+3qnh2rmbEIFJkz6zv8hmGRkCrWFZT ySDo5LcR6cw84cHdGDBttXEKJOgwEUXyVd/GfYvTHHaK1V7+yx99ckDJ GHI=

Note the AD bit shows DNSSEC confirmed.

Now according do you I can "get in a fake server and type a password" or something that I don't quite understand. Let's see:

[paul@bofh paul]$ ssh paul@mail.xelerance.com
Linux mail.xelerance.com 2.6.32-34-server #77-Ubuntu SMP Tue Sep 13 20:54:38 UTC 2011 x86_64 GNU/Linux
Ubuntu 10.04.3 LTS

Welcome to the Ubuntu Server!
 * Documentation:  http://www.ubuntu.com/server/doc
You have new mail.
Last login: Wed Oct 12 15:20:53 2011 from

note it did NOT add this to known_hosts for me.

[paul@bofh paul]$ grep mail.xel .ssh/known_hosts
[paul@bofh paul]$ 

[paul@bofh paul]$ sudo sed -i 's/VerifyHostKeyDNS yes/VerifyHostKeyDNS ask/' /etc/ssh/ssh_config

[paul@bofh paul]$ ssh paul@mail.xelerance.com
The authenticity of host 'mail.xelerance.com (' can't be established.
RSA key fingerprint is f5:8b:9b:77:89:b2:28:0c:9e:e4:b4:b3:27:c4:3e:16.
Matching host key fingerprint found in DNS.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'mail.xelerance.com,' (RSA) to the list of known hosts.

Now without DNSSEC:
[paul@bofh paul]$ sed -i 's/mail.xelerance.com/delme.xelerance.com/' .ssh/known_hosts
[paul@bofh paul]$ sudo sed -i 's/' /etc/resolv.conf
[paul@bofh paul]$ sudo sed -i 's/VerifyHostKeyDNS ask/VerifyHostKeyDNS yes/' /etc/ssh/ssh_config

[paul@bofh paul]$ ssh paul@mail.xelerance.com
The authenticity of host 'mail.xelerance.com (' can't be established.
RSA key fingerprint is f5:8b:9b:77:89:b2:28:0c:9e:e4:b4:b3:27:c4:3e:16.
Matching host key fingerprint found in DNS.
Are you sure you want to continue connecting (yes/no)? 

Note that the ssh clieht behaves differently with or without DNSSEC....

So in my opinion, "yes" can be used instead of "ask". But I'll take "ask" as well, as I also said in 2006. Just get the thing deployed already.

Note You need to log in before you can comment on or make changes to this bug.