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

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