Bug 3510

Summary:

host name lookup quirk

Product:

Portable OpenSSH

Reporter:

Thomas Koeller <thomas>

Component:

ssh

Assignee:

Assigned to nobody <unassigned-bugs>

Status:

CLOSED INVALID

Severity:

normal

CC:

djm

Priority:

Version:

9.1p1

Hardware:

Other

OS:

Linux

Attachments:

Description	Flags
debug patch	none

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