Re: [savannah-help-public] [sr #109343] ssh known_hosts conflicts svn and git

[Bob Proulx]

Pavel Kharitonov wrote:
> But CVS for web pages still uses the RSA key (?)
> 
> When I work with Git and CVS repositories, it issues warnings about different
> keys.

I see you opened the ticket again.  Therefore you think there is still
a problem yet to be resolved.  But I think the only problem is one on
your ssh client and there isn't anything that Savannah can do about
it.

Here are the options as I see them.  This is for discussion in case
anyone else sees anything different.

* vcs0 has a copy of the old vcs RSA and dsa keys copied into place.
This was so that ssh clients that check host RSA keys (hopefully none
are still using DSA keys but can't tell) will check them and see that
there is no host change.  This is the way it works for me on Debian
OldStable, Stable, and Unstable.  It appears that other systems
operate differently.

* vcs0 has new ECDSA keys created for the new host.  If one both
doesn't have an existing key (possibly removing it) and has a new
enough client then the client and server will exchange ECDSA keys.
These keys are new with the new server and the strongest keys.

* The old vcs RSA and DSA keys are only 1024 bits.  That is too short
these days.  We really should invalidate them and force everyone to
upgrade to the stronger keys.  But it will create a big thrash because
almost all users will be affected.

* Caching of host keys is called TOFU, Trust On First Use.  The first
time you see a host key there is no previous history.  You trust it on
first use of it.  And then it is cached and trusted after that time.
It isn't a great security model because if there is a man in the
middle on the first use then you simply trust and cache the MITM keys
rather than the intended server keys.

==== So what can be done?

* You could configure your client such that it will continue to use
and check the old RSA keys.  Apparently your client is warning about
this.  This may be something that has been added in newer ssh
clients.  I don't know.  I haven't investigated it.  Back in December
when last I looked into this issue for the migration ssh clients I
tested were using the RSA keys if those had previously been cached.
No special configuration was needed.  I think something must have
changed in the clients to be making this warning noise now.

* We could decide to stop using the newer stronger ECDSA keys and
configure them out of sshd.  This would be a terrible action because
it would reduce the security for those people who are using it.  This
is too wrong to contemplate further.

* We can decide to continue on as things are now.  Keep using ECDSA
keys for new clients that Trust On First Use them.  People who see
warnings can remove the keys from the known_hosts and then cache the
stronger keys.

====

Soo...  What do you propose?

We could decide to invalidate the old 1024 RSA host keys and force
everyone into this problem now.  Invalidating the old 1024 bit RSA
keys would force the issue upon everyone all at once.  It would be
similarly to smacking everyone with a cast iron frying pan.  I have
been putting off doing this because it is so disruptive to everyone.
It should be done at some point anyway since they are the smaller
1024-bit host keys.  At the least remove the weak DSA keys but at one
time Microsoft Windows clients could only use the DSA keys and I
believe that is why they are still in the list.  And then everyone in
the community can help each other out with instructions on how to
remove all of the keys from the known_hosts file.  Misery loves
company.

Bob