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
Created attachment 279 [details] 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.
This affects all platforms.
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@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..."
Comment on attachment 279 [details] Disable reverse lookups in canohost.c when utmp_len == 0 Damn, you're right. Note to self: read man page properly next time.
Hi, The sshd_config in question includes an AllowUsers line. It does not have any USER@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@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
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.
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@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
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?
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!
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.
- markus@cvs.openbsd.org 2003/06/02 09:17:34 [auth2-hostbased.c auth.c auth-options.c auth-rhosts.c auth-rh-rsa.c] [canohost.c monitor.c servconf.c servconf.h session.c sshd_config] [sshd_config.5] deprecate VerifyReverseMapping since it's dangerous if combined with IP based access control as noted by Mike Harding; replace with a UseDNS option, UseDNS is on by default and includes the VerifyReverseMapping check; with itojun@, provos@, jakob@ and deraadt@ ok deraadt@, djm@ Switch UseDNS off if you don't want any DNS lookups.
Mass change of RESOLVED bugs to CLOSED