I just installed openssh-clients-4.5p1-2.fc7 and noticed that the option to use SSHFP DNS records is still not enabled. From the man page:
VerifyHostKeyDNS Specifies whether to verify the remote key using DNS and SSHFP resource records. If this option is set to yes, the client will implicitly trust keys that match a secure fingerprint from DNS. Insecure fingerprints will be handled as if this option was set to ask. If this option is set to ask, information on fingerprint match will be displayed, but the user will still need to confirm new host keys according to the StrictHostKeyChecking option. The argument must be yes, no, or ask. The default is no. Note that this option applies to protocol version 2 only.
See also VERIFYING HOST KEYS in ssh(1).
The openssh package maintainer has told me in the past he does not want to enable this option due to the "potential harm of an extra DNS lookup".
To me that seems like a weak argument against adding more security, especially since the sshd already does plenty of reverse dns lookups on the client to begin with. And with proper dns configuration, even without having an SSHFP record, the delay of one dns lookup in the ssh client is not going to exceed 100ms.
I maintain the "sshfp" package to generate these SSHFP records for hosts or domains based on .ssh/known_hosts or ssy-keyscan, amking it trivially easy for anyone who has their own domain to add SSHFP records to their domain to make sure of this additional security feature.
SSHFP records are providing real security. It gives you an additional hint on whether or not you can trust the remote host you are connecting to for the first time. It will add some safetey for people who just hit "yes" now to any new fingerprint presented by the ssh client (yeah sure, no one admits to doing it, but everyone does)
Xelerance has deployed SSHFP records for over a year now. We do not see any problems or even experience the extra wait time using an ssh client with VerifyHostKeyDNS enabled. It has been active on all openswan/xelerance domains and never prevented a single ssh client from connecting to those servers.
We would really like to see this option enabled by default. If we miss enabling this option for FC7, we will go through at least another six months of changing every install of FC manually to enable this in the /etc/ssh/ssh_config file.
Note that by now, RIPE's reverse tree is secured by DNSSEC. This covers all IP space in Europe. The first two CC:TLD's (Sweden and Bulgaria) have also enabled DNSSEC. This provides a very strong protection for SSHFP records, though granted this will take some resolver configurations, which is another topic that Fedora should at some point address for the caching-resolver package.
So, I really hope that we can enable SSHFP record lookups in the ssh client in its default configuration file.
As a sidenote, upgrading to the test2 version, i noticed there is no openssh-askpass package anymore. Will the upgrade from FC6 to FC7 be able to deal with this properly?
Paul
Am Freitag, den 23.03.2007, 21:05 +0100 schrieb Paul Wouters:
I just installed openssh-clients-4.5p1-2.fc7 and noticed that the option to use SSHFP DNS records is still not enabled. From the man page:
VerifyHostKeyDNS Specifies whether to verify the remote key using DNS and SSHFP resource records. If this option is set to yes, the client will implicitly trust keys that match a secure fingerprint from DNS. Insecure fingerprints will be handled as if this option was set to ask. If this option is set to ask, information on fingerprint match will be displayed, but the user will still need to confirm new host keys according to the StrictHostKeyChecking option. The argument must be yes, no, or ask. The default is no. Note that this option applies to protocol version 2 only. See also VERIFYING HOST KEYS in ssh(1).The openssh package maintainer has told me in the past he does not want to enable this option due to the "potential harm of an extra DNS lookup".
To me that seems like a weak argument against adding more security, especially since the sshd already does plenty of reverse dns lookups on the client to begin with. And with proper dns configuration, even without having an SSHFP record, the delay of one dns lookup in the ssh client is not going to exceed 100ms.
I maintain the "sshfp" package to generate these SSHFP records for hosts or domains based on .ssh/known_hosts or ssy-keyscan, amking it trivially easy for anyone who has their own domain to add SSHFP records to their domain to make sure of this additional security feature.
SSHFP records are providing real security. It gives you an additional hint on whether or not you can trust the remote host you are connecting to for the first time. It will add some safetey for people who just hit "yes" now to any new fingerprint presented by the ssh client (yeah sure, no one admits to doing it, but everyone does)
Xelerance has deployed SSHFP records for over a year now. We do not see any problems or even experience the extra wait time using an ssh client with VerifyHostKeyDNS enabled. It has been active on all openswan/xelerance domains and never prevented a single ssh client from connecting to those servers.
We would really like to see this option enabled by default. If we miss enabling this option for FC7, we will go through at least another six months of changing every install of FC manually to enable this in the /etc/ssh/ssh_config file.
Note that by now, RIPE's reverse tree is secured by DNSSEC. This covers all IP space in Europe. The first two CC:TLD's (Sweden and Bulgaria) have also enabled DNSSEC. This provides a very strong protection for SSHFP records, though granted this will take some resolver configurations, which is another topic that Fedora should at some point address for the caching-resolver package.
So, I really hope that we can enable SSHFP record lookups in the ssh client in its default configuration file.
As a sidenote, upgrading to the test2 version, i noticed there is no openssh-askpass package anymore. Will the upgrade from FC6 to FC7 be able to deal with this properly?
Paul
Can I check something? Is SSHFP not useful unless dnssec is on?
On Fri, 23 Mar 2007, nodata wrote:
Can I check something? Is SSHFP not useful unless dnssec is on?
It is still very much useful.
First of all, in the case of a trusted network, say a big university campus. Using sshfp records, administrators can add new machines to the network and put their sshfp records in DNS. You will be able to trust the keys for those machines if you trust your campus dns server. The only other known alternative to me for such ssh fingerprint deployments is putting the keys into an LDAP server. Or put it on some web page, which is not very useful for automation.
As for when you are on an untrusted network, an attacker would now have to both spoof your traffic to the DNS servers and man in the middle your ssh session. If you would use your own DNS, instead of a dhcp assigned one, the attacker would have to spoof more then just ssh. If you would be using a DNS server through a VPN, the attacker just can't spoof it at all.
There is not question that SSHFP will become much more useful when combined with DNSSEC. But DNSSEC is already here and deployed. Some CC:TLD's deploy it. Many testbeds exist, and orgnaisations internally are using it.
eg, an ssh session where VerifyHostDNS is enabled, would look like:
[paul@bofh ]$ ssh paul@www.xelerance.com The authenticity of host 'www.xelerance.com (193.110.157.145)' can't be established. RSA key fingerprint is ae:e2:07:ed:6e:fe:d9:0a:fc:a1:36:b7:ed:62:35:13. Matching host key fingerprint found in DNS. Are you sure you want to continue connecting (yes/no)?
It is still up to the human to make the decision. When a key would change, eg by a sysadmin or a hacker, you would get the additional LOUD warning about the "mismatching host key fingerprint found in DNS" which would clearly bring the point across that the ssh key changed and the admin didn't update the DNS, so therefor it is likely the admin didn't change the key, and your connection is being 'man in the middled'.
To me, the important part is, we do not LOSE anything by enabling it. But we do facilitate early adopters of SSHFP and DNSSEC.
Paul
I would also vote to enable it. It is a great security feature at almost no cost to the end-user.
Mike Stahnke
On 3/23/07, Paul Wouters paul@xelerance.com wrote:
On Fri, 23 Mar 2007, nodata wrote:
Can I check something? Is SSHFP not useful unless dnssec is on?
It is still very much useful.
First of all, in the case of a trusted network, say a big university campus. Using sshfp records, administrators can add new machines to the network and put their sshfp records in DNS. You will be able to trust the keys for those machines if you trust your campus dns server. The only other known alternative to me for such ssh fingerprint deployments is putting the keys into an LDAP server. Or put it on some web page, which is not very useful for automation.
As for when you are on an untrusted network, an attacker would now have to both spoof your traffic to the DNS servers and man in the middle your ssh session. If you would use your own DNS, instead of a dhcp assigned one, the attacker would have to spoof more then just ssh. If you would be using a DNS server through a VPN, the attacker just can't spoof it at all.
There is not question that SSHFP will become much more useful when combined with DNSSEC. But DNSSEC is already here and deployed. Some CC:TLD's deploy it. Many testbeds exist, and orgnaisations internally are using it.
eg, an ssh session where VerifyHostDNS is enabled, would look like:
[paul@bofh ]$ ssh paul@www.xelerance.com The authenticity of host 'www.xelerance.com (193.110.157.145)' can't be established. RSA key fingerprint is ae:e2:07:ed:6e:fe:d9:0a:fc:a1:36:b7:ed:62:35:13. Matching host key fingerprint found in DNS. Are you sure you want to continue connecting (yes/no)?
It is still up to the human to make the decision. When a key would change, eg by a sysadmin or a hacker, you would get the additional LOUD warning about the "mismatching host key fingerprint found in DNS" which would clearly bring the point across that the ssh key changed and the admin didn't update the DNS, so therefor it is likely the admin didn't change the key, and your connection is being 'man in the middled'.
To me, the important part is, we do not LOSE anything by enabling it. But we do facilitate early adopters of SSHFP and DNSSEC.
Paul
-- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
On Fri, Mar 23, 2007 at 09:05:08PM +0100, Paul Wouters wrote:
We would really like to see this option enabled by default.
Is there a RFE in bugzilla?
Steve
On Sat, 24 Mar 2007, Steven Pritchard wrote:
On Fri, Mar 23, 2007 at 09:05:08PM +0100, Paul Wouters wrote:
We would really like to see this option enabled by default.
Is there a RFE in bugzilla?
I once put this request through bugzilla, but the maintainer closed the issue because he did not want to enable it. I was looking for a broader discussion on this topic, hance the use of this discussion list.
Paul
On Sun, Mar 25, 2007 at 12:05:40AM +0100, Paul Wouters wrote:
On Sat, 24 Mar 2007, Steven Pritchard wrote:
Is there a RFE in bugzilla?
I once put this request through bugzilla, but the maintainer closed the issue because he did not want to enable it. I was looking for a broader discussion on this topic, hance the use of this discussion list.
Bugs can be reopened. What's the bug #?
FWIW, this sounds like a no-brainer to me...
Steve
On Sat, 24 Mar 2007, Steven Pritchard wrote:
On Sun, Mar 25, 2007 at 12:05:40AM +0100, Paul Wouters wrote:
On Sat, 24 Mar 2007, Steven Pritchard wrote:
Is there a RFE in bugzilla?
I once put this request through bugzilla, but the maintainer closed the issue because he did not want to enable it. I was looking for a broader discussion on this topic, hance the use of this discussion list.
Bugs can be reopened. What's the bug #?
FWIW, this sounds like a no-brainer to me...
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=180277
Paul
-
Michael Stahnke -
nodata -
Paul Wouters -
Steven Pritchard