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

[Ron Frederick <[e-mail]>]

On Apr 26, 2020, at 10:33 PM, denis bider <[e-mail]> wrote:
> 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 "[e-mail] <mailto:[e-mail]>" after user authentication:
> 
> https://cvsweb.openbsd.org/src/usr.bin/ssh/PROTOCOL?annotate=HEAD <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.

Yeah, understood. So far, I haven’t implemented “hostkeys" support in AsyncSSH. I may do that at some point, but I’ll probably just do the new host key validation in AsyncSSH but leave it up to the application code to decide if it actually wants to update the list of known_hosts or not (and if so, where). Right now, AsyncSSH will read from ~/.ssh/known_hosts by default if you don’t specify another source, but it never actually modifies that file. In fact, most of the ways of specifying known_hosts in AsyncSSH are focused on providing the set of hosts dynamically, or even allowing applications to provide their own logic to determine whether a specific host key should be trusted or not for a given host/port, so I’d want to do the same thing with reporting new host keys a server advertises.

Since I don’t have this support yet, I haven’t needed to worry about which clients can properly handle global requests or not. I do use global requests in both directions as part of the implementation of "[e-mail] <mailto:[e-mail]>”, 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.


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

Interesting. 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?


> 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 ([e-mail] <mailto:[e-mail]>), and (2) does not require a second key exchange after user authentication (PuTTY mitigation).

Is RFC 8308 the right reference for this option? Are there any implementations of this so far other than from Bitvise?

Also, I’m not familiar with the PuTTY issue around needing a second key exchange. Is that documented somewhere?
-- 
Ron Frederick
[e-mail]