Re: Suggested way to ssh into obsolete devices (with old ssh crypto)?
On Tue, Jul 06, 2021 at 11:06:22PM -0400, Stefan Monnier wrote:
> > I'm aware of that. My critique was specific to the "we take it out
> > because it's dangerous to the user" part.
>
> That's often an explanation but not the main motivation.
That would be even worse :)
The reason I'm "in" free software comes from the realisation that the
programmer has often "too much" power over their users. Imposing policy
decisions on the users ("this way of rendering fonts looks ugly", "that
sort of key management is insecure") is unavoidable: we do take many
of those decisions at a subconscient level. But I think as programmers
we have the responsibiblty to avoid that the best we can.
> For the `none` cipher, I think it was, tho.
>
> IIRC the problem was that using the `none` cipher causes the
> authentication to be exposed in a way that is worse than using Telnet:
> with Telnet you only expose the data you send to the wire, whereas with
> SSH's `none` cipher you ended up exposing the data plus your
> (valued) credentials.
AFAIK Telnet also sends the login sequence in the clear over the
network (to be more precise: my dusty memory says that Telnet isn't
even in the auth business -- it connects you to something which
does the authentication, all in the clear). Unless you are talking
about RFC2491 and friends -- I doubt they have seen widespread
use, SSH having taken over in the 2000s anyway.
> > I'm torn on this one... Sometimes I've the impression that this leads to
> > asocial software [...]
> Indeed, it has its downsides.
Interesting times :)
Cheers
- t
signature.asc
Description: Digital signature
Re: Suggested way to ssh into obsolete devices (with old ssh crypto)?
> I'm aware of that. My critique was specific to the "we take it out > because it's dangerous to the user" part. That's often an explanation but not the main motivation. For the `none` cipher, I think it was, tho. IIRC the problem was that using the `none` cipher causes the authentication to be exposed in a way that is worse than using Telnet: with Telnet you only expose the data you send to the wire, whereas with SSH's `none` cipher you ended up exposing the data plus your (valued) credentials. > I'm torn on this one... Sometimes I've the impression that this leads to > asocial software (i.e. nobody goes to any effort to make their software > compatible to reasonable ranges of library (and other dependencies's) > versions). > Akin to the Flatpaks and Snaps of this world, perhaps with a less horrible > dependencies management story). Indeed, it has its downsides. Stefan
Re: Suggested way to ssh into obsolete devices (with old ssh crypto)?
>> It's entirely too common for obsolete encryption options that are >> kept for "compatibility" end up being a vector for compromise, and >> entirely reasonable to remove such options in order to provide the >> most secure and maintainable tool for the vast majority of users. > That's the attitude of authoritarian software: "my software is smarter > than you". I think the reality is a bit more subtle ;-) In most cases, the real driver is a desire to keep the code simple and to ease maintenance. Removal of old, little used, and largely untested functionality is part of what can be done for that. >> If you want ancient crypto options, just run an ancient binary. >> They're very easy to find in archive.debian.org. > They're not as easy to run as soon as they start being outrun by > their dependencie's versions, and you perfectly know that. My experience running old Debian packages of Emacs under Debian testing is not that bad. Also, I think that if it's hard to do, it can be blamed on Debian's package management (which should move towards something more like NixOS to solve those problems). Stefan
Re: Suggested way to ssh into obsolete devices (with old ssh crypto)?
>> If they have buffer overflow-style holes, those should be fixed. >> Other than that I can't see how they can be less secure than the "none" >> cipher. > I guess since the "none" cipher isn't supported in debian's ssh Good point. > you will just drop this questionable line of argument? It just moves it to first arguing in favor of supporting `none`. Stefan
Re: Suggested way to ssh into obsolete devices (with old ssh crypto)?
On 7/6/21, Ralph Aichinger wrote: > Hi, everybody, as a bullseye user I am seeing messages like > > | Unable to negotiate with 10.0.17.52 port 22: no matching > | key exchange method found. Their offer: diffie-hellman-group1-sha1 > > with increasing frequency, especially when trying to ssh into > proprietary, obsolete stuff. Above comes from a Cisco 7941 IP > phone I toy around with at home, with no expectation of security > whatsoever, I might as well use telnet. > > Some algorithms can be activated by using e.g. > -oKexAlgorithms=+diffie-hellman-group1-sha1 > but I suppose it is only a question of time before some of this > really old and insecure stuff is compiled out or removed from > sources. It is also a bit difficult to find working combinations > of keyexchange algorithms and ciphers for unknown older servers > (a lot of trial and error?). "ssh -v" might tell you enough about what's missing. And then ssh -Q kex to show available key exchange algorithms, and ssh -Q cipher to show available ciphers > What is the suggested way to work around that problem? I like adding that stuff in the ~/.ssh/config file - ref. man ssh_config for example: $ head ~/.ssh/config Host cerberus 10.10.2.1 User dante KexAlgorithms +diffie-hellman-group1-sha1 # ssh -Q kex # show available key exchange algorithms > What I do not want to do is change my "normal" configuration, e.g. > add these algorithms to my normal .ssh/config. Put all the special cases at the top of the config file and all of the "normal" config stuff at the end, under Host * Regards, Lee
Re: Suggested way to ssh into obsolete devices (with old ssh crypto)?
I have a slightly different question about this issue. when open ssh decided that dh keys, for public and global use were somehow insecure, the ssh tool I use, sshdos, became limited allowing me to reach shellworld, but not say the Linux shell provided with our office dreamhost account any longer. Sshdos incorporates some Linux elements in the code, putty as well. Could a few still secure dh keys be coded in, happy to compensate someone for the work, thereby allowing the program to be an option again? say for those with the freedos project? If not, is there a cla tool that might be coded for DOS resulting in the same solution? Thanks, Karen
Re: Suggested way to ssh into obsolete devices (with old ssh crypto)?
On Tue, Jul 06, 2021 at 05:30:27PM -0400, Stefan Monnier wrote: [...] > > That's the attitude of authoritarian software: "my software is smarter > > than you". > > I think the reality is a bit more subtle ;-) > > In most cases, the real driver is a desire to keep the code simple and > to ease maintenance. Removal of old, little used, and largely untested > functionality is part of what can be done for that. I'm aware of that. My critique was specific to the "we take it out because it's dangerous to the user" part. [...] > My experience running old Debian packages of Emacs under Debian testing > is not that bad. Also, I think that if it's hard to do, it can be > blamed on Debian's package management (which should move towards > something more like NixOS to solve those problems). I'm torn on this one... Sometimes I've the impression that this leads to asocial software (i.e. nobody goes to any effort to make their software compatible to reasonable ranges of library (and other dependencies's) versions). Akin to the Flatpaks and Snaps of this world, perhaps with a less horrible dependencies management story). Cheers - t signature.asc Description: Digital signature
Re: Suggested way to ssh into obsolete devices (with old ssh crypto)?
On Tue, Jul 06, 2021 at 04:45:50PM -0400, Michael Stone wrote: [...] > This is ridiculous [...] Let's simply agree to differ. Cheers - t signature.asc Description: Digital signature
Re: Suggested way to ssh into obsolete devices (with old ssh crypto)?
>> I think the first reaction should be to report it as a bug, so that the >> old cipher is re-added. I think the same argument in favor of including >> the "none" cipher should apply to including old deprecated ciphers. > The old ciphers are generally removed for a reason: because they are hugely > insecure. If they have buffer overflow-style holes, those should be fixed. Other than that I can't see how they can be less secure than the "none" cipher. I fully agree with removing them from the list of cipher that will be automatically chosen for you. But keeping them available upon explicit request for those cases where it's the only cipher that works with a particular other device makes a lot of sense. Stefan
Re: Suggested way to ssh into obsolete devices (with old ssh crypto)?
On Tue, Jul 06, 2021 at 10:18:44PM +0200, to...@tuxteam.de wrote: On Tue, Jul 06, 2021 at 02:11:21PM -0400, Michael Stone wrote: [...] It's entirely too common for obsolete encryption options that are kept for "compatibility" end up being a vector for compromise, and entirely reasonable to remove such options in order to provide the most secure and maintainable tool for the vast majority of users. That's the attitude of authoritarian software: "my software is smarter than you". The authors are free to hold that position, but so am I to utterly dislike it. This is ridiculous. If you want something that the maintainers think is unsafe to put in the mainstream distribution you're perfectly free to add (and maintain it) yourself. That's what free software is all about. I personally utterly dislike when people demand that other people provide them with things. But hey, it's a free world--dislike whatever you want. The only authoritarian thing here is people trying to tell other people what they need to put in the software they maintain. If you want ancient crypto options, just run an ancient binary. They're very easy to find in archive.debian.org. They're not as easy to run as soon as they start being outrun by their dependencie's versions, and you perfectly know that. So you want to run obsolete proprietary hardware with no upgrade path, and also complain that the free software is too hard and/or that the ability to make the free software do exactly what you want isn't "easy" enough for you. Seems legit. Just to be sure that I wasn't dreaming that this wasn't actually a big deal, I just grabbed the openssh-client deb for etch from the archive, along with the library dependencies that couldn't be installed from bullseye (libssl, libkrb5) and it worked fine. If I copy the binary to ssh-oldasdirt and reinstall the current openssh, I can use either the current ssh or ssh-oldasdirt with no issues. If you want it easier than that I'm sure you can hire someone to make a custom repository or even rebuild the old package with a non-conflicting name like ssh-oldasdirt or whatever. Of course, the real answer is to not purchase products with "secure" management that can't be upgraded when it becomes "insecure" management. See above. To me, this is a dangerous antipattern. To me, leaving obsolete crypto in a security tool is an antipattern. Experience has shown again and again that this results in security bugs, sometimes really significant ones. Maintainers of such tools need to be responsible in what they release, even if there's a vocal minority that complains about it. The openssh team does a pretty good job of publishing a deprecation schedule *and* sticking to it.
Re: Suggested way to ssh into obsolete devices (with old ssh crypto)?
On Tue, Jul 06, 2021 at 02:11:21PM -0400, Michael Stone wrote: [...] > It's entirely too common for obsolete encryption options that are > kept for "compatibility" end up being a vector for compromise, and > entirely reasonable to remove such options in order to provide the > most secure and maintainable tool for the vast majority of users. That's the attitude of authoritarian software: "my software is smarter than you". The authors are free to hold that position, but so am I to utterly dislike it. > If you want ancient crypto options, just run an ancient binary. > They're very easy to find in archive.debian.org. They're not as easy to run as soon as they start being outrun by their dependencie's versions, and you perfectly know that. > Of course, the real answer is to not purchase products with "secure" > management that can't be upgraded when it becomes "insecure" > management. See above. To me, this is a dangerous antipattern. Cheers - t signature.asc Description: Digital signature
Re: Suggested way to ssh into obsolete devices (with old ssh crypto)?
> Like you, I have been using CLI options to the ssh command to adjust the > necessary algorithms if I need something "insecure". You should be able to set that option for a specific (set of) hosts in .ssh/config so you don't have to repeat it on the CLI every time. > My thought is that once that no longer serves the purpose, I would > setup a VM, container, I think the first reaction should be to report it as a bug, so that the old cipher is re-added. I think the same argument in favor of including the "none" cipher should apply to including old deprecated ciphers. Stefan
Re: Suggested way to ssh into obsolete devices (with old ssh crypto)?
On Tue, Jul 06, 2021 at 03:20:43PM -0400, Stefan Monnier wrote: If they have buffer overflow-style holes, those should be fixed. Other than that I can't see how they can be less secure than the "none" cipher. I guess since the "none" cipher isn't supported in debian's ssh Good point. you will just drop this questionable line of argument? It just moves it to first arguing in favor of supporting `none`. Luckily for the majority of users, the ssh devs aren't likely to suddenly decide to reduce the security of ssh no matter how loudly someone asks them to. Really, if you don't care about security just use telnet.
Re: Suggested way to ssh into obsolete devices (with old ssh crypto)?
On Tue, Jul 06, 2021 at 02:16:53PM -0400, Roberto C. Sánchez wrote: Of course, the real answer is to not purchase products with "secure" management that can't be upgraded when it becomes "insecure" management. Sadly, this is not always possible. There are times where someone else decides what hardware and such will be used or when older hardware cannot be upgrade for some reason or another. In that sense, your suggestion isn't a "real answer", but rather an answer that depends upon a reality that does not exist for everyone. You make continuous decisions about what to buy, what to use, and what to support. I guess it's just easier to complain that the free OS isn't supporting the unsupported proprietary stuff well enough. But again, unless you're just complaining for the sake of complaining, you can simply run an old binary to support the old junk.
Re: Suggested way to ssh into obsolete devices (with old ssh crypto)?
On Tue, Jul 06, 2021 at 02:11:21PM -0400, Michael Stone wrote: > > If you want ancient crypto options, just run an ancient binary. They're very > easy to find in archive.debian.org. > Thankfully, Debian makes this sort of thing about as painless as it can be. > Of course, the real answer is to not purchase products with "secure" > management that can't be upgraded when it becomes "insecure" management. > Sadly, this is not always possible. There are times where someone else decides what hardware and such will be used or when older hardware cannot be upgrade for some reason or another. In that sense, your suggestion isn't a "real answer", but rather an answer that depends upon a reality that does not exist for everyone. Regards, -Roberto -- Roberto C. Sánchez
Re: Suggested way to ssh into obsolete devices (with old ssh crypto)?
On Tue, Jul 06, 2021 at 08:05:11PM +0200, to...@tuxteam.de wrote: On Tue, Jul 06, 2021 at 01:43:07PM -0400, Michael Stone wrote: On Tue, Jul 06, 2021 at 01:02:49PM -0400, Stefan Monnier wrote: >>>I think the first reaction should be to report it as a bug, so that the >>>old cipher is re-added. I think the same argument in favor of including >>>the "none" cipher should apply to including old deprecated ciphers. >>The old ciphers are generally removed for a reason: because they are hugely >>insecure. > >If they have buffer overflow-style holes, those should be fixed. >Other than that I can't see how they can be less secure than the "none" cipher. I guess since the "none" cipher isn't supported in debian's ssh you will just drop this questionable line of argument? FWIW, I fully agree with Stefan on this. We've seen a pretty valid reason for keeping old ciphers. Move them out of the way, so that people don't use them by accident. Refuse to downgrade to an insecure cipher at the other side's request. Heck, have one option named i-really-want-to-have-an-insecure-cipher-honestly or something. It's entirely too common for obsolete encryption options that are kept for "compatibility" end up being a vector for compromise, and entirely reasonable to remove such options in order to provide the most secure and maintainable tool for the vast majority of users. If you want ancient crypto options, just run an ancient binary. They're very easy to find in archive.debian.org. Of course, the real answer is to not purchase products with "secure" management that can't be upgraded when it becomes "insecure" management.
Re: Suggested way to ssh into obsolete devices (with old ssh crypto)?
On Tue, Jul 06, 2021 at 01:43:07PM -0400, Michael Stone wrote: > On Tue, Jul 06, 2021 at 01:02:49PM -0400, Stefan Monnier wrote: > >>>I think the first reaction should be to report it as a bug, so that the > >>>old cipher is re-added. I think the same argument in favor of including > >>>the "none" cipher should apply to including old deprecated ciphers. > >>The old ciphers are generally removed for a reason: because they are hugely > >>insecure. > > > >If they have buffer overflow-style holes, those should be fixed. > >Other than that I can't see how they can be less secure than the "none" > >cipher. > > I guess since the "none" cipher isn't supported in debian's ssh you > will just drop this questionable line of argument? FWIW, I fully agree with Stefan on this. We've seen a pretty valid reason for keeping old ciphers. Move them out of the way, so that people don't use them by accident. Refuse to downgrade to an insecure cipher at the other side's request. Heck, have one option named i-really-want-to-have-an-insecure-cipher-honestly or something. Cheers - t signature.asc Description: Digital signature
Re: Suggested way to ssh into obsolete devices (with old ssh crypto)?
On Tue, Jul 06, 2021 at 01:02:49PM -0400, Stefan Monnier wrote: I think the first reaction should be to report it as a bug, so that the old cipher is re-added. I think the same argument in favor of including the "none" cipher should apply to including old deprecated ciphers. The old ciphers are generally removed for a reason: because they are hugely insecure. If they have buffer overflow-style holes, those should be fixed. Other than that I can't see how they can be less secure than the "none" cipher. I guess since the "none" cipher isn't supported in debian's ssh you will just drop this questionable line of argument?
Re: Suggested way to ssh into obsolete devices (with old ssh crypto)?
On Tue, Jul 06, 2021 at 12:05:41PM -0400, Stefan Monnier wrote: > > Like you, I have been using CLI options to the ssh command to adjust the > > necessary algorithms if I need something "insecure". > > You should be able to set that option for a specific (set of) hosts in > .ssh/config so you don't have to repeat it on the CLI every time. > > > My thought is that once that no longer serves the purpose, I would > > setup a VM, container, > > I think the first reaction should be to report it as a bug, so that the > old cipher is re-added. I think the same argument in favor of including > the "none" cipher should apply to including old deprecated ciphers. > > > Stefan > The old ciphers are generally removed for a reason: because they are hugely insecure. I wouldn't ask for the old ciphers to be re-added to a new version of ssh. Just my €0.02 Andy Cater
Re: Suggested way to ssh into obsolete devices (with old ssh crypto)?
On Tue, Jul 06, 2021 at 10:40:00AM +0200, Ralph Aichinger wrote: > Hi, everybody, as a bullseye user I am seeing messages like > > | Unable to negotiate with 10.0.17.52 port 22: no matching > | key exchange method found. Their offer: diffie-hellman-group1-sha1 > > with increasing frequency, especially when trying to ssh into > proprietary, obsolete stuff. Above comes from a Cisco 7941 IP > phone I toy around with at home, with no expectation of security > whatsoever, I might as well use telnet. > > Some algorithms can be activated by using e.g. > -oKexAlgorithms=+diffie-hellman-group1-sha1 > but I suppose it is only a question of time before some of this > really old and insecure stuff is compiled out or removed from > sources. It is also a bit difficult to find working combinations > of keyexchange algorithms and ciphers for unknown older servers > (a lot of trial and error?). > > What is the suggested way to work around that problem? Download > ssh sources from 15 years ago, and build a "ssh-insecure" binary? > > What I do not want to do is change my "normal" configuration, e.g. > add these algorithms to my normal .ssh/config. > > I suppose I am not the only one or first to have this problem, > is there an elegant solution, that does not compromise security > in the dominating normal case (ssh into modern servers)? > Like you, I have been using CLI options to the ssh command to adjust the necessary algorithms if I need something "insecure". My thought is that once that no longer serves the purpose, I would setup a VM, container, or chroot running Debian wheezy or jessie and then use the ssh command from that environment. Regards, -Roberto -- Roberto C. Sánchez
Re: Suggested way to ssh into obsolete devices (with old ssh crypto)?
On Tue, Jul 06, 2021 at 10:40:00AM +0200, Ralph Aichinger wrote: > Hi, everybody, as a bullseye user I am seeing messages like > > | Unable to negotiate with 10.0.17.52 port 22: no matching > | key exchange method found. Their offer: diffie-hellman-group1-sha1 > > with increasing frequency, especially when trying to ssh into > proprietary, obsolete stuff. Above comes from a Cisco 7941 IP > phone I toy around with at home, with no expectation of security > whatsoever, I might as well use telnet. > > Some algorithms can be activated by using e.g. > -oKexAlgorithms=+diffie-hellman-group1-sha1 > but I suppose it is only a question of time before some of this > really old and insecure stuff is compiled out or removed from > sources. It is also a bit difficult to find working combinations > of keyexchange algorithms and ciphers for unknown older servers > (a lot of trial and error?). > > What is the suggested way to work around that problem? Download > ssh sources from 15 years ago, and build a "ssh-insecure" binary? > > What I do not want to do is change my "normal" configuration, e.g. > add these algorithms to my normal .ssh/config. > > I suppose I am not the only one or first to have this problem, > is there an elegant solution, that does not compromise security > in the dominating normal case (ssh into modern servers)? > > Thanks in advance, > Ralph > This also works the other way round: other older Linux [CentOS/Red Hat] can't work with Microsoft Windows or things expecting newer cipher suites One way round is to keep a separate ssh config with manually edited lists of what ciphers work with what - but it is not straightforward. This will only get worse as we move to elliptic key, potentially. All the best, Andy C
