[SOLVED] Latest sshd not accepting key algorithms

chowbok · 2021-09-29 06:17:42

I just upgraded from openssh 8.7p1-1 to openssh 8.8p1-1. When I try to do a key-based login now, it's refusing my connection and logging this:

userauth_pubkey: key type ssh-rsa not in PubkeyAcceptedAlgorithms

This is very odd, since ssh claims it is an accepted algorithm:

> ssh -Q PubkeyAcceptedAlgorithms | grep rsa
ssh-rsa
rsa-sha2-256
rsa-sha2-512
ssh-rsa-cert-v01@openssh.com
rsa-sha2-256-cert-v01@openssh.com
rsa-sha2-512-cert-v01@openssh.com

A Google seach for that error gives me exactly one hit, in Russian.

Anyone have any thoughts?

Last edited by chowbok (2021-09-29 06:46:54)

chowbok · 2021-09-29 06:37:22

Never mind, looks like a problem with PuTTY rather than OpenSSH. Anyone else running into this, you'll have to regenerate your keys with the latest version of PuTTYGen.

childerico · 2021-09-29 09:15:59

Actually, I have the some problem (i.e., key-based authentication not working any more) after the upgrade to openssh 8.8p1-1 and I am not using PuTTY. Downgrading fixes the issue.

EDIT: sorry for my pretty unuseful reply: the issue is likely not due to a bug in openssh: https://dev.to/cloudx/why-openssh-8-8-c … ovided-49i

Last edited by childerico (2021-09-29 09:19:00)

vr0 · 2021-09-30 03:45:12

> cat /etc/ssh/sshd_config
...
PubkeyAuthentication yes
PubkeyAcceptedKeyTypes=+ssh-rsa
...

> journalctl -f -u sshd
Sep 30 05:03:10 xxxx systemd[1]: Started OpenSSH Daemon.
Sep 30 05:03:10 xxxx sshd[115707]: Server listening on 0.0.0.0 port 22.
Sep 30 05:03:10 xxxx sshd[115707]: Server listening on :: port 22.
Sep 30 05:03:24 xxxx sshd[115709]: Accepted publickey for xxxx from xx.xx.xx.xx port 55163 ssh2: RSA SHA256:XXXX
Sep 30 05:03:24 xxxx sshd[115709]: pam_unix(sshd:session): session opened for user xxxx(uid=xxxx) by (uid=xxxx)
Sep 30 05:03:24 xxxx sshd[115709]: pam_env(sshd:session): deprecated reading of user environment enabled

That works for me, but I think soon or later we must change our public keys.

> ssh-keygen -o -a 100 -t ed25519 -f ~/.ssh/id_ed25519 -C "comment"
> ssh-keygen -t rsa-sha2-256 -b 4096 -f ~/.ssh/id_rsa2_256 -C "comment"
> ssh-keygen -t rsa-sha2-512 -b 4096 -f ~/.ssh/id_rsa2_512 -C "comment"

Cheers.

Last edited by vr0 (2021-09-30 03:49:20)

robinhood018 · 2021-10-10 18:23:56

Well, the above method didn't work for me too, so I had to downgrade to this version https://archive.archlinux.org/packages/ … kg.tar.zst
You can do all this by > pacman -U /path/to/this/openssh-8.7p1-2-x86_64.pkg.tar.zst

This is a suggested option for anyone else for whom the other options didn't work.

rashfeather · 2021-10-12 14:15:50

#5 worked for me. Interesting how it's only *some* remote hosts which had a problem. I was still able to access a majority just fine.

V1del · 2021-10-12 14:38:55

You are papering over an intentional disable/deprecation by downgrading the package: https://www.openssh.com/txt/release-8.8 note the potentially incompatible changes note. You should fix your server's keys or follow #4 as a last resort instead of downgrading the package.

probackup-nl · 2021-10-23 20:50:26

#4 doesn't work on 5.10.74-1-raspberrypi4-ARCH:

$ grep Pub /etc/ssh/sshd_config
PubkeyAuthentication yes
PubkeyAcceptedKeyTypes=+ssh-rsa
$ sudo systemctl restart sshd

ssh-audit still recommends to add ssh-rsa:

# algorithm recommendations (for OpenSSH 8.8)
(rec) -ecdh-sha2-nistp521                   -- kex algorithm to remove
(rec) -ecdh-sha2-nistp384                   -- kex algorithm to remove
(rec) -ecdh-sha2-nistp256                   -- kex algorithm to remove
(rec) -diffie-hellman-group-exchange-sha256 -- kex algorithm to remove
(rec) -ecdsa-sha2-nistp256                  -- key algorithm to remove
(rec) +ssh-rsa                              -- key algorithm to append
...

PS And an ancient OpenSSH 6.2 client responds with "no hostkey alg" and sshd logs in journal:

Unable to negotiate with X port Y: no matching host key type found. Their offer: ssh-rsa-cert-v01@openssh.com,ssh-rsa-cert-v00@openssh.com,ssh-rsa,ssh-dss-cert-v01@openssh.com,ssh-dss-cert-v00@openssh.com,ssh-dss [preauth]

Last edited by probackup-nl (2021-10-23 20:54:19)

loqs · 2021-10-24 20:08:20

probackup-nl wrote:

ssh-audit still recommends to add ssh-rsa:

What version of ssh-audit is producing that output?

https://github.com/jtesta/ssh-audit/com … 7d1ff73c89

Wild Penguin · 2021-11-13 12:40:40

I was also hit by this bug while trying to access my OpenWRT router.

I also noticed, that ssh-keygen still creates RSA keys per default. Hmm, interersting: it creates keys that OpenSSH itself has deprecated!

Perhaps the wiki should be updated to advice users on this deprecation and to create stronger keys, and perhaps upstream is wise enough to change the default key type, both to facilitate the transition. What do you think?

Also, sorry if I'm veered too much off-topic! This is just some input from a user-point of view. I understand the world is going on forward, and some algorithms just need to be changed...

EDIT: Also, somehow missed this topic has already been marked as [SOLVED]!

Last edited by Wild Penguin (2021-11-13 12:57:47)

progandy · 2021-11-13 15:41:45

I also noticed, that ssh-keygen still creates RSA keys per default. Hmm, interersting: it creates keys that OpenSSH itse

A key marked as ssh-rsa should automatically use the newer rsa-sha2-256 / rsa-sha2-512 protocols to communicate with the server. (The stored rsa key does not include any data to specify the hash algorithm and has the same format for all three, it can be used with any of the hashes supported by ssh) That should(TM) work as long as the server supports them as well. If The ssh-server does support sha256/sha512, but the connection fails, then there is probably a bug in openssh.
Only the old protocol using rsa keys and SHA1 hashing has been disabled.

Last edited by progandy (2021-11-13 15:47:21)

drankinatty · 2021-11-19 08:06:06

It may be marked solved, but the problem remains for many devices that must present the new key to the updated version of openssh.. All my old ssh keys that are rsa work fine when present from phones, etc. However generating a new key with `ssh-keygen` generates a 3072 bit key and identifies it as `-----BEGIN OPENSSH PRIVATE KEY-----` instead of the older keys identified as `-----BEGIN RSA PRIVATE KEY-----`. The only thing I can tell is different between the keys generated that causes the issue is the length.

This works fine for Arch, but other apps that need to present the keys to your Arch server running sshd have problems with the longer length resulting in

userauth_pubkey: key type ssh-rsa not in PubkeyAcceptedAlgorithms [preauth]

Granted, this isn't an Arch or openssh problem, but I suspect we will see more of it as clients with older versions attempt to use newer keys with the current version of openssh on the server.

Last edited by drankinatty (2021-11-19 08:39:09)

Bachsau · 2021-11-30 18:47:31

There is no reason to downgrade anything, but the Algorithm used for user authentication is only one part of the equation. You also need re-enable it for the host key:

HostKeyAlgorithms +ssh-rsa
PubkeyAcceptedAlgorithms +ssh-rsa

If you add both to your sshd_config, old putty connections will work again.

Last edited by Bachsau (2021-11-30 19:41:49)

Wild Penguin · 2021-11-30 19:16:36

In my previous reply I got confused, but also I may have encountered an OpenSSH bug. I can not confirm since the conditions to trigger it don't exist anymore (I could try to reproduce them by re-configuring some host for testing)..

First, the ssh client on Arch started to not accept ssh-rsa as the Host Key algorithm (because it's deprecated? I'm not actually sure which ssh-rsa key the server used). But, also something different happened: if I set HostKeyAlgorithms=+ssh-rsa, it suddenly stops accepting to use my ssh-rsa public key, too. I also needed to set PubkeyAcceptedAlgorithms=+ssh-rsa. After upgrading the host I was connecting to so that the host has stronger ed25519 host keys, I don't need to set PubKeyAcceptedAlgorithms anymore. It will just accept both host and public keys (despite only the former had changed).

Bachsau · 2021-11-30 19:38:57

You need both because the algorithm has been deprecated and subsequently removed from both options. "ssh-rsa" should have better been called "rsa-sha1", because that's what it really means, but when it was defined, key-type and signature algorithm were one, and they didn't know that would change. Modern versions of OpenSSH combine the RSA keys with the more secure SHA-2, but putty did not support this for a long time and afaik only implemented it in the latest version when using the PPK3 key format.

ed25519 keys are newer and were never used together with SHA-1, so this isn't a problem here. But RSA requires a collision resistant hash function to apply to the message it signs (read this), and SHA-1 is broken.

Last edited by Bachsau (2021-11-30 20:02:46)

skimj · 2021-12-21 02:18:31

V1del wrote:

You are papering over an intentional disable/deprecation by downgrading the package

This is a very important point. This "breakage" is not a "bug".

From https://www.openssh.com/txt/release-8.8:

Incompatibility is more likely when connecting to older SSH implementations that have not been upgraded or have not closely tracked improvements in the SSH protocol.

Upgrading PuTTY (or any other client that doesn't implement openssh 8.8) to the latest version is the solution.

Bachsau · 2021-12-21 06:15:35

Of course that will be the best solution in the long term. However, as I understand it, the risk of using the old ssh-rsa is still theoretical because of how SHA-1 is used in this case. It may be a weak spot but does not open your server to immediate attacks.

nponeccop · 2021-12-30 18:39:09

Just in case someone else is googling, WinSCP 5.9.15 doesn't work. Putty 0.76 does work, without a need to regenerate a .ppk, including its psftp.

To make WinSCP working again, it's enough to change just PubkeyAcceptedAlgorithms and perform systemctl reload sshd.

progandy · 2021-12-30 19:11:12

nponeccop wrote:

To make WinSCP working again, it's enough to change just PubkeyAcceptedAlgorithms and perform systemctl reload sshd.

Better switch to the WinSCP 5.20 beta or generate ecdsa keys.
https://winscp.net/eng/docs/ssh_algorithms

nponeccop · 2022-01-01 20:33:30

Bachsau wrote:

Modern versions of OpenSSH combine the RSA keys with the more secure SHA-2, but putty did not support this for a long time and afaik only implemented it in the latest version when using the PPK3 key format.

JFYI PuTTY 0.76 works fine with old "PuTTY-User-Key-File-2: ssh-rsa" private keys. However, various other clients are still affected, e.g. WinSCP and the Network plugin in FarManager.

skimj wrote:

Upgrading PuTTY (or any other client that doesn't implement openssh 8.8) to the latest version is the solution.

The clients should implement rsa-sha2-256 or rsa-sha2-512, that is essentially what rsa-sha was replaced with. Of course other algorithms can be used too, but rsa-sha256 is the only one which doesn't require to change configuration or regenerate keys

Last edited by nponeccop (2022-01-04 12:58:57)

FormBurden · 2022-06-18 20:57:52

Hey all, just wanted to state that from #4 answer, changing/adding

PubkeyAcceptedKeyTypes=+ssh-rsa

has caused my Tabby Terminal Emulator to work correctly. In the past I couldn't figure out why I couldn't log in using my keys vs before I was heavily using Debian Containers and such in Proxmox and SSH would work correctly. Now trying once again to get this to work, it was the PubKey Accept that was the issue with Tabby. So glad I could get it working again.

2ManyDogs · 2022-06-18 22:53:12

Closing this old solved thread.

Arch Linux

#1 2021-09-29 06:17:42

[SOLVED] Latest sshd not accepting key algorithms

#2 2021-09-29 06:37:22

Re: [SOLVED] Latest sshd not accepting key algorithms

#3 2021-09-29 09:15:59

Re: [SOLVED] Latest sshd not accepting key algorithms

#4 2021-09-30 03:45:12

Re: [SOLVED] Latest sshd not accepting key algorithms

#5 2021-10-10 18:23:56

Re: [SOLVED] Latest sshd not accepting key algorithms

#6 2021-10-12 14:15:50

Re: [SOLVED] Latest sshd not accepting key algorithms

#7 2021-10-12 14:38:55

Re: [SOLVED] Latest sshd not accepting key algorithms

#8 2021-10-23 20:50:26

Re: [SOLVED] Latest sshd not accepting key algorithms

#9 2021-10-24 20:08:20

Re: [SOLVED] Latest sshd not accepting key algorithms

#10 2021-11-13 12:40:40

Re: [SOLVED] Latest sshd not accepting key algorithms

#11 2021-11-13 15:41:45

Re: [SOLVED] Latest sshd not accepting key algorithms

#12 2021-11-19 08:06:06

Re: [SOLVED] Latest sshd not accepting key algorithms

#13 2021-11-30 18:47:31

Re: [SOLVED] Latest sshd not accepting key algorithms

#14 2021-11-30 19:16:36

Re: [SOLVED] Latest sshd not accepting key algorithms

#15 2021-11-30 19:38:57

Re: [SOLVED] Latest sshd not accepting key algorithms

#16 2021-12-21 02:18:31

Re: [SOLVED] Latest sshd not accepting key algorithms

#17 2021-12-21 06:15:35

Re: [SOLVED] Latest sshd not accepting key algorithms

#18 2021-12-30 18:39:09

Re: [SOLVED] Latest sshd not accepting key algorithms

#19 2021-12-30 19:11:12

Re: [SOLVED] Latest sshd not accepting key algorithms

#20 2022-01-01 20:33:30

Re: [SOLVED] Latest sshd not accepting key algorithms

#21 2022-06-18 20:57:52

Re: [SOLVED] Latest sshd not accepting key algorithms

#22 2022-06-18 22:53:12

Re: [SOLVED] Latest sshd not accepting key algorithms

Board footer