Re: [Savannah-hackers-public] new vcs server ssh host key fingerprint

[Bob Proulx]

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