Mike Miller wrote: > Bob Proulx wrote: > > Because of the flexibility to be able to switch back and forth while > > working on the various version control systems we went with option 3 > > described there. (And we have used that capability a few times > > already.) I cloned the old host keys onto the new system. Therefore > > if you have the hostnames in your known_hosts for the previous system > > you should not get a key change warning using the same hostname on the > > new system. If your ssh warns on IP address changes that will be the > > only difference. > > Maybe, the exact message was > > Warning: the RSA host key for 'hg.sv.gnu.org' differs from the key for the > IP > address '208.118.235.201'
Hmm... This feels like something where the smallest of details can cause a lot of ... I usually say problems but in this case I will say noise. And there are a lot of different ways to configure every possible part of the system including ssh. It just isn't possible to avoid tripping over one snag or another. 208.118.235.201 is the IP address of the new server. 208.118.235.72 is the IP address of the old server. Using crytographic keys to verify host systems is much stronger than using IP addresses. Therefore personally I don't track IP addresses and I personally configure ssh to track host keys only. I know that I am in the minority since the default is to do both. But there is no way to help it as the IP address must change. All we can do is try to minimize the amount of thrash by limiting the changes as much as possible. When I test switching from the previous IP address to the new IP address using default ssh options I see behavior like this: Perform action using ssh adds this known_hosts entry: hg.sv.gnu.org,208.118.235.72 ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAIEAzFQovi+67xa+wymRz9u3plx0ntQnELBoNU4SCl3RkwSFZkrZsRTC0fTpOKatQNs1r/BLFoVt21oVFwIXVevGQwB+Lf0Z+5w9qwVAQNu/YUAFHBPTqBze4wYK/gSWqQOLoj7rOhZk0xtAS6USqcfKdzMdRWgeuZ550P6gSzEHfv0= Switch IP address of hg.sv.gnu.org to new server 208.118.235.201. Perform another ssh action. Warning: Permanently added the RSA host key for IP address '208.118.235.201' to the list of known hosts. Now the known_hosts entries looks like this (intentionally using HashKnownHosts=no so as to show the entries, otherwise we would just have the hash): hg.sv.gnu.org,208.118.235.72 ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAIEAzFQovi+67xa+wymRz9u3plx0ntQnELBoNU4SCl3RkwSFZkrZsRTC0fTpOKatQNs1r/BLFoVt21oVFwIXVevGQwB+Lf0Z+5w9qwVAQNu/YUAFHBPTqBze4wYK/gSWqQOLoj7rOhZk0xtAS6USqcfKdzMdRWgeuZ550P6gSzEHfv0= 208.118.235.201 ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAIEAzFQovi+67xa+wymRz9u3plx0ntQnELBoNU4SCl3RkwSFZkrZsRTC0fTpOKatQNs1r/BLFoVt21oVFwIXVevGQwB+Lf0Z+5w9qwVAQNu/YUAFHBPTqBze4wYK/gSWqQOLoj7rOhZk0xtAS6USqcfKdzMdRWgeuZ550P6gSzEHfv0= Switching the IP address back to the previous 208.118.235.72 causes no key warnings as the hg.sv.gnu.org,208.118.235.72 is a consistent state for that action. Therefore my expectation is that others will see the same behavior. However know there are a large number of configuration combinations available in the wild and it is impossible to handle all of them. Just because I had that expectation doesn't mean I expect that to actually happen for everyone. :-) [[ In my personal case I include CheckHostIP=no which prevents storing the IP address. In my case I get one entry for both. hg.sv.gnu.org ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAIEAzFQovi+67xa+wymRz9u3plx0ntQnELBoNU4SCl3RkwSFZkrZsRTC0fTpOKatQNs1r/BLFoVt21oVFwIXVevGQwB+Lf0Z+5w9qwVAQNu/YUAFHBPTqBze4wYK/gSWqQOLoj7rOhZk0xtAS6USqcfKdzMdRWgeuZ550P6gSzEHfv0= I mark this as an aside since my case is probably an unusual low percentage use case. ]] > My reflexive response was to run `ssh-keygen -R hg.sv.gnu.org`, log in > again, and verify the fingerprint. Well... Just removing the old entry and trying again seems to defeat the anti-MITM checks here. And once the entry has been deleted if it is a MITM attack then you have lost the original key to verify the previously known real host. Let's say I am on a laptop at an airport and I really am being attacked by having a MITM try to spoof things. Let's say I stop doing anything at that point and get on the airplane and travel. I maintain my known_hosts with the previously verified keys. I travel elsewhere. I connect again. If I have avoided the attack then the verified connectivity now works without changing anything. Of course we announced that things were changing specifically so that people wouldn't freak out and would know that things are going to have a new IP address. So I know you were expecting it. Therefore *my* reflexive reaction would be to remove the IP address from the known_hosts entry and try again using only host keys and not IP addresses. > My ssh client only displays the sha256 fingerprint for the ECDSA Mine still only displays the md5 fingerprint. > key, and that's how we ended up here :) Good enough! :-) > Warning: the RSA host key for 'hg.sv.gnu.org' differs from the key for the > IP > address '208.118.235.201' Since your behavior differs from my testing with the default options (and with my CheckHostIP=no case) I can only assume that once again the smallest of details is causing a lot of, in this case, noise. I don't know why your case is different. Perhaps you can debug your case to root cause? It needs your access to your ssh version, config and known_hosts state. > I've just cloned the wiki repo, I'll try to help if I can. That's awesome! :-) Bob
signature.asc
Description: PGP signature
