Re: [ssh] Host key sync - "global-requests-ok" extension
denis bider <[email protected]> Tue, 18 Dec 2018 22:17:21 -0600
| Newsgroups | gmane.ietf.secsh |
|---|---|
| Message-ID | <[email protected]> |
> Do you have a test server up that we can run clients against? We do now: ssh -P 10999 [email protected] This currently runs SSH Server version 8.21 and is set to update automatically when a new version is released. You can connect and follow the instructions in the authentication banner to log in. It was originally set up to test rsa-sha2-256 and rsa-sha2-512, but you can also test "global-requests-ok" with this version. It won't send you host key sync if your client version string is not on the hardcoded whitelist, but it will (or it's supposed to) if you send the "global-requests-ok" extension. denis On 2018-12-18 20:49, Peter Gutmann wrote: > [email protected] <[email protected]> writes: > >> In our 8.xx versions up to 8.19, the SSH Server will unconditionally send >> this global request after successful authentication to inform the client >> of its other host keys. This allows a client to auto-verify those host >> keys, allowing for host key rotation. > Do you have a test server up that we can run clients against? > >> We suspect some users may also be using ancient OpenSSH versions on their >> production servers that cannot be upgraded. This may include versions >> before 3.1, which first supported client-side receipt of global requests. > I ran into one only recently, 3.something, where something was probably 7, > which had an interesting bug: If you connected and sent a > SSH_MSG_KEX_DH_GEX_REQUEST, it returned in invalid keyex signature. If you > sent a SSH_MSG_KEX_DH_GEX_REQUEST_OLD, it worked. 3.7 is from 2003 whereas > RFC 4419 is from 2006, postdating the implementation. My guess is that it > computes the signature over some form of the _REQUEST_OLD information rather > than the newer _REQUEST info, but I haven't bothered looking at the code. > > While I'm on the subject of OpenSSH, why the *&(*)&() does it disable all > the mandatory-to-implement symmetric ciphers in its default configuration > post 7.x? It can't really be called an implementation of the SSH spec if > no MTI ciphers are supported in its out-of-the-box config. > > Peter. > >