OpenSSH v9 new default conf directive "PubkeyAcceptedKeytypes"

fr3ddie

Hello all,

First of all, let me say this is not strictly a pfSense issue but it is something that is derived from arguable upstream decisions.
The new OpenSSH released with pfSense v2.7.1 CE has a new configuration directive ("PubkeyAcceptedAlgorithms", that replaced the old "PubkeyAcceptedKeyTypes") with a new default value that excludes RSA keys (there is no "ssh-rsa" value anymore).

This leads me, and others who use only an RSA key for SSH (no password access enabled), to be locked-out from the pfSense machine right after the upgrade to v2.7.1.
This is an issue but the most important problem is that there is no "clean" way to workaround this behavior (to my knowledge): if I enable password access I can login again via SSH but, if I try to modify the /etc/ssh/sshd_config file adding the "PubkeyAcceptedAlgorithms +ssh-rsa", then at each restart of the SSH daemon the config file is replaced by the default one (that has the new "embedded" default), locking me out again.....

Probably a new default value of "PubkeyAcceptedAlgorithms +ssh-rsa" should be included in the OpenSSH config file in order to avoid this "silent" lockout. Or, at least, allow some sort of textbox in the webgui for SSH configuration, that allows to add custom directives to the actual config file for OpenSSH.

Actually there is no real reason to exclude RSA as an algorithm for public keys (maybe it may be important to use BIG keys, 16 kb or more) but there is no "flaw" in the algorithm that should make it deprecated...

Thank you

stephenw10

Hmm, are you sure it's not just that the key has only sha1 fingerprints?

I am able to login to 2.7.1 using an RSA key that has sha256 fingerprints.

Nov 25 19:22:42 	sshd 	85845 	Accepted publickey for admin from 172.21.16.8 port 57116 ssh2: RSA SHA256:**************************************

It's a 2048 bit key.

Steve

fr3ddie

@stephenw10 no, it has actually a 256 bit hash:
admin@nas ~$ ssh-keygen -l -f <key>.pub
16384 SHA256:Vihxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxs2Q <user>@Darth (RSA)

stephenw10

Hmm, same as I'm using, just larger:

steve@steve-NUC9i9QNX:~/.ssh$ ssh-keygen -l -f id_rsa.pub 
2048 SHA256:uLAxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxDiU steve@steve-MMLP7AP-00 (RSA)

What error is logged when you try to login?

dennypage

RSA 2048 (112 bits) doesn't really cut it any more. 3072 (128 bit) is recommended. Above 3072, there is a dramatic increase in cost, so it's better to look at different algorithms.

In the end my solution was to just disable the RSA keys on my systems and use elliptical only for ssh. The only exception being the few select systems which still require RSA such as Cisco switches.

I understand that this may be a bit too fast / too soon for some folk. YMMV.

FWIW, following is the system patch I use for pfSense, which has been stable for a few releases:

--- /etc/inc/globals.inc.org	2023-02-02 08:47:26.000000000 -0800
+++ /etc/inc/globals.inc	2023-02-02 22:53:00.000000000 -0800
@@ -365,7 +365,6 @@
 
 global $ssh_keys;
 $ssh_keys = [
-	['type' => 'rsa', 'suffix' => 'rsa_'],
 	['type' => 'ed25519', 'suffix' => 'ed25519_'],
 ];
 
--- /etc/sshd.org	2023-02-02 08:47:26.000000000 -0800
+++ /etc/sshd	2023-02-02 22:53:00.000000000 -0800
@@ -70,7 +70,7 @@
 /* Include default configuration for pfSense */
 /* Taken from https://stribika.github.io/2015/01/04/secure-secure-shell.html */
 $sshconf = "# This file is automatically generated at startup\n";
-$sshconf .= "KexAlgorithms curve25519-sha256@libssh.org,diffie-hellman-group-exchange-sha256\n";
+$sshconf .= "KexAlgorithms curve25519-sha256@libssh.org,curve25519-sha256\n";
 /* Run the server on another port if we have one defined */
 $sshconf .= "Port $sshport\n";
 /* Only allow protocol 2, because we say so */
@@ -116,7 +116,7 @@
 }
 $sshconf .= "X11Forwarding no\n";
 $sshconf .= "Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr\n";
-$sshconf .= "MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-512,hmac-sha2-256,umac-128@openssh.com\n";
+$sshconf .= "MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,umac-128-etm@openssh.com\n";
 $sshconf .= "# override default of no subsystems\n";
 $sshconf .= "Subsystem\tsftp\t/usr/libexec/sftp-server\n";

stephenw10

Hmm, interesting that I'm seeing it allowed then...

fr3ddie

@stephenw10 maybe I have found the combination of factors that lead to the error (and to the need of the directive in SSH configuration).
I noticed that if I use the exact same key from another client machine it suddenly works (as it is happening to you): thus the issue might be that the client machine has an old OpenSSH v6.7 (it is a Debian Jessie machine) and this client/server combination creates the problem.
Most probably, that old version only has ssh-rsa public key exchange algorithm (checking into the manpage for sshd_config the old PubkeyAcceptedKeyTypes directive does not even exist...), thus algorithm removal from the new version creates the problem.

Now, in my opinion, the question is: is ssh-rsa public key exchange algorithm actually insecure?
If it is not, the new default is totally dumb (only driven by "newer is better"), otherwise there is no other solution to the insertion of the "compatibility" directive (PubkeyAcceptedAlgorithms +ssh-rsa) using the /etc/sshd file, as suggested by @dennypage

(in any case, such an event should have been reported in the release notes since it potentially locks out administrators from the machines)

Thank you

dennypage

@stephenw10 said in OpenSSH v9 new default conf directive "PubkeyAcceptedKeytypes":

Hmm, interesting that I'm seeing it allowed then...

What is acceptable in security is a moving window. For RSA, a key length of 2048 is still in widespread use and considered acceptable for time ranges under 2030, but will move to being classed as legacy in the next few years. 3072 is the current recommended key length. The problem with RSA is that when you get to larger key sizes, 4096 (which isn't considered a sufficient bump over 3072) and above, the cost of using RSA becomes pretty high.

I prefer to be a bit ahead of the curve (pardon the pun), and use elliptical. Elliptical is available on all but a few embedded systems and is rather inexpensive when compared with RSA.

johnpoz

@dennypage I'm with you, using ed25519 on mine just looked, its dated from back in 2021..

Only thing I am still using rsa on is like my old sg300 switch doesn't support anything else.

dennypage

@johnpoz said in OpenSSH v9 new default conf directive "PubkeyAcceptedKeytypes":

Only thing I am still using rsa on is like my old sg300 switch doesn't support anything else.

Unfortunately even the current CBS switches only allow RSA 2048 and SHA1 as well. I believe this is scheduled to be fixed in the next release though.