[MacPorts] #70319: openssh @9.8p1 broke some key types

MacPorts noreply at macports.org
Mon Jul 8 01:41:45 UTC 2024


#70319: openssh @9.8p1 broke some key types
------------------------+----------------------
  Reporter:  fhgwright  |      Owner:  artkiver
      Type:  defect     |     Status:  assigned
  Priority:  High       |  Milestone:
 Component:  ports      |    Version:  2.9.3
Resolution:             |   Keywords:
      Port:  openssh    |
------------------------+----------------------

Comment (by fhgwright):

 Replying to [comment:6 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 [comment:9 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.

-- 
Ticket URL: <https://trac.macports.org/ticket/70319#comment:10>
MacPorts <https://www.macports.org/>
Ports system for macOS


More information about the macports-tickets mailing list