Logins to OpenSSH server slow due to "UseDNS yes" config

Bug #424371 reported by Brian Kelley
60
This bug affects 14 people
Affects Status Importance Assigned to Milestone
openssh (Ubuntu)
Fix Released
Low
Unassigned

Bug Description

When logging in to my Ubuntu 8.04 Server edition server via SSH (client PuTTY), logins take exactly 20 seconds from the time the username is entered and the time the password request appears.

The problem is caused by the "UseDNS yes" config parameter. When it is changed to "UseDNS no", the server logs in instantly.

The cause of the problem is that the server is in a network that does not have a DHCP server to store client hostnames, and thus, when requesting the hostname, it waits for the request to timeout. When the same server is put on a network with a DHCP server, the logins are instantaneous as well.

Another workaround is to put the client's hostname and IP address in /etc/hosts.

This bug has similar symptoms to https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/84899 , but in my case, disabling GSSAPIAuthentication does not resolve the issue.

I would disable UseDNS permanently, but I am skiddish because it sounds like a security feature. Unfortunately, it seems worthless; when I put the client's hostname and the WRONG IP address in /etc/hosts, the connection still is successful (after a 20 second delay). That poses the question: what is the point of UseDNS?

In bug 84899, someone suggests changing /etc/nsswitch.conf, but my configuration was already like the recommended fix.

All config files are at their defaults.

To Reproduce:
Install Ubuntu Server 8.04
`apt-get install openssh-server`
Put machine on non-DHCP network
Connect to machine's IP

`lsb_release -rd`
Description: Ubuntu 8.04.3 LTS
Release: 8.04

`apt-cache policy openssh-server1
Installed: 1:4.7p1-8ubuntu1.2

Revision history for this message
Brian Kelley (brian-kelley) wrote :

After reading more about UseDNS, the more pertinent issue is what is the point of it at all if a false IP for the hostname is still accepted as a valid connection.

Also, why is there no setting to make it timeout after a certain number of seconds (aka, what if the DNS request didn't time out for a minute, as some on the web are finding)? There should be a setting to force a DNS timeout.

Revision history for this message
lunch (launch-mailinator-com) wrote :

I found this and it worked...

go into your /etc/nsswitch.conf file and comment out the hosts line - apparently the delay is caused by mdns time outs...

Restart your ssh server and you should be good to go.

Revision history for this message
Chuck Short (zulcss) wrote :

Hi,

I was wondering if you were still having this problem?

Regards
chuck

Changed in openssh (Ubuntu):
importance: Undecided → Low
status: New → Incomplete
Revision history for this message
Brian Kelley (brian-kelley) wrote :

Lunch, I did not have that line in the nsswitch.conf file, I had already checked.

And yes Chuck, I am still experiencing it (and I found another computer that is also doing it, Cent OS 4.5, same version of OpenSSH)

Revision history for this message
Brian (brian-p-stamper) wrote :

I have this same issue, but on Fedora (yes, I realize this is an ubuntu forum)

On Fedora, I have the issue on 5.2 openssh (FC10+) but not on 5.1 (FC9)

If a host is in the hosts file, it connects instantly. If it needs to check DNS, it takes 15 seconds or more to connect. There's no slowness to my DNS servers. A tcpdump shows that when connecting from a host not in the hosts file, it queries the DNS server multiple times at multiple phases of the connection. If I change UseDNS to no in the sshd_config, it works fine. However that disables other things, such as host resolution for anchoring ssh keys to a "from=" address. It can still be done with IP addresses, but for my users who connect from dynamic IPs such as from comcast, they can no longer lock their ssh keys down, which is a problem.

Chuck Short (zulcss)
Changed in openssh (Ubuntu):
status: Incomplete → Confirmed
Revision history for this message
Rodney Beede (business2008+launchpad) wrote :

I'd propose submitting a request upstream to make the default setting for UseDNS be No.

Additionally add comments in the sshd_config and man page:

# 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.
# UseDNS Yes

Revision history for this message
Rod Smith (rodsmith) wrote :

Just to note: This problem still exists in Ubuntu 14.04LTS and 14.10. It's annoying because I have to make changes to every new installation.

Revision history for this message
Alexander (ustimenko-alexander) wrote :

Does someone sent this upstream?

Revision history for this message
beej (beej) wrote :

instead of asking the OpenSSH project to change their default configuration, i filed a bug to have the lookup not be blocking.

Bug 2545 - reverse DNS lookups shouldn't block login
https://bugzilla.mindrot.org/show_bug.cgi?id=2545

Revision history for this message
beej (beej) wrote :

the bug i filed with openssh was marked WONTFIX. the developer who did so claims that the openssh default is UseDNS=no.

can somebody check if the latest ubuntu default is still UseDNS=yes?

Revision history for this message
Colin Watson (cjwatson) wrote :

We don't modify this in Debian/Ubuntu. The default was changed to "UseDNS no" in OpenSSH 6.8p1, which is in Ubuntu 15.10 and later.

Changed in openssh (Ubuntu):
status: Confirmed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.