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
