In the SCO Unix (UnixWare 7.1.4 i386 x86at) the option "UseDNS no" in the sshd_config is ignored. Still the DNS lookup is being made when the client connection is started.
You'll have to provide more information. Are you saying that ssh is doing a lookup? If so, this would be unsurprising, given sshd_config doesn't not affect it. If you mean that sshd is doing the lookup, I'm quite sure that all the calls to getnameinfo() that aren't using NI_NUMERICHOST are disabled by UseDNS=no. Could it be a PAM module or some library code that is making the lookup?
If it's the server, the other thing that can do it is the system login recording libraries (try sshd -u0).
Created attachment 2062 [details] sshd_config
Created attachment 2063 [details] sshd-u0_truss.txt
(In reply to comment #2) > If it's the server, the other thing that can do it is the system login > recording libraries (try sshd -u0). The -u0 options does not help. Attached is the trace of sshd with this option enabled. It took more than 1 minute before the "login as:" dialog appeared in the Putty client. The NS lookup is made: 20538: open("/etc/resolv.conf", O_RDONLY, 0666) = 4 20538: ioctl(4, TCGETS, 0x08046F64) Err#25 ENOTTY 20538: fxstat(2, 4, 0x08046FA4) = 0 20538: brk(0x0814ECE0) = 0 20538: read(4, " n a m e s e r v e r 1".., 8192) = 20 20538: read(4, 0x0814A090, 8192) = 0 20538: close(4) = 0 20538: nuname(0x08046B6B) = 1 20538: xsocket(UW71|XPG4, AF_INET, SOCK_DGRAM, 0) = 4 20538: xconnect(UW71|XPG4, 4, 0xBFF5D9B4, 16) = 0 20538: xsendmsg(UW71|XPG4, 4, 0x08046DB4, 0) = 42 ... Also the sshd_config attached.
The bit leading up to this is: 20538: xgetsockaddr(UW71|XPG4, REMOTENAME, 3, 0x08047ADC, 0x08047B60) = 0 20538: gettimeofday(0x08047070, 0xBFF5A870) = 0 20538: getpid() = 20538 [ 20271 ] 20538: open("/etc/resolv.conf", O_RDONLY, 0666) = 4 20538: ioctl(4, TCGETS, 0x08046F64) Err#25 ENOTTY Which makes me think this is canohost.c:get_remote_hostname(). It does a getpeername() call that is probably the xgetscoaddr call above. It then does a: if (getnameinfo((struct sockaddr *)&from, fromlen, ntop, sizeof(ntop), NULL, 0, NI_NUMERICHOST) != 0) call. This should not result in any DNS traffic though - it's requesting a numeric hostname. IMO the only way for it to end up in the DNS here is if the OS getnameinfo() is buggy. This is further supported by what it does next: 20538: open("/etc/services", O_RDONLY, 0666) = 4 20538: ioctl(4, TCGETS, 0x08047894) Err#25 ENOTTY 20538: fxstat(2, 4, 0x080478D4) = 0 20538: read(4, " # i d e n t\t " @ ( # )".., 8192) = 4260 20538: read(4, 0x0814A090, 8192) It's not looking at /etc/hosts - it's looking for a port number to service name lookup and it's doing so in spite of the getnameinfo() call above not requesting a service name lookup. So, I think your system has been configured to do service lookups by DNS *and* your libc/resolver getnameinfo() is broken. There isn't much we can do in sshd to mitigate this. If it is still failing for you then I suggest disabling service lookups via DNS and/or contacting your OS vendor.
closing resolved bugs as of 8.6p1 release