On Mon, 30 Aug 2021, David Newall wrote:> A lot of equipment, perfectly good equipment, expensive equipment, but > old equipment requires it.? Most of it is behind a security appliance so > there's no real risk is negligible if indeed it's not actually zero. > > Removing DSS removes management access to the equipment and the only > reason is a pedantic complaint that DSS is trivially broken. > > Please don't break equipment over well-meaning pedantry.I bet this (once) expensive equipment still supports telnet, so nothing is being broken. -d
On Mon, 30 Aug 2021, Damien Miller wrote:> I bet this (once) expensive equipment still supports telnet, so > nothing is being broken.Not necessarily. Besides, telnet clients are also in short supply; didn?t OpenBSD remove it from base? It also doesn?t have all those nice features SSH has, file transfer, channels, etc. of which only a subset may actually apply for the appliances but still? bye, //mirabilos -- Infrastrukturexperte ? tarent solutions GmbH Am Dickobskreuz 10, D-53121 Bonn ? http://www.tarent.de/ Telephon +49 228 54881-393 ? Fax: +49 228 54881-235 HRB AG Bonn 5168 ? USt-ID (VAT): DE122264941 Gesch?ftsf?hrer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg **************************************************** /?\ The UTF-8 Ribbon ? ? Campaign against Mit dem tarent-Newsletter nichts mehr verpassen: ? HTML eMail! Also, https://www.tarent.de/newsletter ? ? header encryption! ****************************************************
> > A lot of equipment, perfectly good equipment, expensive equipment, but > > old equipment requires it. Most of it is behind a security appliance so > > there's no real risk is negligible if indeed it's not actually zero. > > > > Removing DSS removes management access to the equipment and the only > > reason is a pedantic complaint that DSS is trivially broken. > > > > Please don't break equipment over well-meaning pedantry. > > I bet this (once) expensive equipment still supports telnet, so > nothing is being broken.even if it doesn't, the idea that someone would assume support of this equipment is the responsibility of the openssh maintainers, rather than the _vendor_, blows my mind. save a statically linked copy of openssh that supports your old crypto, problem solved.
On 30.08.21 05:01, Damien Miller wrote:> On Mon, 30 Aug 2021, David Newall wrote: >> Removing DSS removes management access to the equipment and the only >> reason is a pedantic complaint that DSS is trivially broken. >> >> Please don't break equipment over well-meaning pedantry. > > I bet this (once) expensive equipment still supports telnet, so > nothing is being broken.As long as the definition of "getting broken" covers "things suddenly stop working as they were", it *still* breaks setups where plain TELNET+FTP has been disabled or firewalled in favor of "more secure" SSH. Which doesn't mean that DSS, and thus the firmware's implementation of SSH, should not be considered the thing to have broken *first*, but. On 30.08.21 06:23, Peter Moody wrote:> even if it doesn't, the idea that someone would assume support of this > equipment is the responsibility of the openssh maintainers, rather > than the _vendor_, blows my mind.FWIW, I'm *nowhere* near labeling any specific problem of *mine* a "responsibility* of the OpenSSH developers. Pray tell, though, at what level does "a bunch of somebodies" turn into "a compatibility issue" or "a valid use case" or somesuch? $ cat .ssh/config .ssh/config.d/* | grep -c '^Host' 709 $ cat .ssh/config .ssh/config.d/* | grep dss HostKeyAlgorithms ssh-dss HostKeyAlgorithms ssh-dss HostKeyAlgorithms +ssh-dss HostKeyAlgorithms +ssh-dss HostKeyAlgorithms +ssh-dss HostKeyAlgorithms +ssh-dss (Yes, I already default-disabled DSS on my workplace machine. And no, not all of those six targets are someplace I can easily set up a VPN to, or a VM with a current OpenSSH server in.)> save a statically linked copy of openssh that supports your old > crypto, problem solved.*sigh* Right *now*, I *could* do that ... our auditors have had "version control of *Linux*-based workplace computers, too" on their wishlist for quite a while, though. Regards, -- Jochen Bern Systemingenieur Binect GmbH -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3449 bytes Desc: S/MIME Cryptographic Signature URL: <http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20210830/279d3539/attachment-0001.p7s>