getnameinfo(3) called from sshd finds error in /etc/hosts?

[Vasil Dimov]

The problem: when trying to login to an sshd server from 172.27.0.83 it
takes more than a minute for the password prompt to appear.

setup on the server machine:
OS: 5.2.1-RELEASE-p3

/etc/resolv.conf
nameserver 192.168.10.253
(does not know anything about 172.27.0.83)

/etc/hosts:
kutelo2		172.27.0.83

/etc/nsswitch.conf:
hosts: files dns

when started `sshd -ddd' sshd stops at the first:
debug3: Trying to reverse map address 172.27.0.83.
for about a minute. There is a second identical message a few lines after
that, but it causes no problems.

As I see the function "sleeping" that long is getnameinfo(3) called from
libssh from canohost.c

So I extracted the code into a separate file tmp.c:
int
main(int argc, char **argv)
{
    struct sockaddr_in  from;
    socklen_t           fromlen;
    char                name[NI_MAXHOST];
    int                 errcode;

    fromlen = sizeof(from);
    memset(&from, 0, sizeof(from));

    from.sin_len = sizeof(from);
    from.sin_family = AF_INET;
    from.sin_port = htons(2379);
    inet_aton("172.27.0.83", &from.sin_addr);

    if ((errcode = getnameinfo((struct sockaddr *)&from, fromlen, name,
                               sizeof(name), NULL, 0, NI_NAMEREQD)) != 0) {
        fprintf(stderr, "getnameinfo(): %d\n", errcode);
    } else {
        name[sizeof(name) - 1] = '\0';
        printf("resolved OK: %s\n", name);
    }

    return 0;
}

which gives:
resolved OK: kutelo2

This is a mystery as the code in canohost.c is exactly the same, but returns
error code EAI_NONAME after more than a minute sending requests to the
nameserver. What work it has to do with the nameserver as 172.27.0.83 is in
/etc/hosts?

Than I changed nsswitch.conf to:
hosts: files [unavail=return] dns

In that case tmp.c's behavior does not change (resolved OK: kutelo2),
but sshd's first call of getnameinfo(3) fails immediately with EAI_NONAME.
It seems that according to this situation kutelo2 entry in /etc/hosts is
corrupted, but tmp.c does not think so, even when started as the sshd user.

Any ideas of what is happening?