openssh @9.8p1 broke some key types

[fhgwright (Fred Wright)]

MacPro:~ fw$ ssh localhost
/Users/fw/.ssh/config line 77: Bad key types '+ssh-rsa,ssh-dss'.
/Users/fw/.ssh/config line 78: Bad key types '+ssh-rsa,ssh-dss'.
/Users/fw/.ssh/config: terminating, 2 bad configuration options

I think these are still supported, but not by default. And of course, any intentional change of this type requires lots of notice, given that it affects anywhere that keys are installed.

If this isn't just a config change, then it might be best in the short term to go back to 9.7p1 while applying the security patch (which AIUI is simple).

[fhgwright (Fred Wright)]

BTW, IMO the OpenSSH folks are partly responsible for this, by not releasing a 9.7p2 with just the security fix and no functional changes.

[danielluke (Daniel J. Luke)]

It’s mentioned in the release notes: ​https://www.openssh.com/releasenotes.html

“ OpenSSH has disabled DSA keys by default since 2015 but has retained run-time optional support for them.”

I don’t think we should re-enable the dsa keys that have been default disabled since 2015 (it would just push this problem to next year when they remove the option to compile with support), but I’ll leave it to the maintainer to decide.

[fhgwright (Fred Wright)]

It certainly wasn't well publicized. I didn't become aware of it until yesterday, and I have keys of those types all over the place.

Maybe the announcement to users was on display in the bottom of a locked filing cabinet stuck in a disused lavatory with a sign on the door saying "Beware of the Leopard".

[danielluke (Daniel J. Luke)]

You had to specifically enable accepting dsa keys in config since OpenSSH 7 (back in 2015)

[fhgwright (Fred Wright)]

Where "you" means developers. There was no communication to end users that their existing and widely distributed keys would stop working whenever developers decided not to enable that option.

[danielluke (Daniel J. Luke)]

No, I means end users. As far as I can tell, macports’ shipped ssh config doesn’t contain the bits to enable dsa keys for sshd (server) or ssh (client). To make it work after openssh 7 a person would need to configure as described in ​http://www.openssh.com/legacy.html

[artkiver (グレェ)]

DSA key support will be removed entirely in 2025, it's been disabled by default since 2015.

Also see:

Future deprecation notice
=========================

OpenSSH plans to remove support for the DSA signature algorithm in
early 2025 and compile-time disable it later this year.

DSA, as specified in the SSHv2 protocol, is inherently weak - being
limited to a 160 bit private key and use of the SHA1 digest. Its
estimated security level is only 80 bits symmetric equivalent.

OpenSSH has disabled DSA keys by default since 2015 but has retained
run-time optional support for them. DSA was the only mandatory-to-
implement algorithm in the SSHv2 RFCs[3], mostly because alternative
algorithms were encumbered by patents when the SSHv2 protocol was
specified.

This has not been the case for decades at this point and better
algorithms are well supported by all actively-maintained SSH
implementations. We do not consider the costs of maintaining DSA in
OpenSSH to be justified and hope that removing it from OpenSSH can
accelerate its wider deprecation in supporting cryptography
libraries.

This release makes DSA support in OpenSSH compile-time optional,
defaulting to on. We intend the next release to change the default
to disable DSA at compile time. The first OpenSSH release of 2025
will remove DSA support entirely.

From ​https://www.openssh.com/releasenotes.html#9.7p1

I'd heartily recommend searching through ​https://www.openssh.com/releasenotes.html with the phrase "deprecation" to see if there might have been anything else announced but missed?

[artkiver (グレェ)]

If you want to create a variant that enables DSA support, you're welcome to submit a PR, but I would be against it.

[fhgwright (Fred Wright)]

Replying to danielluke:

No, I means end users. As far as I can tell, macports’ shipped ssh config doesn’t contain the bits to enable dsa keys for sshd (server) or ssh (client). To make it work after openssh 7 a person would need to configure as described in ​http://www.openssh.com/legacy.html

OK, but that just means that a long-forgotten config-file tweak that was made out of necessity years ago has been rendered inoperative with no notice. Normally, something of that form should emit obvious warnings for at least a year before action involving significant effort becomes mandatory.

Disallowing new keys based on a deprecated algorithm is one thing, but failing to support existing keys is quite heavy-handed. Perhaps if the OpenSSH folks spent more time learning how the real world works instead of reintroducing old security bugs, we wouldn't be having this issue.

BTW, claims about OpenSSH 7 and 2015 are wrong, at least in the MacPorts context. The openssh port didn't start requiring the config tweak until 8.8p1, issued in Oct-2021. And oddly enough, I don't see anything in the port diffs from 8.4p1 to 8.8p1 relating to key types.

Another issue is that the old key types are necessary to interoperate with the Apple sshd in OS versions prior to 10.12. And since the mechanism for automatically reloading a previously loaded port after a deactivate/activate is extremely unreliable, any dependence on a MacPorts sshd on a headless system risks rendering it incommunicado after a port upgrade. So one would need to keep the Apple sshd active on a different port, and also keep around an alternate ssh client that doesn't suffer from deprecation disease.

Replying to artkiver:

If you want to create a variant that enables DSA support, you're welcome to submit a PR, but I would be against it.

I don't understand this comment. Are you saying that one is free to create, test, and submit a PR which is guaranteed to be rejected due to maintainer opposition?

BTW, the openssl3 port added a legacy variant for somewhat similar reasons in Nov-2021, only a couple of weeks after openssh @8.8p1 came out with the config-file tweak requirement.

[danielluke (Daniel J. Luke)]

Replying to fhgwright:

OK, but that just means that a long-forgotten config-file tweak that was made out of necessity years ago has been rendered inoperative with no notice.

In order to make the config tweak, you had to read the notice (from upstream).

BTW, claims about OpenSSH 7 and 2015 are wrong, at least in the MacPorts context. The openssh port didn't start requiring the config tweak until 8.8p1, issued in Oct-2021. And oddly enough, I don't see anything in the port diffs from 8.4p1 to 8.8p1 relating to key types.

7.0 disabled dsa (2015) 8.8 disabled ssh-rsa using sha-1 signatures (2021)

MacPorts didn't do anything to enable these and if you continued using them you had to manually change your configuration.

Another issue is that the old key types are necessary to interoperate with the Apple sshd in OS versions prior to 10.12.

OpenSSH since 7.2 (2016) supports ssh-rsa keys with RFC8332 RSA/SHA-256/512 signatures and upgrades existing rsa keys to use the newer signature algorithm where possible.

Replying to artkiver:

If you want to create a variant that enables DSA support, you're welcome to submit a PR, but I would be against it.

I don't understand this comment. Are you saying that one is free to create, test, and submit a PR which is guaranteed to be rejected due to maintainer opposition?

It sounds like the maintainer doesn't like the idea and won't pursue it, but probably would accept it.

[artkiver (グレェ)]

It sounds like the maintainer doesn't like the idea and won't pursue it, but probably would accept it.

That is a correct interpretation. I certainly won't be submitting such a PR myself, but if someone else wants to go against upstream and maintain a variant, I can fathom why.

Regarding, "has been rendered inoperative with no notice."?

I would again draw your attention to the release notes for 9.7p1 excerpted previously, italics for emphasis to help with reading comprehension:

We intend the next release to change the default to disable DSA at compile time.

Notice was given in advance, this is not blind siding anyone who has been paying attention.