On Sun, 4 Oct 2020, Christoph Anton Mitterer wrote:> 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.Well, first I disagree that this method is improper. The existence of UpdateHostkeys doesn't stop people hard-rotating their keys if that's what they prefer.> > 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.Again, how is this different to the status quo? If a server has been compromised then its host key(s) should be considered compromised too and should be cleaned up. This is true regardless of the existence of UpdateHostkeys. -d
Hi Damien, UpdateHostkeys is an interesting feature. I hope you plan to document it somewhat better in the ssh_config.5 file than is currently present? My reading of the documentation is that it is ambiguous as to the following: if StrictHostKeyChecking=yes and UpdateHostkeys=yes which option wins? (My vote is that StrictHostKeyChecking=yes wins every time.) If the hostkey that matches is found in GlobalKnownHostsFile, then I hope that the UpdateHostKeys is NOT used to update the UserKnownHostsFile ... My vote is to assume that the GlobalKnownHostsFile is being properly managed and maintained for the listed hosts and UpdateHostKeys would be ignored in this case. I am unclear what happens with UpdateHostKeys when the key is found via DNS SSHFP and the use of VerifyHostKeyDNS settings. My vote is that if the key is found in DNS SSHFP records, the UpdateHostKeys does NOT get used to add to the UserKnownHostsFile. How do CheckHostIP=yes and UpdateHostKeys play together? It is not clear to me if the HostIP fingerprints AND the Hostname fingerprint recards are BOTH to be added via the UpdateHostKeys directive or not. I believe it would be wise to be explicit with regards to these impacts to the UpdateHostKeys option as described in the man page. Thank you for your considerating of these questions. Be safe, stay healthy, -- Mark
On Sat, 3 Oct 2020, Mark D. Baushke wrote:> Hi Damien, > > UpdateHostkeys is an interesting feature. I hope you plan to document it > somewhat better in the ssh_config.5 file than is currently present? > > My reading of the documentation is that it is ambiguous as to the > following: > > if StrictHostKeyChecking=yes and UpdateHostkeys=yes > which option wins? > > (My vote is that StrictHostKeyChecking=yes wins every time.)They are almost completely separate: StrictHostKeyChecking controls the circumstances under which a hostkey is accepted. UpdateHostkeys controls whether to try to learn additional hostkeys for a host with an already trusted host key. The small point of interaction is when StrictHostKeyChecking=no and the user elects to continue past a changed hostkey. I'll double-check to make sure that UpdateHostkeys gets turned off along the other options that are disabled in this case.> If the hostkey that matches is found in GlobalKnownHostsFile, then I > hope that the UpdateHostKeys is NOT used to update the > UserKnownHostsFile ... > > My vote is to assume that the GlobalKnownHostsFile is being properly > managed and maintained for the listed hosts and UpdateHostKeys would > be ignored in this case.Good point. I'll implement this.> I am unclear what happens with UpdateHostKeys when the key is found > via DNS SSHFP and the use of VerifyHostKeyDNS settings. > > My vote is that if the key is found in DNS SSHFP records, the > UpdateHostKeys does NOT get used to add to the UserKnownHostsFile.Another good point. I'll do this too :)> How do CheckHostIP=yes and UpdateHostKeys play together? > It is not clear to me if the HostIP fingerprints AND the Hostname > fingerprint recards are BOTH to be added via the UpdateHostKeys > directive or not.They should play just fine (modulo bugs like the one Matthieu reported). Keys learned by UpdateHostKeys should behave exactly like ones learned by TOFU with respect to CheckHostIP and HashKnownHosts. -d