UpdateHostkeys now enabled by default

Christoph Anton Mitterer calestyo at scientia.net
Sun Oct 4 14:35:46 AEDT 2020


On Sun, 2020-10-04 at 14:02 +1100, Damien Miller wrote:
> This is strictly no worse than continuing to use the old key, so I
> don't
> consider it a problem.

Well but in reality it will lead to people never again replace their
key by proper means.


> How is this different to the status quo? If you don't clean up keys
> after
> a compromise then you have a problem. Anyone doing this already has
> to
> be prepared to deal with multiple keys being known for a host. The
> tooling
> support for doing this (ssh-keygen -R) works identically regardless
> of
> the number of keys.

Well the big difference is IMO:
AFIAU this feature distributes the newer server keys to clients right? 

So even if the compromise is detected on the server side (and properly
cleaned up) the may be countless of clients (which you can never reach
all) who still have the compromised keys and may subsequently be
vulnerable to MitM, since they'd still trust that the key authenticates
server foo.bar.

Same scenario obviously if the compromise is never detected but just
used to get keys for MitM servers to clients... and afterwards removing
any trace/backdoor from the server.


Cheers,
Chris.



More information about the openssh-unix-dev mailing list