Call for testing: OpenSSH 8.2

[Aham Brahmasmi]

> Sent: Thursday, February 06, 2020 at 5:29 AM
> From: "Damien Miller" <djm at mindrot.org>
> To: "Phil Pennock" <phil.pennock at globnix.org>
> Cc: openssh-unix-dev at mindrot.org
> Subject: Re: Call for testing: OpenSSH 8.2
>
> On Wed, 5 Feb 2020, Phil Pennock wrote:
>
> > On 2020-02-06 at 10:29 +1100, Damien Miller wrote:
> > >  * sshd(8): allow the UpdateHostKeys feature to function when
> > >    multiple known_hosts files are in use. When updating host keys,
> > >    ssh will now search subsequent known_hosts files, but will add
> > >    updated host keys to the first specified file only. bz2738
> >
> > In testing this, when the impact is to _remove_ a known_hosts entry then
> > all the existing entries are deleted from the subsequent files, and the
> > remaining entries are added to the first file.
> >
> > I initially assumed, on reading the email, that the logic was to not
> > assume that subsequent files are writable, but it seems that's not it.
> >
> > Is this just a corner case that wasn't considered?
>
> No, that's pretty much the intended behaviour. Tracking which entries go
> where and trying to match it while making updates is just too fiddly.
>
> I hope to automatically enable UpdateHostKeys in a future release when
> the user is using the default UserKnownHostsFiles, so if people are
> using something custom then they can choose themselves whether the above
> behaviour is something they can live with.

Namaste Damien,

Firstly, thank you for switching back the default of UpdateHostKeys to
no.

Secondly, I (n=1) think that UpdateHostKeys can be set to yes (or ask)
by volks who wish to perform key rotation using ssh.

However, switching it to yes (or ask) for everyone in future may not be
desirable. I say this because I think that the ssh client should only
read from the configuration. Updates to known_hosts could happen outside
the ssh system.

I am aware of the trust-on-first-use scenario where the client first
gets user confirmation about the server key and then writes it to
known_hosts.

But I am unable to understand why it should also switch the underlying
host keys by default (in future). I may be wrong here, but in my mind,
that seems like auto-magic.

> The previous behaviour was quite broken: AFAIK it wouldn't even search
> beyond the first known_hosts file when looking for keys.
>
> -d

Finally, could the "sk" keys be documented in a way that suggests "sk"
stands for "(hardware) security key", which in itself is not related to
"S/KEY"?

I say this because it is difficult to understand from the manpage:
1) what is the difference (if any) between ed25519 and ed25519_sk keys.
2) which keys to use when.

I know I am unable to frame the above properly, but it is difficult to
equate "authenticator-hosted" to something like a "use the _sk variant
when you have a (hardware) security key".

Dhanyavaad,
ab
---------|---------|---------|---------|---------|---------|---------|--