On Fri, Sep 18, 2009 at 11:25 AM, Males, Jess wrote: > I didn't appreciate the flexibility of known_hosts or sshd_known_hosts until following up on > Kurth's response; so thanks for that. Yes, that was a good link. In particular it appears that at least part of #4 (and the important part at that!) may already be implemented. I should have read a more recent version of the openssh man pages before posting (but it's too late now!) but it appears that one key can have multiple aliases associated with it and ssh will no longer match just the first one but will keep looking through the whole list. I just ran another test, being much more careful about my cut and paste this time, and it seems to work now (whoops!). Here's what my sample known_hosts looks like: <host1name>,<host1_IP>,<app1name>,<app1_IP>,<app2name>,<app2_IP> <host1 key> <host2name>,<host2_IP>,<app1name>,<app1_IP>,<app2name>,<app2_IP> <host2 key> > However, personally, I lean toward #1. When reading #1, it seems to suggest having one > key for the whole site. This I wouldn't do. Rather, whenever adding a second node and creating a > cluster, just copy the keys from node one to node two. Each cluster will have unique keys. All > applications on a cluster will have the same key. Doing this preserves notifications for possible > MitM attacks, but doesn't require coordinated updates across the entire infrastructure. Since we frequently have hosts that move between clusters, I figured that I'd probably have to keep the keys the same for all hosts. While I could change the key when it changes clusters, that will trigger the ol' MitM warning... > All that said, some follow-up considerations: > > If all your users are on relatively few systems, then implementing a client side sshd_known_hosts is more > straight-forward. It would not require users to understand or mess with known_hosts themselves. > Similarly, if you have NFS /home drives or CIFS windows profiles where the network homogenizes the > known_hosts experience, then this solution gains favor. Sadly, most of what I have is a hodge-podge across many systems. However, my users are more savvy than in many cases and can mess with known_hosts when necessary. I can also hit about 80% of the clients using centralized ssh_known_hosts files. > Speaking against updating known_hosts are differing clients on differing platforms. How does putty > handle known_hosts? You'll love this-- it stores them in the Windows registry. http://www.chiark.greenend.org.uk/~sgtatham/putty/faq.html#faq-hostkeys > What are your current procedures for migrating applications? If an application move requires > a server change, even if the IP is moved, what do customers do when the key changes? They usually either panic or remove any key that generates a MitM warning... ever. Again, not highly desirable behavior in either case. :-) I'm now leaning towards using scripted host key scans to build some global ssh_known_hosts files with the cluster IPs listed on the same lines as the host keys. This will require the script to collect some cluster information so it won't be quite as simple as the four-liners floating around. :-) -- Steve
