OpenSSH future RSA host key deprecation

RouterOS General
1

Hello everybody,

version 8.2 of well known OpenSSH has been release:
[openssh-unix-announce] Announce: OpenSSH 8.2 released

The announcement comes with a deprecation notice for RSA host keys as used with RouterOS:

Future deprecation notice

It is now possible[1] to perform chosen-prefix attacks against the
SHA-1 algorithm for less than USD$50K. For this reason, we will be
disabling the “ssh-rsa” public key signature algorithm by default in a
near-future release.

This algorithm is unfortunately still used widely despite the
existence of better alternatives, being the only remaining public key
signature algorithm specified by the original SSH RFCs.

The better alternatives include:

  • The RFC8332 RSA SHA-2 signature algorithms rsa-sha2-256/512. These
    algorithms have the advantage of using the same key type as
    “ssh-rsa” but use the safe SHA-2 hash algorithms. These have been
    supported since OpenSSH 7.2 and are already used by default if the
    client and server support them.

  • The ssh-ed25519 signature algorithm. It has been supported in
    OpenSSH since release 6.5.

  • The RFC5656 ECDSA algorithms: ecdsa-sha2-nistp256/384/521. These
    have been supported by OpenSSH since release 5.7.

To check whether a server is using the weak ssh-rsa public key
algorithm, for host authentication, try to connect to it after
removing the ssh-rsa algorithm from ssh(1)'s allowed list:

ssh -oHostKeyAlgorithms=-ssh-rsa user at host

If the host key verification fails and no other supported host key
types are available, the server software on that host should be
upgraded.

A future release of OpenSSH will enable UpdateHostKeys by default
to allow the client to automatically migrate to better algorithms.
Users may consider enabling this option manually.

[1] “SHA-1 is a Shambles: First Chosen-Prefix Collision on SHA-1 and
Application to the PGP Web of Trust” Leurent, G and Peyrin, T
(2020) > https://eprint.iacr.org/2020/014.pdf

So future versions of OpenSSH client will not support connecting to current RouterOS.

user@linux $ ssh -oHostKeyAlgorithms=-ssh-rsa admin@mikrotik
Unable to negotiate with 192.168.88.1 port 22: no matching host key type found. Their offer: ssh-rsa

Please implement other (host) key algorithms for SSH in RouterOS as soon as possible. Thanks!

2

Just had a closer look. Would be nice to have ssh-ed25519, but it’s not a requirement. Support for rsa-sha2-512 and/or rsa-sha2-256 (defined in RFC8332) would be sufficient. Just ssh-rsa (which uses SHA1) is deprecated here. Sadly RouterOS supports the latter one only.

3

Version 6.47beta35 adds support for rsa-sha2-256. Public key authentication does not work, though.
Thanks anyway!

4

Version 6.46.4 also fixes the issue with public key authentication. All fine now, thanks a lot!

5

This is not fixed. We still have issues (#[SUP-10614]) with public key authentication.
The router first advertises rsa-sha2-256 and then declines it:

14:59:56 ssh,debug host key algo: rsa-sha2-256,ssh-rsa-sha256@ssh.com,rsa-sha2-512,ssh-rsa,ssh-dss,x509v3-sign-rsa-sha256@ssh.com,x509v3-sign-rsa,x509v3-sign-dss,ssh-ed25519,ecdsa-sha2-nistp256
14:59:56 ssh,debug kex algo: curve25519-sha256@libssh.org,ecdh-sha2-nistp256,diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha256,diffie-hellman-group15-sha512,diffie-hellman-group16-sha512,diffie-hellm
an-group-exchange-sha1,diffie-hellman-group14-sha1,ext-info-c
14:59:56 ssh,debug enc algo CS: aes256-gcm@openssh.com,aes128-gcm@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr,3des-ctr,twofish256-ctr,twofish192-ctr,twofish128-ctr,aes256-cbc,aes192-cbc,aes128-cbc,3des-cbc,twofish25
6-cbc,twofish192-cbc,twofish128-cbc,twofish-cbc,chacha20-poly1305@openssh.com
14:59:56 ssh,debug mac algo CS: hmac-sha2-256-etm@openssh.com,hmac-sha2-256,hmac-sha2-512-etm@openssh.com,hmac-sha2-512,hmac-sha1
14:59:56 ssh,debug comp algo CS: none,zlib,zlib@openssh.com
14:59:56 ssh,debug packet follows: 0
14:59:56 ssh,debug agreed on: diffie-hellman-group-exchange-sha256 rsa-sha2-256 aes256-ctr aes256-ctr hmac-sha1 hmac-sha1 none none
…
14:59:56 ssh,debug unsupported algo: rsa-sha2-256

6

Is there any progress for the implementation of ed25519 pubkeys?

On RouterOS 6.45.9 i cannot import my public key:

/user ssh-keys import public-key-file=sshkey_v2.pub.txt user=admin
unable to load key file (wrong format?) !

OpenSSH supports this since version 6.5 from January 30, 2014.

7

No progress, no reaction on ed25519 keys from Mikrotik.

8

Any alternative to this problem?

9

The problem was solved… So what exactly is your problem?

10

I am no longer able to use private keys. I’ve always used it like this, but in the new versions I’m not able to use .ppk or .pem

I have several RBs with this same key. When I needed to change one of them and updated it, I couldn’t use the private keys anymore.
It’s Weird, but the keys I used were always .ppk.

11

I was able to find a fix for this.

Adding the following settings in the local SSH client config made it work for me:

Host my-mikrotik-device.example.com
	PubkeyAcceptedKeyTypes +ssh-rsa
12

I can confirm that connecting with

-o HostKeyAlgorithms=-ssh-rsa

or

-o HostKeyAlgorithms=rsa-sha2-256

does work against RouterOS 6.48.3.

What still doesn’t work is rsa-sha2-256 for public key authentication!

So, currently, even with the latest stable RouterOS, this doesn’t work:

ssh -o PubkeyAcceptedKeyTypes=-ssh-rsa -o HostKeyAlgorithms=-ssh-rsa   mikrotik  -v

And the client reports:

debug1: send_pubkey_test: no mutual signature algorithm

The thing is that Linux distributions are on their way removing ssh-rsa from the default PubkeyAcceptedKeyTypes list. For example, the default Fedora 33 crypto policy doesn’t include ssh-rsa.

Thus, one currently has to work around this with e.g.

ssh -o PubkeyAcceptedKeyTypes=ssh-rsa -o HostKeyAlgorithms=-ssh-rsa   mikrotik

to see that RouterOS actually supports rsa-sha2-256 for host keys …

13

You are confusing two things here.
There’s key type and host key algorithm. As MikroTik supports ssh-rsa for key type and rsa-sha2-256 for host key algorithm everything is fine.
Just “ssh-rsa” for host key algorithm is deprecated.

Yes, this is confusing…

14

No, I’m not. You are wrong.

You are confusing ssh key types and public key authentication algorithms.

For the examples I included in my last posts I used the same RSA key:

$ file ~/.ssh/example-mikrotik-rsa-2021.pub
/home/juser/.ssh/example-mikrotik-rsa-2021.pub: OpenSSH RSA public key

You get a list of the public key authentication algorithm your client
support like this:

ssh -Q PubkeyAcceptedKeyTypes

Note that there are several ones that contain the rsa substring:

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

You see, those can be used in combination with a user’s RSA key …

So, as of 2021, ssh-rsa usage is considered insecure, thus it’s disabled on modern Linux distributions, by default. Also, OpenSSH has deprecated it, recommends alternatives, and likely removes it from a future OpenSSH release.

The problem is that Mikrotik’s RouterOS doesn’t support any secure alternative public key authentication algorithm, such as rsa-sha2-256.

Thus, this also fails against a Mikrotik device:

ssh -o PubkeyAcceptedKeyTypes=rsa-sha2-256 mikrotik

Wherea when I copy the same public key to a Linux server, public key authentication with other secure public key authentication algorithms does work as expected:

ssh -v -F /dev/null -o UserKnownHostsFile=delme -o IdentitiesOnly=yes  -i /home/juser/.ssh/example-mikrotik-rsa-2021  -o PubkeyAcceptedKeyTypes=rsa-sha2-256 example.org
ssh -v -F /dev/null -o UserKnownHostsFile=delme -o IdentitiesOnly=yes  -i /home/juser/.ssh/example-mikrotik-rsa-2021  -o PubkeyAcceptedKeyTypes=rsa-sha2-512 example.org

In case you aren’t already convinced, you might want to try a web search and/or
check out these fine questions/answers on that topic:

https://security.stackexchange.com/q/226131/42507
https://superuser.com/q/1556852/66039

15

Well, I was not wrong but we spoke about different topics. :squinting_face_with_tongue:
(Note the initial topic is about host keys, so this was kind of hijacked - though this is related… Perhaps you should open a new topic on this.)

No idea about public key authentication algorithms… Would have to take a look first.
Running Arch Linux with latest OpenSSH 8.6p1 here without issue.

16

This is what I found from Fedora:
https://fedoraproject.org/wiki/Changes/StrongCryptoSettings2

But it does not mention openssh.

17

This is now the upstream default with OpenSSH 8.8p1, the relevant part:

Potentially-incompatible changes

This release disables RSA signatures using the SHA-1 hash algorithm
by default. This change has been made as the SHA-1 hash algorithm is
cryptographically broken, and it is possible to create chosen-prefix
hash collisions for <USD$50K [1]

For most users, this change should be invisible and there is
no need to replace ssh-rsa keys. OpenSSH has supported RFC8332
RSA/SHA-256/512 signatures since release 7.2 and existing ssh-rsa keys
will automatically use the stronger algorithm where possible.

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. For these cases, it may be necessary
to selectively re-enable RSA/SHA1 to allow connection and/or user
authentication via the HostkeyAlgorithms and PubkeyAcceptedAlgorithms
options. For example, the following stanza in ~/.ssh/config will enable
RSA/SHA1 for host and user authentication for a single destination host:

Host old-host
HostkeyAlgorithms +ssh-rsa
PubkeyAcceptedAlgorithms +ssh-rsa

We recommend enabling RSA/SHA1 only as a stopgap measure until legacy
implementations can be upgraded or reconfigured with another key type
(such as ECDSA or Ed25519).

[1] “SHA-1 is a Shambles: First Chosen-Prefix Collision on SHA-1 and
Application to the PGP Web of Trust” Leurent, G and Peyrin, T
(2020) > https://eprint.iacr.org/2020/014.pdf

[openssh-unix-announce] Announce: OpenSSH 8.8 released

So would be nice if MikroTik would finally add modern key types…

18

Just bumped into this.

So my SSH client says “no mutual signature algorithm” - Fedora 33.
.. and ssh keys then don’t work …

Yes, I understand that adding command line parameters can be a workaround, but I’m waiting for the RouterOS fix.
Please notify on this thread …

Thanks.

19

Bumped into this today.
Took me a while to figure out why I couldn’t connect to a remote box.

Thanks @derdeagle for the tip in .ssh/config file. That will do until Mikrotik hopefully patch their SSH server.

20

Ran into this too. Either specify “-o ‘PubkeyAcceptedKeyTypes +ssh-rsa’” for ssh or put the option into ~/.ssh/config for your mikrotik host.

Given that ssh-rsa is not supported, I don’t understand how can mikrotik not support either ed25519 keys or another host key algorithm (say “-o ‘HostKeyAlgorithms=rsa-sha2-256’”).