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

[Ron Frederick <ronf%timeheart.net@localhost>]

Hi Denis,

On Apr 26, 2020, at 5:03 AM, denis bider <denisbider.ietf%gmail.com@localhost> 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%timeheart.net@localhost