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 _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev@xxxxxxxxxxx https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
