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

[denis bider <[e-mail]>]

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 <[e-mail]>
wrote:

> denis bider <[e-mail]> 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.