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

Bug 730558

Summary: Set set VerifyHostKeyDNS to 'yes'
Product: [Fedora] Fedora Reporter: wildfire
Component: opensshAssignee: Jan F. Chadima <jchadima>
Status: CLOSED RAWHIDE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 15CC: david, jchadima, mattias.ellert, mgrepl, pwouters, tmraz
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
See Also:
Fixed In Version: openssh-5.9p1-11.fc17 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2011-10-18 05:53:51 EDT Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:

Description wildfire 2011-08-14 09:31:16 EDT
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 06:16:46 EDT
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-15 21:18:57 EDT
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 04:37:32 EDT
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 15:41:42 EDT
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/' .ssh/known_hosts

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

[paul@bofh paul]$ dig +dnssec sshfp 

; <<>> DiG 9.7.4b1-RedHat-9.7.4-0.3.b1.fc14 <<>> +dnssec sshfp
;; 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

;; ANSWER SECTION:	3423	IN	SSHFP	1 1 35986CB1EDC535E0A216CA2595E4132D7DB6C767	3423	IN	SSHFP	2 1 10D9F8AEC3AD276A8D9782E5C31D693962428968	3423	IN	RRSIG	SSHFP 5 3 3600 20111104225846 20111012181411 42515 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
Linux 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:
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
The authenticity of host ' (' 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 ',' (RSA) to the list of known hosts.

Now without DNSSEC:
[paul@bofh paul]$ sed -i 's/' .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
The authenticity of host ' (' 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.