openssh unix dev - Apr 2003 - [Bug 549] Login Delay / Remove unwanted reverse map check

http://bugzilla.mindrot.org/show_bug.cgi?id=549

           Summary: Login Delay / Remove unwanted reverse map check
           Product: Portable OpenSSH
           Version: 3.5p1
          Platform: PPC
        OS/Version: AIX
            Status: NEW
          Severity: normal
          Priority: P3
         Component: sshd
        AssignedTo: openssh-unix-dev at mindrot.org
        ReportedBy: devin.nate at bridgecomm.net


OpenSSH compiled and working well on AIX 4.3.3 and 5.1.

When some users go to connect using a ssh client, they experience a 60-90 second
delay. Basic examination reveals that it's the ip->host reverse map.
Further
investigation reveals the code in canohost.c:

        debug3("Trying to reverse map address %.100s.", ntop);
        /* Map the IP address to a host name. */
        if (getnameinfo((struct sockaddr *)&from, fromlen, name,
sizeof(name),
            NULL, 0, NI_NAMEREQD) != 0) {
                /* Host name not found.  Use ip address. */
#if 0
                log("Could not reverse map address %.100s.", ntop);
#endif
                return xstrdup(ntop);
        }

If the reverse lookup fails, it resorts to the IP address. Ideally, a person
could configure ssh to never do a reverse lookup.

sshd is running, via inittab:
     sshd:2:respawn:/usr/local/sbin/sshd -Du0

Documentation suggests that the option -u0 causes sshd not to do a lookup, but
this is not true (i.e. no if statement surrounding that block of code that would
indicated -u0 will stop the lookup), and experience shows that users are still
getting hung up on a reverse lookup in some situations.

I've created a mini patch to bypass the check, which basically amounts to:

#ifdef DISABLE_REVERSE_MAP
        /* Don't search for hostname. Use ip address */
        debug3("Skipping reverse map of address.");
        return xstrdup(ntop);
#endif
..original canohost.c lookup code.

I am happy to submit my patches, or, would like to see either a *_config option
and or a ./configure --disable-reverse-map type option to absolutely stop DNS
lookups.

Thanks



------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

http://bugzilla.mindrot.org/show_bug.cgi?id=549





------- Additional Comments From dtucker at zip.com.au  2003-05-03 09:16 -------
Created an attachment (id=279)
 --> (http://bugzilla.mindrot.org/attachment.cgi?id=279&action=view)
Disable reverse lookups in canohost.c when utmp_len == 0

How about fixing canohost so it behaves more like the man page?  Example patch
attached.

Note: I'm not sure this is the right way to go about this but 
get_remote_hostname is used by ssh and sshd and because utmp_len is a
server-only variable you can't just import in and check if utmp_len == 0.



------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

http://bugzilla.mindrot.org/show_bug.cgi?id=549

dtucker at zip.com.au changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
         OS/Version|AIX                         |All
           Platform|PPC                         |All



------- Additional Comments From dtucker at zip.com.au  2003-05-03 09:17 -------
This affects all platforms.



------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

http://bugzilla.mindrot.org/show_bug.cgi?id=549





------- Additional Comments From mouring at eviladmin.org  2003-05-03 12:39
-------
Are we sure this is right?

The manpage states:

 -u0 may also be used to prevent sshd from making
             DNS requests unless the authentication mechanism or configuration
             requires it.  Authentication mechanisms that may require DNS in-
             clude RhostsAuthentication, RhostsRSAAuthentication,
             HostbasedAuthentication and using a from="pattern-list"
option in
             a key file.  Configuration options that require DNS include using
             a USER at HOST pattern in AllowUsers or DenyUsers.

I suspect this will break the exceptions listed here.  Which would be wrong.  
Is the original reporter sure that he is not running accross one of theses 
cases?  Since the bug report is prefixed by "When some users..."  not
"Every
user..."



------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

http://bugzilla.mindrot.org/show_bug.cgi?id=549

dtucker at zip.com.au changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
 Attachment #279 is|0                           |1
           obsolete|                            |



------- Additional Comments From dtucker at zip.com.au  2003-05-04 10:00 -------
(From update of attachment 279)
Damn, you're right.  Note to self: read man page properly next time.




------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

http://bugzilla.mindrot.org/show_bug.cgi?id=549





------- Additional Comments From devin.nate at bridgecomm.net  2003-05-06 04:31
-------
Hi,

The sshd_config in question includes an AllowUsers line. It does not have any
USER at HOST specified users, only USER,USER,USER,etc. RhostAuthentication is
set
to no, RhostRSAAuthentication is set to no, HostbasedAuthentication is default
and therefore set to no, user keyfiles are not used, and no from lines are
specified.

The short answer is, no, according to the documentation we do not have any of
the exceptions that would require a DNS lookup when -u0 is specified.

The longer answer(s):

1a. I wouldn't use a hostname in sshd_config or other security file even if
DNS
worked perfectly all of the time. I still wish to disable DNS lookups
completely.

1b. OpenSSH already uses an IP address if/when DNS fails. It's not like
OpenSSH
guarentees that you'll get a legitimate hostname out of the DNS lookup. The
existing code uses an IP address when the ip->host lookup fails. If you use a
USER at HOST specification, or anything which relies on a hostname... a simple
DNS
error will cause OpenSSH to do something else. In some cases, based on what I
understand, OpenSSH may deny a legit user access, in other cases allow a
non-permitted user access.

2. Interestingly, where an IP address causes a specific user a delay, adding it
to /etc/hosts (with /etc/netsvc.conf specifying to use /etc/hosts first), the
first connect proceeds quickly, but if the user enters a bad password a second
DNS lookup is performed, which then takes 60-90 seconds. If the user enters a
password bad a second time, there is no delay. (I didn't care to even figure
this out, since I'd prefer to just diable DNS period - not have /etc/hosts
entries to resolve IPs that customers have that cause DNS problems).

I hope this provides more info. I looked at the patch submitted by Darren
Tucker, seems like an excellent approach also.

Thanks



------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

http://bugzilla.mindrot.org/show_bug.cgi?id=549





------- Additional Comments From dtucker at zip.com.au  2003-05-06 09:16 -------
What about making "-u -1" unconditionally disable DNS lookups (even if
this
means an automatic fail for those authentication types)?  

I'd suggest a new option but I know people think there are too many 
already, but totally disabling lookups seems to be a common request.



------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

http://bugzilla.mindrot.org/show_bug.cgi?id=549





------- Additional Comments From devin.nate at bridgecomm.net  2003-05-06 10:41
-------
I don't think (I could be wrong, I certainly haven't checked all the
code), that
disabling DNS will automatically break all the OpenSSH components that would
like to have a hostname. Instead, my suspicion is that you'll need to use
the ip
address(es) in place of the hostname(s). In fact, I just tested USER at
IP.IP.IP.IP
and that worked as predicted. (i.e. allowed me in when I had the right IP
address, disallowed me when I came from a non-permitted IP address). My sshd is
patched to never do the DNS lookup.

I consider using IP addresses instead of hostnames a feature. An item in the
config file, similar to "VerifyReverseMapping" might be appropriate:

ReverseMapIPAddresses [ yes(default)|no ]  (for ssh_config and sshd_config)

I realize that the Internet continues to struggle with hostnames vs ip
addresses. How many firewall admins wouldn't want to do something like
"DENY
pornsite.com", or "DENY spamsite.net" and get all the potential
IP addresses and
be done with it. And yet, DNS based access controls haven't taken off.

Many other network daemons let you disable DNS. I realize a security server
isn't quite the same as your favorite smtp, http, or ftp server - however,
especially given our environment here, and what I suspect many users of OpenSSH
have, I don't see DNS records being needed very often. I guess another way
to
look at this is with a config option to stop OpenSSH from using the hostname in
ACLs (and therefore not performing DNS lookups), and instead use the IP address
only.

Thanks,
Devin Nate



------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

http://bugzilla.mindrot.org/show_bug.cgi?id=549





------- Additional Comments From mouring at eviladmin.org  2003-05-10 14:43
-------
Umm.. No.. This does not sound like an OpenSSH issue, but you state yourself:

[..] adding it to /etc/hosts (with /etc/netsvc.conf specifying to 
use /etc/hosts first), the first connect proceeds quickly, but if the user 
enters a bad password a second DNS lookup is performed, which then takes 60-90 
seconds. [..]

This sounds like a broken resolver behavior.  I run OpenSSH with ZERO dns 
service at work (not totally true, but no sane DNS service =) and at home.  I 
don't see this behavior (Sol 2.7, Sol 2.5.1, OpenBSD 3.2, OpenBSD --current,
Solaris 9).

Are we dead sure this is a 'universal' issue and not a brain damaged
resolver?



------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

http://bugzilla.mindrot.org/show_bug.cgi?id=549





------- Additional Comments From devin.nate at bridgecomm.net  2003-05-11 08:09
-------
Hey Ben;

I'm pretty sure that this is a universial issue. Basically it boils down to
the
fact that neither -u0 nor any other configuration paramater will stop the block
of code I first wrote about (in particular, getnameinfo(... NI_NAMERAQD) in
canohost.c) from executing. sshd will always resolve an ip address to host name
if it can (i.e. if DNS succeeds) - you cannot stop it. You can stop it from
using that information, but you can't stop it from inquiring about it.

To your point about bad resolver behavior, I suppose it may or may not be.
However, regardless of what you do, sshd WILL try to use the resolver. And the
DNS system does leave potential for delays due to resolution, which may fail at
the end. It happens. I'm trying to get some sort of configuration option
telling
sshd NOT to do that getnameinfo() call built into OpenSSH.

Which brings me to the next question: I cannot commit changes to the OpenSSH
code myself - how does that process work? Darren, you seem extremely active in
the OpenSSH community. Is the current patch good enough.. should I be
writing/submitting a patch to make a new sshd_config option.. what's the
status
of this?

Thanks!



------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

http://bugzilla.mindrot.org/show_bug.cgi?id=549





------- Additional Comments From dtucker at zip.com.au  2003-05-11 13:16 -------
I'm a relative newbie so I'll defer to Ben on this.

In answer to the process question, a few people have commit access to -portable,
but generally they'll only commit simple, obvious changes on their own. 
Larger
or more contentious changes generally require agreement from one or more others 
(that's the meaning of the "ok [user]@" bits in ChangeLog).

The other thing is -portable is a branch (more or less) of the original OpenSSH 
from OpenBSD, and any changes, small or not, that cause it to diverge from 
OpenBSD without good reason will get a *lot* of restistance.

Something that might be worth checking: get_canonical_hostname() does some 
caching, perhaps there's something in there that would explain the
inconsistent
results you're seeing wrt the lookups.  If I have time next week I'll
see if I
can reproduce this on my AIX box.



------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.