Re: [Curdle] Client-side SSH_MSG_EXT_INFO: Use it or lose it principle!

Unfortunately, the specific server implementations that use the Java library may use an unrelated version string.

Unless I get new information, our next SSH Client version (8.42) will disable sending of SSH_MSG_EXT_INFO if the version string contains:

CrushFTPSSHD

J2SSH_Maverick

However, I suspect the are more and/or the above might not be accurate. At this point I'm pretty sure I've been receiving reports of this issue for a while, but never figured it out because they tend to be ad hoc servers that I couldn't connect to, and I never heard back from users with any server-side diagnostics. This is the first time a user pointed me to a server with which I could test.

denis

On Mon, Apr 27, 2020 at 12:37 AM Peter Gutmann <pgut001%cs.auckland.ac.nz@localhost> wrote:

denis bider <denisbider.ietf%gmail.com@localhost> writes:

>it has come to my attention that at least one SSH server implementation (a)
>advertises support for SSH_MSG_EXT_INFO as defined in RFC 8308, and (b)
>disconnects on actual receipt of an EXT_INFO message from the client.

Not wanting to do a public name-and-shame on this, but could you share the ID
string needed to fingerprint this server? Looks like a lot of implementations
will need to be able to deal with this...

>This happens when we define a general mechanism, but then the most widely
>used implementations only use certain aspects of it.

That's a more specific version of "an implementation is fully SSH standards-
compliant when it can connect to OpenSSH (client) or Putty can connect to it
(server)". Those two are the universal benchmark for SSH implementations, for
better or for worse. TLS dealt with this to some extent by adding a mechanism
bacronym'd as GREASE for sending random information in extensions to detect
implementations that broke on them, perhaps something similar could be done
for SSH.

Peer.