On Mon, 10 Feb 2020, Aham Brahmasmi wrote: > 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. That's not true though - ssh will update known_hosts with new keys already (subject to confirmation) and will automatically add IP addresses it learns for existing hostnames (without confirmation under default conditions). > 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 problem we're trying to solve is being able to move to better cryptography over time. If you learnt a ssh-dss key back in 2002, but the server offers a ssh-ed25519 key in 2020 then we should definitely use the latter. So my plan is to fix the remaining corner cases in UpdateHostkeys and try to enable UpdateHostkeys=yes for cases where the user has not overridden known_hosts after openssh-8.2 has been released. -d _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev@xxxxxxxxxxx https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
