Call for testing: OpenSSH 8.2

[Damien Miller]

On Wed, 5 Feb 2020, Phil Pennock wrote:

> On 2020-02-05 at 20:39 -0500, Phil Pennock wrote:
> Rediscovered part of why I was doing this: HostKeyAlgorithms is not
> cumulative across rules, instead still being the "first match", even
> when subsequent entries start with "+" or "-".
> 
> IMO the easiest way for people to safely test and discover what works
> still is to have ssh config which looks like:
> 
>   Host *
>     HostKeyAlgorithms -ssh-rsa*,ssh-dss*
> 
>   Host legacy
>     HostKeyAlgorithms +ssh-rsa
> 
> Is changing to support this, as long as subsequent rules start +/-,
> something sufficiently compatible that you'd consider it?

No, sorry - the rules evaluation is enough of a mess without adding
more corner cases where first-match-doesn't-always-win...

> Yes, we can put the "HostKeyAlgorithms -ssh-rsa*,ssh-dss*" at the end of
> the file, but then every host where we explicitly enable ssh-rsa, we
> then have to also re-disable the things we don't intend to re-enable.
> 
> So I contend that the behavior of this is only obvious to OpenSSH
> experts and it will cause me pain helping folks:
> 
>   Host legacy
>     HostKeyAlgorithms +ssh-rsa
>   Host *
>     HostKeyAlgorithms -ssh-rsa*,ssh-dss*
> 
>   # net result: host legacy has ssh-dss* algorithms enabled, plus any
>   # ssh-rsa* glob matches beyond ssh-rsa itself

I don't think that is correct. Host legacy won't have ssh-dss enabled
because that isn't in the default set of algs to begin with.

That being said, the HostKeyAlgorithms knob is a bit subtle because
it is treated specially already because of its interaction with
known_hosts - by default ssh prefers algorithms in known_hosts to
ones that aren't. If the user overrides HostKeyAlgorithms then this
preference order is lost and the user may be presented with new/changed
host key warnings.

I think I can improve this situation; let me go write a patch :)

-d