UPD see below, this were a problem with various SSH clients which didn’t support the now-necessary algorithms.
Looks like in
8.8 they’ve deprecated
ssh-rsa (SHA-1) keys (see https://www.openssh.com/txt/release-8.8, Potentially-incompatible changes). Which is nice, but unfortunately many of my
PuTTy-made keys happened to be of just that
As I’ve had a bunch of my not-very-production servers pointed to
nixos-unstable, they’ve now all received this update and locked me out. Those are remote servers, so console logon is problematic. Fortunately, they’re proper NixOS and can be rebuilt from scratch, still this takes some effort.
Any ideas how to temporarily unlock
ssh-rsa on them at least to change the keys?
SHA1 signatures. Not keys (
The confusing bit is that
ssh-rsa can refer to either a public key type (unrelated) or key algorithm involving SHA1. Only the latter is removed.
For most users, this change should be invisible and there is
no need to replace ssh-rsa keys.
You’d have to use fairly old clients to run into issues here - say, OpenSSH on CentOS 6.
That, or there’s something else amiss. What errors are you’re getting? Try connecting using OpenSSH and enable verbose (
-v) mode - if necessary you can also increase the log verbosity on the server end.
Also see: Demystifying “ssh-rsa” in OpenSSH Deprecation Notice
Do you get any error messages from putty?
For me it was the other way around: Updated my client ssh and tried to connect to an “old” ssh server. This resulted in:
“Unable to negotiate with $IP port 22: no matching host key type found. Their offer: ssh-rsa,ssh-dss”
Adding the options (as stated in the release notes):
to my .ssh/config solved it for me. Though, I don’t have any clue if this a) would solve yours (cause, it’s the other way around) and b) how you could try it with putty, as I don’t have/use putty.
Wow that was really silly of me.
Should have remembered there’s no SHA1 involved in writing the key — I’ve even had to write a converter for Windows CryptoAPI keys into openssh format some time ago, so it just… hadn’t come in mind… I don’t know. Sorry.
I’ve tried connecting from several different clients and it failed with every one, which kind of hinted me on the problem with keys. I’ve started updating them and now it looks OK. Latest PuTTY is okay (my prev one were not too old either, but looks like it’s not well maintained and isn’t getting non-mandatory algorithms too soon).
Thanks for the hint.
maybe for the next poor soul that comes here with this problem, what did you do to ‘upgrade’ your client keys? or was it a clickey click click windows GUI procedure.
Keys are OK. They also say
ssh-rsa letters in the file, but that’s a different sort of
ssh-rsa which has not been deprecated itself.
The problem is with algorithms which SSH client uses for connecting to the SSH server. In this case it depends on the client. Seek a newer version if this happens. Older clients only support deprecated algo.
For PuTTY, the official latest version has this OK. I had a recent one, but not the latest, so they didn’t use to have the newer algorithms until recently.
For IntelliJ IDEA / Rider, I’m talking to the team. Seems like the latest versions are not OK. We’ll see.
Latest FAR Manager (NetBox): FAIL
Latest WinSCP: FAIL