How strict are you about ssh host key checking?

cracauer@

Developer
I recently made the switch to distribute ssh host keys to new machines before the first ssh connection is made.

I have been strict about not knowingly changing ssh host keys when machines get replaced for a long time. So that I never have to ignore a change warning on my own hosts. Of course some machines are under control of people who don't care. Preaching has limited success. I think I recently got a warning from github of all places.

How about you? Don't tell me you've been there since 1996 :)
 
I'm fairly strict with them. I want to know why that host key changed. Because it often indicates a server has been replaced. Or something bad happened. The rule at $DAYJOB is that hostnames are never reused. Host keys should not, and do not, change. It typically means somebody messed up DNS again, because the 'old' hostname's IP did get reused for a new server. DNS at $DAYJOB is a mess, never let a couple of "Minesweeper Consultants & Solitaire Expert"s maintain DNS. Don't even get me started on repeatedly, and continuously, forgetting PTR records exists :rolleyes:

Haven't found a good, proper solution for load-balancing git+ssh though. If you send it to two or more servers you're either constantly confronted with changing host signatures, or you have to put the same host keys on all hosts.
 
I have always worked in more controlled environments. Generally, with automated host building, the host keys get generated, and installed, and become "known", very early in the process. Otherwise the deployment process (which generally relies on ssh) can hickup. For security reasons, they never change. The "automation system" is generally designed to deploy new hosts and retire old ones. Porting host keys to a "replacement" host would be quite unusual. You might do it to avoid disruptions on a failed host with special or unusual functions. e.g. our name servers co-habitated with time servers and were always physical because they were needed before the VM servers in a power-loss recovery. Changing their host keys would have been disruptive.
 
Back
Top