OpenSSH future RSA host key deprecation

eworm · Fri Feb 14, 2020 2:18 pm

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!

eworm · Mon Feb 17, 2020 9:22 pm

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.

eworm · Tue Feb 18, 2020 10:58 am

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

eworm · Mon Mar 02, 2020 11:11 am

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

theprojectgroup · Mon Mar 09, 2020 12:50 pm

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

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

andrin · Fri May 15, 2020 6:04 pm

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.

eworm · Fri May 15, 2020 6:54 pm

No progress, no reaction on ed25519 keys from Mikrotik.

xxtudo121xx · Thu Jan 14, 2021 4:59 pm

Any alternative to this problem?

eworm · Wed Jan 20, 2021 2:20 pm

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

xxtudo121xx · Wed Feb 10, 2021 7:48 pm

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.

derdeagle · Fri Mar 19, 2021 5:44 pm

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

gsauthof · Fri May 28, 2021 8:20 pm

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

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 ...

eworm · Wed Jun 09, 2021 7:53 pm

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...

gsauthof · Wed Jun 09, 2021 10:42 pm

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.

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

eworm · Thu Jun 10, 2021 12:13 pm

Well, I was not wrong but we spoke about different topics. 😝
(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.

eworm · Thu Jun 10, 2021 12:21 pm

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

But it does not mention openssh.

eworm · Mon Sep 27, 2021 4:50 pm

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...

LaKing · Wed Sep 29, 2021 12:50 am

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.

Knu1 · Thu Oct 21, 2021 12:06 am

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.

markus · Sun Dec 12, 2021 9:44 pm

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'").

eworm · Mon Dec 13, 2021 5:28 pm

Please note that RouterOS supports rsa-sha2-256 for host key algorithm just fine. The recent issue is about public key authentication.

ewulf · Wed Dec 15, 2021 4:09 pm

I also ran into this just today. Seems still present in ROS 7.1.

Please fix ASAP.

Here is my debug putput from OpenSSH (on an Arch Linux):

~ $ ssh -vvvv automation@192.168.0.2
OpenSSH_8.8p1, OpenSSL 1.1.1l  24 Aug 2021
debug1: Reading configuration data /home/user/.ssh/config
debug1: /home/user/.ssh/config line 1: Applying options for *
debug3: kex names ok: [diffie-hellman-group1-sha1]
debug3: kex names ok: [diffie-hellman-group1-sha1]
debug3: kex names ok: [diffie-hellman-group1-sha1]
debug1: Reading configuration data /etc/ssh/ssh_config
debug2: resolve_canonicalize: hostname 192.168.0.2 is address
debug3: expanded UserKnownHostsFile '~/.ssh/known_hosts' -> '/home/user/.ssh/known_hosts'
debug3: expanded UserKnownHostsFile '~/.ssh/known_hosts2' -> '/home/user/.ssh/known_hosts2'
debug3: ssh_connect_direct: entering
debug1: Connecting to 192.168.0.2 [192.168.0.2] port 22.
debug3: set_sock_tos: set socket 3 IP_TOS 0x48
debug1: Connection established.
debug1: identity file /home/user/ansible/id_rsa_automation type 0
debug1: identity file /home/user/ansible/id_rsa_automation-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_8.8
debug1: Remote protocol version 2.0, remote software version ROSSSH
debug1: compat_banner: no match: ROSSSH
debug2: fd 3 setting O_NONBLOCK
debug1: Authenticating to 192.168.0.2:22 as 'automation'
debug3: record_hostkey: found key type RSA in file /home/user/.ssh/known_hosts:143
debug3: load_hostkeys_file: loaded 1 keys from 192.168.0.2
debug1: load_hostkeys: fopen /home/user/.ssh/known_hosts2: No such file or directory
debug1: load_hostkeys: fopen /etc/ssh/ssh_known_hosts: No such file or directory
debug1: load_hostkeys: fopen /etc/ssh/ssh_known_hosts2: No such file or directory
debug3: order_hostkeyalgs: prefer hostkeyalgs: rsa-sha2-512-cert-v01@openssh.com,rsa-sha2-256-cert-v01@openssh.com,rsa-sha2-512,rsa-sha2-256
debug3: send packet: type 20
debug1: SSH2_MSG_KEXINIT sent
debug3: receive packet: type 20
debug1: SSH2_MSG_KEXINIT received
debug2: local client KEXINIT proposal
debug2: KEX algorithms: curve25519-sha256,curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,diffie-hellman-group14-sha256,ext-info-c
debug2: host key algorithms: rsa-sha2-512-cert-v01@openssh.com,rsa-sha2-256-cert-v01@openssh.com,rsa-sha2-512,rsa-sha2-256,ssh-ed25519-cert-v01@openssh.com,ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp384-cert-v01@openssh.com,ecdsa-sha2-nistp521-cert-v01@openssh.com,sk-ssh-ed25519-cert-v01@openssh.com,sk-ecdsa-sha2-nistp256-cert-v01@openssh.com,ssh-ed25519,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,sk-ssh-ed25519@openssh.com,sk-ecdsa-sha2-nistp256@openssh.com
debug2: ciphers ctos: chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com
debug2: ciphers stoc: chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com
debug2: MACs ctos: umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: MACs stoc: umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: compression ctos: none,zlib@openssh.com,zlib
debug2: compression stoc: none,zlib@openssh.com,zlib
debug2: languages ctos: 
debug2: languages stoc: 
debug2: first_kex_follows 0 
debug2: reserved 0 
debug2: peer server KEXINIT proposal
debug2: KEX algorithms: diffie-hellman-group-exchange-sha256
debug2: host key algorithms: ssh-rsa,rsa-sha2-256
debug2: ciphers ctos: aes128-ctr,aes192-ctr,aes256-ctr,aes128-cbc,aes192-cbc,aes256-cbc,3des-cbc
debug2: ciphers stoc: aes128-ctr,aes192-ctr,aes256-ctr,aes128-cbc,aes192-cbc,aes256-cbc,3des-cbc
debug2: MACs ctos: hmac-sha1,hmac-md5
debug2: MACs stoc: hmac-sha1,hmac-md5
debug2: compression ctos: none
debug2: compression stoc: none
debug2: languages ctos: 
debug2: languages stoc: 
debug2: first_kex_follows 0 
debug2: reserved 0 
debug1: kex: algorithm: diffie-hellman-group-exchange-sha256
debug1: kex: host key algorithm: rsa-sha2-256
debug1: kex: server->client cipher: aes128-ctr MAC: hmac-sha1 compression: none
debug1: kex: client->server cipher: aes128-ctr MAC: hmac-sha1 compression: none
debug3: send packet: type 34
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(2048<7680<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug3: receive packet: type 31
debug1: SSH2_MSG_KEX_DH_GEX_GROUP received
debug2: bits set: 1019/2048
debug3: send packet: type 32
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug3: receive packet: type 33
debug1: SSH2_MSG_KEX_DH_GEX_REPLY received
debug1: Server host key: ssh-rsa SHA256:XXXXXXXXX
debug3: record_hostkey: found key type RSA in file /home/user/.ssh/known_hosts:143
debug3: load_hostkeys_file: loaded 1 keys from 192.168.0.2
debug1: load_hostkeys: fopen /home/user/.ssh/known_hosts2: No such file or directory
debug1: load_hostkeys: fopen /etc/ssh/ssh_known_hosts: No such file or directory
debug1: load_hostkeys: fopen /etc/ssh/ssh_known_hosts2: No such file or directory
debug1: Host '192.168.0.2' is known and matches the RSA host key.
debug1: Found key in /home/user/.ssh/known_hosts:143
debug2: bits set: 1041/2048
debug3: send packet: type 21
debug2: set_newkeys: mode 1
debug1: rekey out after 4294967296 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug3: receive packet: type 21
debug1: SSH2_MSG_NEWKEYS received
debug2: set_newkeys: mode 0
debug1: rekey in after 4294967296 blocks
debug1: Will attempt key: /home/user/ansible/id_rsa_automation RSA SHA256:XXXXXXXXX explicit
debug2: pubkey_prepare: done
debug3: send packet: type 5
debug3: receive packet: type 6
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug3: send packet: type 50
debug3: receive packet: type 51
debug1: Authentications that can continue: publickey,password
debug3: start over, passed a different list publickey,password
debug3: preferred publickey,keyboard-interactive,password
debug3: authmethod_lookup publickey
debug3: remaining preferred: keyboard-interactive,password
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Offering public key: /home/user/ansible/id_rsa_automation RSA SHA256:XXXXXXXXX explicit
debug1: send_pubkey_test: no mutual signature algorithm
debug2: we did not send a packet, disable method
debug3: authmethod_lookup password
debug3: remaining preferred: ,password
debug3: authmethod_is_enabled password
debug1: Next authentication method: password
automation@192.168.0.2's password:

[admin@ap] > /system/routerboard/print
       routerboard: yes
        board-name: wAP ac
             model: RouterBOARD wAP G-5HacT2HnD
     serial-number: XXXXXXX
     firmware-type: qca9550L
  factory-firmware: 3.34
  current-firmware: 7.1
  upgrade-firmware: 7.1

[admin@ap] > /system/resource/print 
                   uptime: 6d6h24m15s
                  version: 7.1 (testing)
               build-time: Dec/01/2021 14:07:27
         factory-software: 6.33.5
              free-memory: 22.7MiB
             total-memory: 64.0MiB
                      cpu: MIPS 74Kc V5.0
                cpu-count: 1
            cpu-frequency: 720MHz
                 cpu-load: 0%
           free-hdd-space: 4108.0KiB
          total-hdd-space: 16.0MiB
  write-sect-since-reboot: 3962
         write-sect-total: 179388
               bad-blocks: 0%
        architecture-name: mipsbe
               board-name: wAP ac
                 platform: MikroTik

Best regards

zetxx · Tue Dec 28, 2021 3:54 pm

obi · Fri Feb 18, 2022 10:33 am

any progress?

PackElend · Sun Apr 03, 2022 5:02 pm

has anyone contacted support / opened a ticket?

ilium007 · Thu Apr 28, 2022 5:02 pm

Following.

Ran into same issue with routerOS 7.2.1 today. Solved with .ssh/config addition as per this thread.

colinardo · Tue Jun 07, 2022 7:14 pm

It's fixed in Router OS 7.4beta2
viewtopic.php?t=186583
What's new in 7.4beta2 (2022-Jun-07 12:08)
*) ssh - disable ssh-rsa when strong-crypto=yes and use rsa-sha2-sha256;

OpenSSH future RSA host key deprecation

OpenSSH future RSA host key deprecation

Re: OpenSSH future RSA host key deprecation

Re: OpenSSH future RSA host key deprecation

Re: OpenSSH future RSA host key deprecation

Re: OpenSSH future RSA host key deprecation

Re: OpenSSH future RSA host key deprecation

Re: OpenSSH future RSA host key deprecation

Re: OpenSSH future RSA host key deprecation

Re: OpenSSH future RSA host key deprecation

Re: OpenSSH future RSA host key deprecation

Re: OpenSSH future RSA host key deprecation

Re: OpenSSH future RSA host key deprecation

Re: OpenSSH future RSA host key deprecation

Re: OpenSSH future RSA host key deprecation

Re: OpenSSH future RSA host key deprecation

Re: OpenSSH future RSA host key deprecation

Re: OpenSSH future RSA host key deprecation

Re: OpenSSH future RSA host key deprecation

Re: OpenSSH future RSA host key deprecation

Re: OpenSSH future RSA host key deprecation

Re: OpenSSH future RSA host key deprecation

Re: OpenSSH future RSA host key deprecation

Re: OpenSSH future RSA host key deprecation

Re: OpenSSH future RSA host key deprecation

Re: OpenSSH future RSA host key deprecation

Re: OpenSSH future RSA host key deprecation

Re: OpenSSH future RSA host key deprecation