[Bug 3567] New: CanonicalizeHostname yes doesn't canonicalize the Hostname with ProxyJump none

[bugzilla-daemon at mindrot.org]

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

            Bug ID: 3567
           Summary: CanonicalizeHostname yes doesn't canonicalize the
                    Hostname with ProxyJump none
           Product: Portable OpenSSH
           Version: 9.3p1
          Hardware: All
                OS: Linux
            Status: NEW
          Severity: enhancement
          Priority: P5
         Component: ssh
          Assignee: unassigned-bugs at mindrot.org
          Reporter: mindrot-bugzilla at herkulessi.de

Basically the Summary.
When CanonicalizeHostname is set to yes and ProxyJump is explicitly
disabled via setting it to none, no hostname canonicalisation is
performed.
According to the Documentation, "If set to yes then, for connections
that do not use a ProxyCommand or ProxyJump, ssh(1) will attempt to
canonicalize the hostname" and "A value of none disables the use of a
ProxyJump host."

If you do actually set ProxyJump to none, ssh still asks the system
resolver to resolve the short name, but not the canonicalized one and
exits with "ssh: Could not resolve hostname <short hostname>: Name or
service not known"

ProxyCommand works as expected (as in "if set to none hostname
canonicalisation is performed").
"CanonicalizeHostname always" also works as expected.

Since I only have access to Linux machines, I only tested it on Linux,
but it affects at least x86_64 (AMD64) and aarch64 (ARM64) on both the
current OpenSSH version shipped by Debian (OpenSSH_8.4p1
Debian-5+deb11u1, OpenSSL 1.1.1n  15 Mar 2022) as well as the latest
release built from the official source tarball (OpenSSH_9.3p1, OpenSSL
3.0.8 7 Feb 2023)

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