openssh bugs - May 2025 - [Bug 3824] New: ssh -Q should also accept a remote hostname to query

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

            Bug ID: 3824
           Summary: ssh -Q should also accept a remote hostname to query
           Product: Portable OpenSSH
           Version: 10.0p2
          Hardware: amd64
                OS: Linux
            Status: NEW
          Severity: enhancement
          Priority: P5
         Component: ssh
          Assignee: unassigned-bugs at mindrot.org
          Reporter: martin-eric.racine at iki.fi

In its current form, 'ssh -Q feature' reports what the SSH client
supports. It would be desirable for the command to accept an optional
hostname to be able to query the features of a remote host e.g. 'ssh -Q
kex mailhost.internal' as well.

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

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

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 wouldn't be the same thing unfortunately. It would be possible
(given a fairly significant amount of effort) to query some of the
option that the remote side has *enabled* but that's more like what
"ssh -G [host]" does rather than what "ssh -Q [option]"
does.

"ssh -Q" shows what the client supports, not what the client has
enabled.

-- 
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=3824

--- Comment #2 from Martin-?ric RACINE <martin-eric.racine at iki.fi> ---
Kinda like "ssh -G" indeed but for the remote host, rather than for
how
the local host is configured to interact with the remote host.

I'm asking, because I need to check why authentication suddenly fails
for a host and the information provided by -vvv is too abstract. I
suspect that the key exchange or host key algorithms might have changed
on the remote, and I was hoping for a command option that prints only
that i.e. something like "ssh -Q" but able to query the remote, rather
than what the local "ssh" binary supports.

-- 
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=3824

Darren Tucker <dtucker at dtucker.net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dtucker at dtucker.net

--- Comment #3 from Darren Tucker <dtucker at dtucker.net> ---
(In reply to Martin-?ric RACINE from comment #2)
[...]
> I'm asking, because I need to check why authentication suddenly
> fails for a host and the information provided by -vvv is too
> abstract. I suspect that the key exchange or host key algorithms
> might have changed on the remote,
Failure to negotiate key exchange or hostkey algorithms should be
fairly clear:

$ /usr/bin/ssh -o hostkeyalgorithms=ssh-dss localhost
Unable to negotiate with 127.0.0.1 port 22: no matching host key type
found. Their offer:
rsa-sha2-512,rsa-sha2-256,ecdsa-sha2-nistp256,ssh-ed25519

$ /usr/bin/ssh -o kexalgorithms=diffie-hellman-group1-sha1 localhost
Unable to negotiate with 127.0.0.1 port 22: no matching key exchange
method found. Their offer:
mlkem768x25519-sha256,sntrup761x25519-sha512,sntrup761x25519-sha512 at
openssh.com,curve25519-sha256,curve25519-sha256 at
libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,ext-info-s,kex-strict-s-v00
at openssh.com
> and I was hoping for a command
> option that prints only that i.e. something like "ssh -Q" but
able
> to query the remote, rather than what the local "ssh" binary
> supports.
Mismatches in PubkeyAcceptedAlgorithms on the server side will be less
obvious to the client.  As a general rule sshd won't disclose the
reasons for authentication failures to unauthenticated connections, so
generally this kind of thing will only be available in the server-side
debugging.

-- 
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=3824

Darren Tucker <dtucker at dtucker.net> changed:

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

-- 
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.