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

Awesome!

Yes, the idea of "global-requests-ok" is not to make the client do anything
different. It's to reassure the server that the client won't violate the
spec if the server sends a global request.

The main motivating usage case is so the server can feel at liberty to send
the global request "hostkeys-00-ZT/[email protected]" after user authentication:

https://cvsweb.openbsd.org/src/usr.bin/ssh/PROTOCOL?annotate=HEAD

This is essential functionality which allows clients and servers to change
host keys without requiring administrative intervention at each client
installation.

Without "global-requests-ok", the server needs a database of client version
strings to which it's safe to send the "hostkeys" global request.
Otherwise, it can't send it because a bunch of half-baked clients (I'm
counting 7 in our list) are borked and can't handle receiving a global
request. Or they can handle it usually, but not when they're expecting a
response to a channel open.

Meanwhile I've received more info about the implementation that disconnects
on receiving EXT_INFO from the client. The bug is unfortunately in a widely
used Java SSH library. The information I received suggests it's going to be
fixed, but I'm afraid there are already a fair number of deployed servers
that have the issue.

While I'm wishing things - I would also like the "delay-compression"
extension to be more widely supported because it's the only
delayed-compression mechanism that (1) does not have a race condition by
design (zlib-ZT/[email protected]), and (2) does not require a second key exchange
after user authentication (PuTTY mitigation).

denis


On Sun, Apr 26, 2020 at 12:33 PM Ron Frederick <ronf-vmXfByGZ37geIZ0/[email protected]> wrote:

> Hi Denis,
>
> On Apr 26, 2020, at 5:03 AM, denis bider <[email protected]>
> wrote:
>
> 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.
>
> This happens when we define a general mechanism, but then the most widely
> used implementations only use certain aspects of it. Lots of
> implementations now support EXT_INFO sent by the server because it's needed
> for RSA-SHA2 signatures, but only a handful implementations send EXT_INFO
> by the client.
>
> Bitvise SSH Client sends EXT_INFO if the server supports it. It's free to
> use or test with - but it runs on Windows and lots of people don't want to
> test with that.
>
> It's possible that your implementation has no need for any of the
> extensions that would appear in EXT_INFO from the client. However, if you
> wish for this extensibility to be available in the future, then if your
> client supports EXT_INFO, I would strongly suggest that it sends it.
>
> If you want to send a client-side EXT_INFO that takes minimal effort, I
> suggest:
>
> 1. Ensure that your SSH client can correctly handle SSH_MSG_GLOBAL_REQUEST
> received at any point. Your client should not disconnect when it receives
> this message, or act like it received a channel open failure if it receives
> a global request when it's waiting for a channel open confirmation. These
> are the two most common error modes relating to global requests.
>
> 2. Once you have ensured the above, if the server supports EXT_INFO, send
> a client-side EXT_INFO implementing the extension "global-requests-ok" as
> defined in this draft:
>
> https://tools.ietf.org/html/draft-ssh-global-requests-ok-00
>
> This tells the server that your client properly implements global requests
> so that the server can use them for things like active keep-alives.
>
> Implementing this would take minimal effort and would help ensure that
> client-side EXT_INFO remains an available extension mechanism 10 years down
> the road for SSH.
>
>
> I’ve made this change in the AsyncSSH “develop” branch as commit
> https://github.com/ronf/asyncssh/commit/b87291d, and will roll this into
> the next release. Most of the support was already in place as I already had
> common code for generating and parsing EXT_INFO on both the client and
> server. The changes are as follows:
>
>     - AsyncSSH now advertises that it will accept EXT_INFO from clients
> when acting as a server
>
>     - AsyncSSH will send the global-requests-ok extension when acting as a
> client and talking to a server that supports EXT_INFO from clients
>
> Since AsyncSSH doesn’t actually have any heuristics around disabling the
> use of global requests based on client software/version, it doesn’t
> actually do anything right now when it receives the ‘global-requests-ok’
> extension. However, I confirmed it successfully parses received extensions,
> so it should be easy to process future extensions from the client when this
> is needed.
>
> I also specifically tested this against the Bitvise server (thanks for
> making that available for free for non-commercial use!), and it seems to
> work well.
> --
> Ron Frederick
> ronf-vmXfByGZ37geIZ0/[email protected]
>
>
>
>

_______________________________________________
Curdle mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/curdle