3 ms·

This seems like it could be solved easily enough. Just add a feature to ssh for rotating keys securely. Each new key issued by the server could be signed by the

This seems like it could be solved easily enough. Just add a feature to ssh for rotating keys securely. Each new key issued by the server could be signed by the previous (already trusted) key. If the chain is ever broken and an unsigned key is issued (after initial setup) then ssh could simply bail out and refuse to connect with a scary message warning you to contact the administrators, as it does now every time keys change. The problem right now is that if you rotate keys frequently your users get desensitized to the scary message and end up following the drill to delete the current key and connect with the new one. With a secure signing chain for rotating keys you avoid this problem.

pxc 2y ago
You can set up SSH to use certs and then add the server cert to your known_hosts file instead of the individual host keys. Then when the host keys rotate, all is well as long as the new host keys are signed by the same cert.
MaxBarraclough 2y ago
> Each new key issued by the server could be signed by the previous (already trusted) key That doesn't work if the host's private key is leaked, or may have been leaked, e.g. [0][1]. The current solution seems ok; we go through another channel to confirm the new key, likely either receiving an email about the key change, or using the web. [0] https://github.blog/news-insights/company-news/we-updated-our-rsa-ssh-host-key/ https://github.blog/news-insights/company-news/we-updated-ou... [1] https://bitbucket.org/blog/ssh-host-key-changes https://bitbucket.org/blog/ssh-host-key-changes