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
> 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
>> 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
>> 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
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
>
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
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
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
>> 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
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
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
> 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
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
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
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
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.
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
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
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
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,
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,
21 matches
Mail list logo
