Bug 3510 - host name lookup quirk
Summary: host name lookup quirk
Status: CLOSED INVALID
Alias: None
Product: Portable OpenSSH
Classification: Unclassified
Component: ssh (show other bugs)
Version: 9.1p1
Hardware: Other Linux
: P5 normal
Assignee: Assigned to nobody
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2022-12-13 00:47 AEDT by Thomas Koeller
Modified: 2023-03-17 13:39 AEDT (History)
1 user (show)

See Also:


Attachments
debug patch (388 bytes, patch)
2022-12-13 23:23 AEDT, Thomas Koeller
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Thomas Koeller 2022-12-13 00:47:11 AEDT
Setting up hostbased authentication I noticed a difference in treatment of the requesting client's host name, depending on whether the connection is via ipv4 or ipv6. In the ipv6 case, the client's fqdn is looked up in /etc/shosts as documented, while in the ipv4 case the client's unadorned host name is used.

After some debugging I found that the apparently the getnameinfo() function, which is used by the client to retrieve its own host name, is responsible. It seems that calling this function with the 'flags' argument set to 'NI_NAMERQD' returns the fqdn for an ipv6 socket, but for ipv4 it returns just the plain host name without a domain part.

Now, an obvious, easy workaround for this problem is to have both names in /etc/shosts, but that is certainly undesirable. I wonder if there is a better workaround?
Comment 1 Damien Miller 2022-12-13 09:44:11 AEDT
That is not documented behaviour of NI_NAMERQD:

> NI_NAMEREQD
>    If set, then an error is returned if the hostname
>    cannot be determined.

Do you have the short names in question in /etc/hosts? If so, they may be used in favour of a full DNS lookup.
Comment 2 Thomas Koeller 2022-12-13 20:45:17 AEDT
(In reply to Damien Miller from comment #1)
> That is not documented behaviour of NI_NAMERQD:

Of course not, but it is the actual behavior I observe. I put a debug output statement right after the call to getnameinfo() in in canohost.c:

                /* Get the address in ascii. */
                if ((r = getnameinfo((struct sockaddr *)&addr, addrlen, ntop,
                    sizeof(ntop), NULL, 0, flags)) != 0) {
                        error_f("getnameinfo %d failed: %s",
                            flags, ssh_gai_strerror(r));
                        return NULL;
                }
>>>             debug_f("host name lookup returned: %s", ntop);
                return xstrdup(ntop);

and this is what I get:

[thomas@sarkovy ~]$ ssh -6 -v sarkovy.koeller.dyndns.org 2>&1 | grep -e '^debug1: get_socket_address:'
debug1: get_socket_address: host name lookup returned: fd46:1ffa:d8e0::1 (flags = 1)
debug1: get_socket_address: host name lookup returned: fd46:1ffa:d8e0::1 (flags = 1)
debug1: get_socket_address: host name lookup returned: sarkovy.koeller.dyndns.org (flags = 8)
debug1: get_socket_address: host name lookup returned: fd46:1ffa:d8e0::1 (flags = 1)

[thomas@sarkovy ~]$ ssh -4 -v sarkovy.koeller.dyndns.org 2>&1 | grep -e '^debug1: get_socket_address:'
debug1: get_socket_address: host name lookup returned: 192.168.0.1 (flags = 1)
debug1: get_socket_address: host name lookup returned: 192.168.0.1 (flags = 1)
debug1: get_socket_address: host name lookup returned: sarkovy (flags = 8)

> Do you have the short names in question in /etc/hosts? If so, they
> may be used in favour of a full DNS lookup.

No, I don't, the names are looked up via DNS.
Comment 3 Thomas Koeller 2022-12-13 23:23:06 AEDT
Created attachment 3642 [details]
debug patch

A patch to add debug output showing the problem.
Comment 4 Thomas Koeller 2022-12-16 05:20:53 AEDT
nsswitch configuration was at fault.
Comment 5 Damien Miller 2022-12-16 08:07:07 AEDT
could you elaborate, in case someone else has the same problem?
Comment 6 Damien Miller 2023-03-17 13:39:16 AEDT
OpenSSH 9.3 has been released. Close resolved bugs