UPD see below, this were a problem with various SSH clients which didn’t support the now-necessary algorithms.
Looks like in openssh8.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 ssh-rsa sort.
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?
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.
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):
HostKeyAlgorithms +ssh-rsa
PubkeyAcceptedKeyTypes +ssh-rsa
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