>
I do use global requests in both directions as part of the implementation
> of "keepalive%openssh.com@localhost”, but so far I haven’t run into any issues with that.
> That’s disabled by default, though, so perhaps people are only enabling
> with peers that don’t have issues with global requests.
Features that are disabled by default end up being used in a small fraction of connections in practice - I think it's not wrong to guess 1%. Problems with them are further unlikely to be reported because the user assumes the problem they experience is why the feature is disabled anyway.
I think the "hostkeys-00%openssh.com@localhost" mechanism is highly valuable. I would like to see it more widely supported and enabled by default. Last I checked, it was disabled by default, no doubt due to cherished clients that disconnect when they receive it.
I would very much like it to be enabled by default, especially if the client sends the "global-requests-ok" extension. Bitvise SSH Server enables "hostkeys" if the client does this. If not, then we use built-in compatibility rules based on the SSH version string to guess if it's safe to send global requests.
> Does it fail on ANY global request being sent from a server, or is it only
> at certain points that it doesn’t handle these messages correctly?
The bug I was discussing here is that when operating as a server, the Maverick implementation (and therefore servers that use it) has a bug where it crashes if the client sends SSH_MSG_EXT_INFO. There is only one point in the connection where the client is permitted to send SSH_MSG_EXT_INFO. This is immediately after the client's first SSH_MSG_NEWKEYS.
Perhaps you mean to ask about clients which fail upon receiving global requests from SSH servers? These fall mainly into two types:
(1) Clients that disconnect on receipt of ANY global request at any time. These are outright negligent implementations: RFC 4254 requires the global requests to be handled and responded to if "want reply" is true. You can't send an active keep-alive to this kind of client.
(2) Clients that disconnect when in a special state, specifically when expecting a channel open confirmation from the server. These are oversights that were generally fixed in later versions of the software, but people still use earlier versions that had the bug. When dealing with this type of client, it's almost-safe to send an active keep-alive (very low chance of client being in the crash-susceptible state). However, if the server is sending the "hostkeys" global request, that usually happens at the same time as the client is opening its first channel. Therefore, client-side crash becomes very likely.
> Is RFC 8308 the right reference for this option? Are there
> any implementations of this so far other than from Bitvise?
Yes, RFC 8308 is the authoritative spec for the "delay-compression" extension. Bitvise SSH Server and Client can be considered reference implementations. As of right now I haven't been informed of others.
> Also, I’m not familiar with the PuTTY issue around needing a
> second key exchange. Is that documented somewhere?
The race condition is inherent in the zlib%openssh.com@localhost algorithm. PuTTY identified this issue and addressed it with a strategy based on key re-exchange. Bitvise SSH Client also uses the key re-exchange strategy if the server advertises zlib%openssh.com@localhost but not the "delay-compression" extension.
PuTTY project source on this issue:
denis