Update of sr#110996 (group administration):

             Assigned to:                    None => rwp                    
             Open/Closed:                    Open => Closed                 

    _______________________________________________________

Follow-up Comment #2:

Are you running Arch or Parabola and if so have you recently updated
to a newer version of ssh?  This is me guessing and gathering
background information.

The problem is most likely that the ssh client on your system is
rejecting the legacy 1024-bit rsa host key being presented by
fencepost and not trying either of the other two presented newer host
keys which are stronger.

I suggest fixing this with the end goal of upgrading to using ED25519
keys instead of the previous RSA keys.  ED25519 keys are stronger,
more compact, and use different algorithms which causes ssh to avoid
looking at the RSA key at all.  It's one of those win-win upgrades.

However it's a circular dependency.  You can't change your key in the
~/.ssh/authorized_keys file without being able to log in and you can't
log in.  Therefore the first step is to provide a temporary workaround
for the host key rejection so that you can log in.  Then upgrade your
identity keys to ed25519 keys.  At that point you should be good to
go.

Note though that you have filed your bug ticket against Savannah
fencepost is not part of the Savannah software forge and we here don't
have admin access to fencepost.  Meaning I think what I describe is
the problem but if this does not work then you will have to file a
ticket with FSF sysadmin who controls and admins the fencepost
machine.

In the meantime let's see if we can help.  As a temporary workaround I
think this next will force your ssh client to acept the key but to
upgrade to the strongest ED25519 key and store it into the known_hosts
file.

Try this:


    ssh -o'UpdateHostKeys=yes' -o'HostkeyAlgorithms=+ssh-rsa'
-o'PubkeyAcceptedAlgorithms=+ssh-rsa' fencepost.gnu.org
    ...
    ED25519 key fingerprint is
SHA256:czIgr7VZvWzBireMUixS42C5dnq/H5DaRAbTD2Kgqpw.
    ...


If that works, allows you to accept the new key, and log into
fencepost, then on your client create an ed25519 key, and upgrade the
public key in your fencepost ~/.ssh/authorized_keys file to the
contents of the newly created id_ed25519.pub file on your client.
This is described somewhat more here for Savannah.

https://savannah.nongnu.org/maintenance/SshAccess/

Then also log into your Savannah web UI and upgrade your access keys
for use with Savannah systems as this would likely be a problem for
any ssh access there too.

I appreciate hearing feedback about these instructions.  If they work.
If they don't work.  If they were confusing.  If they were clear.  We
want to be able to help people with the best information possible.
Thanks!

Hopefully this will get you going!



    _______________________________________________________

Reply to this item at:

  <https://savannah.nongnu.org/support/?110996>

_______________________________________________
Message sent via Savannah
https://savannah.nongnu.org/


Reply via email to