Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #236954 > unrolled thread

Suggested way to ssh into obsolete devices (with old ssh crypto)?

Back to article view | Back to linux.debian.user

Contents

  Suggested way to ssh into obsolete devices (with old ssh crypto)? Ralph Aichinger <ra@pi.h5.or.at> - 2021-07-06 11:10 +0200
    Re: Suggested way to ssh into obsolete devices (with old ssh crypto)? "Andrew M.A. Cater" <amacater@einval.com> - 2021-07-06 11:30 +0200
    Re: Suggested way to ssh into obsolete devices (with old ssh crypto)? Roberto C. Sánchez <roberto@debian.org> - 2021-07-06 15:00 +0200
      Re: Suggested way to ssh into obsolete devices (with old ssh crypto)? Stefan Monnier <monnier@iro.umontreal.ca> - 2021-07-06 18:10 +0200
        Re: Suggested way to ssh into obsolete devices (with old ssh crypto)? "Andrew M.A. Cater" <amacater@einval.com> - 2021-07-06 18:40 +0200
          Re: Suggested way to ssh into obsolete devices (with old ssh crypto)? Stefan Monnier <monnier@iro.umontreal.ca> - 2021-07-06 19:10 +0200
            Re: Suggested way to ssh into obsolete devices (with old ssh crypto)? Michael Stone <mstone@debian.org> - 2021-07-06 19:50 +0200
              Re: Suggested way to ssh into obsolete devices (with old ssh crypto)? <tomas@tuxteam.de> - 2021-07-06 20:10 +0200
                Re: Suggested way to ssh into obsolete devices (with old ssh crypto)? Michael Stone <mstone@debian.org> - 2021-07-06 20:20 +0200
                  Re: Suggested way to ssh into obsolete devices (with old ssh crypto)? Roberto C. Sánchez <roberto@debian.org> - 2021-07-06 20:20 +0200
                    Re: Suggested way to ssh into obsolete devices (with old ssh crypto)? Michael Stone <mstone@debian.org> - 2021-07-06 20:40 +0200
                  Re: Suggested way to ssh into obsolete devices (with old ssh crypto)? <tomas@tuxteam.de> - 2021-07-06 22:20 +0200
                    Re: Suggested way to ssh into obsolete devices (with old ssh crypto)? Michael Stone <mstone@debian.org> - 2021-07-06 22:50 +0200
                      Re: Suggested way to ssh into obsolete devices (with old ssh crypto)? <tomas@tuxteam.de> - 2021-07-06 23:50 +0200
                    Re: Suggested way to ssh into obsolete devices (with old ssh crypto)? Stefan Monnier <monnier@iro.umontreal.ca> - 2021-07-06 23:40 +0200
                      Re: Suggested way to ssh into obsolete devices (with old ssh crypto)? <tomas@tuxteam.de> - 2021-07-07 00:00 +0200
                        Re: Suggested way to ssh into obsolete devices (with old ssh crypto)? Stefan Monnier <monnier@iro.umontreal.ca> - 2021-07-07 05:10 +0200
                          Re: Suggested way to ssh into obsolete devices (with old ssh crypto)? <tomas@tuxteam.de> - 2021-07-07 10:00 +0200
                    Re: Suggested way to ssh into obsolete devices (with old ssh crypto)? Karen Lewellen <klewellen@shellworld.net> - 2021-07-07 00:00 +0200
              Re: Suggested way to ssh into obsolete devices (with old ssh crypto)? Stefan Monnier <monnier@iro.umontreal.ca> - 2021-07-06 21:30 +0200
                Re: Suggested way to ssh into obsolete devices (with old ssh crypto)? Michael Stone <mstone@debian.org> - 2021-07-06 21:30 +0200
    Re: Suggested way to ssh into obsolete devices (with old ssh crypto)? Lee <ler762@gmail.com> - 2021-07-07 01:20 +0200

Page 1 of 2  [1] 2  Next page →

#236954 — Suggested way to ssh into obsolete devices (with old ssh crypto)?

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

[toc] | [next] | [standalone]

#236956

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

[toc] | [prev] | [next] | [standalone]

#236966

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

[toc] | [prev] | [next] | [standalone]

#236971

> 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

[toc] | [prev] | [next] | [standalone]

#236972

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

[toc] | [prev] | [next] | [standalone]

#236973

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

[toc] | [prev] | [next] | [standalone]

#236975

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?

[toc] | [prev] | [next] | [standalone]

#236976

[Multipart message — attachments visible in raw view] — view raw

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

[toc] | [prev] | [next] | [standalone]

#236977

On Tue, Jul 06, 2021 at 08:05:11PM +0200, tomas@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.

[toc] | [prev] | [next] | [standalone]

#236978

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

[toc] | [prev] | [next] | [standalone]

#236979

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.

[toc] | [prev] | [next] | [standalone]

#236983

[Multipart message — attachments visible in raw view] — view raw

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

[toc] | [prev] | [next] | [standalone]

#236985

On Tue, Jul 06, 2021 at 10:18:44PM +0200, tomas@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.

[toc] | [prev] | [next] | [standalone]

#236989

[Multipart message — attachments visible in raw view] — view raw

On Tue, Jul 06, 2021 at 04:45:50PM -0400, Michael Stone wrote:

[...]

> This is ridiculous [...]

Let's simply agree to differ.

Cheers
 - t

[toc] | [prev] | [next] | [standalone]

#236988

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

[toc] | [prev] | [next] | [standalone]

#236990

[Multipart message — attachments visible in raw view] — view raw

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

[toc] | [prev] | [next] | [standalone]

#237000

> 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

[toc] | [prev] | [next] | [standalone]

#237003

[Multipart message — attachments visible in raw view] — view raw

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

[toc] | [prev] | [next] | [standalone]

#236991

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

[toc] | [prev] | [next] | [standalone]

#236981

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

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | linux.debian.user

csiph-web