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
I propose to change this to 'ask' only. This will improve the security and will not make the ssh security fully dependent on DNSSEC.
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 AND 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? Cheers, Anand
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.
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 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 4096 ;; QUESTION SECTION: ;mail.xelerance.com. IN SSHFP ;; ANSWER SECTION: 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.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 76.10.157.69 paul@mail:~$ 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.com The authenticity of host 'mail.xelerance.com (193.110.157.189)' 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,193.110.157.189' (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/193.110.157.136/8.8.8.8/' /etc/resolv.conf [paul@bofh paul]$ sudo sed -i 's/VerifyHostKeyDNS ask/VerifyHostKeyDNS yes/' /etc/ssh/ssh_config [paul@bofh paul]$ ssh paul.com The authenticity of host 'mail.xelerance.com (193.110.157.189)' 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.