There are some cases when server may have few server keys, each of those is valid. Examples: 1) server booting from golden image. Golden image has 'build-in' host ssh key which is changed after system configuration management application set up proper ssh key for server. 2) server may reboot between two different operating systems, each using own host ssh key. 3) DynDNS-related shuffling between few servers (at given time server is occupying on of the few known IPs, and is causing false alerts if that IP was known to be used by previous server). Right now there is no way to say ssh client 'both keys are valid for a given server', which cause users one of the following actions: 1. Use set of ssh options to prevent key learning 2. Use ssh-keygen -R to remove old key and confirm new one on the next connect, repeat on each host ssh key change (e.g. reboot to different OS). Both of those actions loosen attention on 'spoofed ssh keys' alert and therefore significantly endanger overall security of ssh-related workflow. Malicious agent may use those alerts to persuade personnel mistakenly trusting wrong key (due to repeated and often false positive alerts, actual and valid alert would have been ignored and processed as false positive). Proposition: permit multiple host keys for a given server name and/or IP address.
(In reply to George Shuklin from comment #0) [...] > 1) server booting from golden image. Golden image has 'build-in' > host ssh key which is changed after system configuration management > application set up proper ssh key for server. The down side is that anyone with access to the golden image could MITM connections. > 2) server may reboot between two different operating systems, each > using own host ssh key. Copy one set of host keys and use it on both OSes. > 3) DynDNS-related shuffling between few servers (at given time > server is occupying on of the few known IPs, and is causing false > alerts if that IP was known to be used by previous server). Use CheckHostIP=no in the config for such hosts. [...] > Proposition: permit multiple host keys for a given server name > and/or IP address. Anyway, that's already possible but for different host key types. You could set HostKeyAlgorithms=ssh-rsa for one host and HostKeyAlgorithms=ssh-ed25519 on the other. I think having multiple keys of the same type valid for one host is a risk, though.
(In reply to George Shuklin from comment #0): > 1) server booting from golden image. Golden image has 'build-in' > host ssh key which is changed after system configuration management > application set up proper ssh key for server. Use "ssh -o HostKeyAlias=golden-image" when connecting to the newly imaged system until the keys are changed. This also protects against trivial MITM at that point (not from anyone with access to the image though).
(In reply to Darren Tucker from comment #1) > (In reply to George Shuklin from comment #0) > [...] > > 1) server booting from golden image. Golden image has 'build-in' > > host ssh key which is changed after system configuration management > > application set up proper ssh key for server. > > The down side is that anyone with access to the golden image could > MITM connections. Yes, there is a risk, but it's less than 'use -R every time'. Adding additional keys is not default configuration, so unexpected users wouldn't be affected. > > Proposition: permit multiple host keys for a given server name > > and/or IP address. > > Anyway, that's already possible but for different host key types. > You could set HostKeyAlgorithms=ssh-rsa for one host and > HostKeyAlgorithms=ssh-ed25519 on the other. > > I think having multiple keys of the same type valid for one host is > a risk, though. Is any reason why to have two different keys with different algo is OK, but to have two different keys with same algo is not OK?
(In reply to George Shuklin from comment #3) [...] > Yes, there is a risk, but it's less than 'use -R every time'. Adding > additional keys is not default configuration, so unexpected users > wouldn't be affected. Some users will do insecure things but that doesn't mean we should weaken the host key checking for those who don't. > Is any reason why to have two different keys with different algo is > OK, but to have two different keys with same algo is not OK? It's an artefact of the way the host key matching works, not a deliberate feature. In recent versions of OpenSSH the server will inform the client of all of its host keys (via the "hostkeys-00@openssh.com" extension) and if the client wants to (via UpdateHostKeys) it will update the known_hosts file.
I agree with Darren here - this seems like a niche-case solution that is fairly likely to trap common-case users, sorry. BTW, host certificates may present a possible solution to your problem.
closing resolved bugs as of 8.6p1 release