openssh bugs - Dec 2022 - [Bug 3510] New: host name lookup quirk

https://bugzilla.mindrot.org/show_bug.cgi?id=3510

            Bug ID: 3510
           Summary: host name lookup quirk
           Product: Portable OpenSSH
           Version: 9.1p1
          Hardware: Other
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P5
         Component: ssh
          Assignee: unassigned-bugs at mindrot.org
          Reporter: thomas at koeller.dyndns.org

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?

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=3510

Damien Miller <djm at mindrot.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |djm at mindrot.org

--- Comment #1 from Damien Miller <djm at mindrot.org> ---
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.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=3510

--- Comment #2 from Thomas Koeller <thomas at koeller.dyndns.org> ---
(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 at 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 at 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.

-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=3510

--- Comment #3 from Thomas Koeller <thomas at koeller.dyndns.org> ---
Created attachment 3642
  --> https://bugzilla.mindrot.org/attachment.cgi?id=3642&action=edit
debug patch

A patch to add debug output showing the problem.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=3510

Thomas Koeller <thomas at koeller.dyndns.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |INVALID

--- Comment #4 from Thomas Koeller <thomas at koeller.dyndns.org> ---
nsswitch configuration was at fault.

-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=3510

--- Comment #5 from Damien Miller <djm at mindrot.org> ---
could you elaborate, in case someone else has the same problem?

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=3510

Damien Miller <djm at mindrot.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |CLOSED

--- Comment #6 from Damien Miller <djm at mindrot.org> ---
OpenSSH 9.3 has been released. Close resolved bugs

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.