savannah-hackers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[savannah-help-public] [sr #109343] ssh known_hosts conflicts svn and gi


From: Bob Proulx
Subject: [savannah-help-public] [sr #109343] ssh known_hosts conflicts svn and git
Date: Mon, 26 Jun 2017 20:36:52 -0400 (EDT)
User-agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/57.0.2987.98 Safari/537.36

Update of sr #109343 (project administration):

             Open/Closed:                    Open => Closed                 

    _______________________________________________________

Follow-up Comment #1:

It appears your ssh client is configured to ignore an existing RSA type host
key if a newer ECDSA type key is available.  That isn't the way my ssh client
works.  On my system when I have an existing RSA host key in the known hosts
file then that is the host key it checks against when connecting to a server
with a matching key. In your case this does not appear to be happening.

In which case I suggest deleting ALL of your old host keys from your
known_hosts file and fetching the new ECDSA keys.

If your ssh client is hashing the host names then this will be somewhat
difficult since there isn't a way to know what keys are stored there.  You
could then only delete either all of them, which loses the security of
trust-on-first-use (TOFU) other previously seen hosts. Or you can remove them
one at a time as they are seen. If your ssh client is not hashing host names
in the known_hosts file then I suggest editing that file and deleting all of
your savannah.gnu.org names including all of the possible aliases for those
names.  Aliases include nongn.org and sv.gnu.org and sv.nongnu.org.

The host keys for verifying fingerprints are listed here:
https://savannah.gnu.org/maintenance/SshAccess/

Background: Back in December 2016 we upgraded servers for the version control
system and then started moving services one at a time from the old machine to
the new machine.  The previous RSA host key was preserved verbatim.  This
prevented people from seeing any host key changes across this migration.

However the new server did have a newer, stronger, ECDSA key.  If your ssh
client is new enough it will prefer this key when it stores the host key in
the known_hosts file in the TOFU (trust-on-first-use) policy.

However the old server key is a small 1024 bit key.  At some point we will
want/need to generate a new, larger, stronger key.  Hopefully by that time
most people won't care because they will have migrated naturally through to
the newer, stronger ECDSA key. If we delay long enough then regenerating a
longer, stronger, RSA key will not affect most people.

It is fine to file tickets for these types of things but since this was more
of a question and answer type of thing let me suggest emailing to the
savannah-hackers-public AT gnu.org mailing list instead.  It is much easier to
deal with discussion like this on the mailing list rather than in a bug
ticket.  (I really hate editing email in a web browser. It is so much easier
in a real editor.)


    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/support/?109343>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/




reply via email to

[Prev in Thread] Current Thread [Next in Thread]