What is the point of sshd “UseDNS” option?

Question

I know what it does, but I don't know why. What attack(s) does it prevent?

Is it relevant for all kind of authentication methods? (hostbased, password, publickey, keyboard-interactive ...)

I added one to CoreOS also here: https://github.com/coreos/bugs/issues/92 — , Jul 25 '14 at 09:36

Gilles 'SO- stop being evil' · Accepted Answer · 2016-02-16T20:46:36.013

The UseDNS option is mostly useless. If the client machines are out there on the Internet, there is a high chance that they don't have any reverse DNS, their reverse DNS doesn't resolve forward, or their DNS doesn't provide any information other than “belongs to this ISP” which the IP address already tells you.

In typical configurations, DNS is only used for logging. It can be used for authentication, but only if IgnoreRhosts no is specified in sshd_config. This is for compatibility with old installations that used rsh, where you can say “the user called bob on the machine called darkstar may log in as alice without showing any credentials” (by writing darkstar bob in ~alice/.rhosts). It is only secure if you trust all the machines that may possibly be connecting to the ssh server. In other words, this is very very rarely usable in a secure way.

Given that the DNS lookup doesn't provide any useful information except in very peculiar circumstances, it should be turned off. As far as I can tell, the only reason it's on by default is that it's technically more secure (if you're concerned about authentication, not availability), even though that only applies to a tiny set of circumstances.

Another argument for turning off this feature is that every superfluous feature is an unnecessary security risk.

So, UseDNS is relevant only for hostbased authentication ? If i don't use hostbased auth and i don't care if hostname or IP show up in logs, UseDNS makes no difference ? — user368507, Nov 28 '12 at 19:24
@user368507 Yes, that's it. UseDNS isn't even useful if you use key-based host authentication, only if you use hostname-based host authentication (i.e. extremely weak authentication). — Gilles 'SO- stop being evil', Nov 28 '12 at 19:33
@Gilles of course, if you use key-based and hostname-based authentication, UseDNS is very much useful, and critical. You authenticate a user based on key, and the server based on hostname, assigned to a MAC address. — kara deniz, May 12 '16 at 19:46

score 52 · Answer 2 · answered Mar 05 '14 at 17:48

52

I added to a bug report (old but still current) in Ubuntu about this.

https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/424371

I proposed changing the default to No and adding newer documentation on it:

# UseDNS - Determines whether IP Address to Hostname lookup and comparison is performed
# Default value is No which avoids login delays when the remote client's DNS cannot be resolved
# Value of No implies that the usage of "from=" in authorized_keys will not support DNS host names but only IP addresses.
# Value of Yes supports host names in "from=" for authorized_keys. Additionally if the remote client's IP address does not match the resolved DNS host name (or could not be reverse lookup resolved) then a warning is logged.

answered Mar 05 '14 at 17:48

Rodney

553

3

Up up upvote ... this is more useful, because it contains a piece of information I was looking for. – 0xC0000022L May 23 '14 at 17:54
1

Similarly if UseDNS is no then hostnames cannot be matched in pam_access rules and IPs must be used instead. – ColinM Apr 14 '16 at 13:29
1

I upvoted this answer a couple of years ago but only today I noticed that, the default was changed to "UseDNS no" in OpenSSH 6.8p1, which is in Ubuntu 15.10 and later. – Anthony Geoghegan Mar 23 '17 at 21:30
RedHat (in RHEL7) just recently changed the default to No as well, which breaks hostname-based access controls (which are useful as mostly advisory controls on an intranet, obviously not as the sole access control mechanism). – dannysauer Jan 29 '18 at 18:37
Great answer, thanks. "Value of Yes supports host names in "from=" for authorized_keys." This is critical. Without UseDNS yes, from= does not work at all unless IP addresses are specified in the from= option. Even if the hostname is in the hosts file! So, "UseDNS" should more accurately be called "SupportHostNames". For search engines, sshd[1234]: Authentication tried for theuser with correct key but not from a permitted host (host=1.2.3.4, ip=1.2.3.4). – Rob Bricheno Nov 04 '22 at 12:16

score 9 · Answer 3 · edited Apr 13 '17 at 12:37

9

From the manpage of sshd_config(5):

 UseDNS  Specifies whether sshd(8) should look up the remote host name and
         check that the resolved host name for the remote IP address maps
         back to the very same IP address.  The default is “yes”.

Enabling this makes access from a location without proper (forward and reverse) DNS generate a warning in the logs.

So this doesn't prevent any attack except that it would need some qualified remote address of the client in order not to log any warning. Such a warning may help you in tracing down the attacker only if that PTR record makes any sense.

^{edit: updated according to comment of Andrey Voitenkov.}

edited Apr 13 '17 at 12:37

Community

1

answered Nov 27 '12 at 22:27

gertvdijk

13,977

So it is a filter on who is allowed to connect based on whatever there is in the DNS server ? – user368507 Nov 27 '12 at 22:31
2

Why would it make access impossible? sshd just generates warning if DNS A/PTR records do not match. Logon sequence will be slow in case of resolving problems. – Andrey Voitenkov Nov 27 '12 at 22:32
This does prevent access if the authorized key has been compromised as long as the attacker cannot spoof the values in the from= field before the authorized key in question (if used). – Alecz Nov 15 '17 at 15:55

score 7 · Answer 4 · answered Nov 28 '12 at 14:10

It is needed when you use FROM option in an authorized_keys file and you want to filter by names and not just IPs.

The FROM option in a line of an authorized_keys file allows you to limit hosts that can use a specific key.
This increases the ability of managing multiple servers that have access to each other without allowing clones of a machine to impersonate it's origin, usually unintentionally (leftover crontabs, human error).

AnthonyK · Answer 5 · 2016-04-07T02:00:11.500

I'd like to add that on CentOS 7 (7.1.1503) and hence Red Hat Enterprise Linux 7, I was unable to log in with the default setting of yes for UseDNS. After uncommenting and setting it to no, I was able to log in. Thus it appears that one can indeed be denied service if DNS is not working correctly! In CentOS 6, it appears the default is no and hence I can ssh in with no functioning DNS!

I'd like to add that my experimentation was on LXC containers and not physical machine, in case that makes a difference!

What is the point of sshd “UseDNS” option?

5 Answers5

Linked