similar to: FYI: SSH1 now disabled at compile-time by default

On Tue, 24 Mar 2015, Dan Kaminsky wrote: > Hmm. Feels a little aggressive for ssh client. Support heartily for sshd. People who need it can build their own, or OS vendors might supply a non-default v.1 capable client binary themselves. IMO it's time to apply some selection pressure to a protocol that can't be secured. -d

On Tue, Mar 24, 2015 at 10:37 PM, Dan Kaminsky <dan at doxpara.com> wrote: > On Tuesday, March 24, 2015, Damien Miller <djm at mindrot.org> wrote: > >> On Tue, 24 Mar 2015, Dan Kaminsky wrote: >> >> > Hmm. Feels a little aggressive for ssh client. Support heartily for >> sshd. >> >> People who need it can build their own, or OS vendors

My two-cents removing v1 from the server - excellent. removing it from the client - admirable, but there are many potential operational concerns as mentioned above. I'll chat a bit about personal experience with removal of something as being "more secure" when it's effect is actually lessen "security" Possible solution - even for beyond ? Create a new client that

On Wed, 2015-03-25 at 18:48 +1100, Damien Miller wrote: > Our ability to influence people who run truly obsolete software is > extremely limited. +1, mostly because those who still use something that outdated in their products are either dead, or simply don't care about their customer's security (which is typical in the embedded devices area). Just by us (or anyone else) saying

Hi, On Fri, Mar 27, 2015 at 02:36:50PM +0100, Hubert Kario wrote: > > Same thing with needing sshv1 to access old network gear where even sshv1 > > was an achievement. "Throw away gear that does its job perfectly well, > > but has no sshv2 for *management*" or "keep around an ssh v1 capable > > client"? > > If you depend on hardware like this,

Hi, On Fri, Mar 27, 2015 at 12:53:05PM +0100, Hubert Kario wrote: > On Thursday 26 March 2015 11:19:28 Michael Felt wrote: > > Experience: I have some hardware, on an internal network - that only > > supports 40-bit ssl. I am forced to continue to use FF v17 because that was > > the last browser to provide SSL40-bit support. My security is weakened > > because I cannot

There's a world of difference between changing defaults and killing functionality. SSH in general and OpenSSH in particular is part of what we'll eventually get around to identifying as (I know everyone hates this word) critical infrastructure. That means it doesn't break, particularly not intentionally, and even more particularly not without time, warning, and probably public input.

I mentioned extensions because I had a few and saw them die. the 40-bit ssl is the web interface for power5 (the so-called ASMI https interface). These ports have no access to "outside", on a separate lan segment. my desktop, not acting as router, can connect to non-Natted and NATted segments. re: use of a stunnel - how does this turn 40-bit https into >40-bit https. Sounds like a

No, I just think 15 years or so is more than enough time to have addressed the issue. On Thu, Mar 26, 2015 at 14:05:08 -0700, Dan Kaminsky wrote: > So, this isn't your problem and you don't respect the people's whose > problem it is. > > On Thu, Mar 26, 2015 at 12:43 PM, Iain Morgan <imorgan at nas.nasa.gov> wrote: > > > On Thu, Mar 26, 2015 at 11:55:18

On Thu, Mar 26, 2015 at 10:19:05 -0700, Dan Kaminsky wrote: > Communication is a two way street. If OpenSSH wants to go down the route > of single releases, like the browsers did, it can remove its minor numbers, > like the browsers did. > There's no question of "going down the route." This has been the practice with OpenSSH for many years -- if not from the beginning.

On Thu, Mar 26, 2015 at 11:55:18 -0700, Dan Kaminsky wrote: > You're right. My argument the is the next build of OpenSSH should be > OpenSSH 7, and the one after that 8, then 9, then 10. No minor releases? > Sure, go ahead. Deprecate the point, > > Do you manage any machines running SSHv1? > If by "running" you mean accepting SSH1, of course not. From a

On 26/03, Nico Kadel-Garcia wrote: >Yanking it out wholesale should be part of a 7.0 build, not an >incremental release. That's a major incompatibility with one heck of a >lot of existing code, much of which is on extended support. > And it?s been said multiple times in this thread that the OpenSSH version number is just a incrementing decimal number, it doesn?t have any major

https://bugzilla.mindrot.org/show_bug.cgi?id=2343 Bug ID: 2343 Summary: test_fuzz.c won't compile if ssh1 support is disabled Product: Portable OpenSSH Version: 6.7p1 Hardware: Other OS: Linux Status: NEW Severity: enhancement Priority: P5 Component: Build system Assignee:

OK, with this additional information I can now reproduce it. Based on some quick experiments it seems to be triggered when sshd is built --with-ssh1 and the config does not *load* a Protocol 1 host key. Works: Protocol=1,2 + Hostkey not specified Protocol=1,2 + Hostkeys for both protocols specified. Doesn't work: Protocol=2 + Hostkey not specified. Protocol=1,2 + Hostkeys specified only for

Protocols and ciphers are sunsetted all the time, this is a regular thing, but there are announcements before breaking changes are inserted. You assume people are slow to update anyway; some are, some aren't, what you're doing is wildly rewarding the slow updaters and punishing the fast ones. That has negative effects elsewhere. What would it hurt to announce the release in 3-6 months

https://bugzilla.mindrot.org/show_bug.cgi?id=2369 Bug ID: 2369 Summary: `ssh-keygen -A` errors on RSA1 when building with SSH1 disabled Product: Portable OpenSSH Version: 6.9p1 Hardware: All OS: All Status: NEW Severity: normal Priority: P5 Component: ssh-keygen

I see that commercial SSH version it is possible to run sshd in SSH1 using DES (i.e, accepting SSH-DES clients). I understand from Damien Miller that Cisco routers also run in only SSH1 DES mode. Is it possible in openSSH to configure sshd (compile-time/runtime) to run sshd in SSH1 or SSH2 mode and accept SSH1 or SSH2 DES clients ? [I would like to be able to run sshd in SSH1/DES mode ] Is

Hi, the OpenSSH installation script for Cygwin still creates a SSH1 host key by default. My question is, wouldn't it make more sense to drop all auto-generation of SSH1 keys from the default installation procedure? I mean, nobody should use SSH1 anymore, right? Or should the script stick to it for some reason? Corinna -- Corinna Vinschen Cygwin Project Co-Leader Red Hat

Alright, so I pulled the data from scans.io, There's actually 82,650 devices on the open Internet claiming support for <=SSH-1.5, generally routers. Top 20 on that is: $ head -n 20 ssh1_versions.txt 39148 SSH-1.5-Cisco-1.25 14477 SSH-1.5-HUAWEI-VRP3.1 10571 SSH-1.5-1.0.0 4634 SSH-1.5-HUAWEI-VRP-3.10 3284 SSH-1.5-1.2.33 2965 SSH-1.5-VRP-3.3 1836 SSH-1.5-VRP-3.4 1125

Hello, I was searching for this information virtually everywhere, but as I couldn't find it - I'm asking here. I was wondering, why setting the Compression Level was removed in SSH2, and if on, is always set to 6. In SSH1 it was possible to set the Compression Level from 1 to 9. I have made some tests with Compression Levels using scp: SSH1, compression 9 (highest available for