SSH "broken" in Ventura

[Buadhai]

Ventura (I have 13.0 Beta (22A5342f)), ships with OpenSSH_9.0p1. According to the OpenSSH release notes:

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]

In my case this meant that the RSA keys that I had generated using just ssh-keygen without specifying a key type ended up with RSA signatures using the now deprecated SHA-1 hash algorithm. Put simply this meant that I could no longer log in to my Mac running Ventura from devices with deprecated keys.

A workaround is described in this Reddit thread: SSH in Ventura

Perhaps a better solution is to generate keys based on a more secure hash algorithm. For the time being, I'm switching to ed25519

Which you can generate like this:

ssh-keygen -t ed25519 -C "comment"

I'd be interested in reading alternative thoughts on this.

 

[Tuba]

SHA-1 has been considered mostly unsafe for about two decades. Which SSH version and OS had you created those deprecated keys on?

 

[Buadhai]

On a Raspberry Pi 4

pi@raspsky:~/webcam $ cat /etc/os-release
PRETTY_NAME="Raspbian GNU/Linux 10 (buster)"

pi@raspsky:~/webcam $ ssh -V
OpenSSH_7.9p1 Raspbian-10+deb10u2+rpt1, OpenSSL 1.1.1n  15 Mar 2022

The web host that I'm using is still on:

[~]# ssh -V
OpenSSH_5.3p1, OpenSSL 1.0.1e-fips 11 Feb 2013

 

[Tuba]

That’s a distressingly old OpenSSH on the web host.

That 7.9 apparently defaults to RSA/SHA1 surprises me, but 7.9 isn’t exactly new either.

I guess this is a potential issue for everyone until Debian/Ubuntu move to a more recent release. Thanks for posting it so the rest of us won’t have to find out the hard way.

 

[Buadhai]

I was mistaken about the SHA-1 key on the Pi. It must have been generated by an earlier version of OpenSSH. I generated a new one and got:

pi@raspsky:~/webcam $ ssh-keygen -l -f ~/.ssh/id_rsa.pub
2048 SHA256:z9ncZAvJ+QXO3re5NWzODcVr8Qn5wXxOLJ5Gi9Yt/J0 pi@raspsky (RSA)

I guess it shows that if, like me, you didn't keep up, you might have some old keys still around.

I also found that Shelly, the iPad/iPhone SSH client is based on an old version of PUTTY (7.0 ?) which generates SHA-1 signatures. The author plans an upgrade.

Here's an interesting article on the issue:

RSA keys are not deprecated; SHA-1 signature scheme is!

 

[Buadhai]

I should clarify how I ended up handling the "distressingly old OpenSSH" on the host.

I had originally made a global change (in /etc/ssh/ssh_config) but it was suggested that I should do this on a per host basis. So, I did it in /Users/me/.ssh/config which now has an entry like this:

host my_web_host
   HostName mydomain.com
   User my_user
   Port 22
   HostKeyAlgorithms +ssh-rsa
   PubkeyAcceptedKeyTypes +ssh-rsa

This works, but I sure wish I understood all of this a bit better.

 

[dono42]

According to the release notes Openssh at 8.8/8.8p1 or newer is going to stop SHA-1 connections. The version in Monterey is 8.6p1 and Ventura is 9.0p1. Doing anything from Ventura is not compatible with older MacOS. The recommendation from Openssh is;

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