similar to: An update on SSH protocol 1

On Tue, 3 May 2016, Colin Watson wrote: > Debian takes the latter approach. Specifically, we have an > "openssh-client-ssh1" binary package that includes only scp1, ssh1, and > ssh-keygen1 binaries; we do not ship any server-side SSHv1 support. I > modelled this on Fedora's approach, which is basically the same aside > from a slightly different package name. >

https://bugzilla.mindrot.org/show_bug.cgi?id=2523 Bug ID: 2523 Summary: An RSA private key file consistently gives "Badd Passphrase" errors, but worked before Product: Portable OpenSSH Version: 7.1p1 Hardware: Other OS: Linux Status: NEW Severity: normal Priority:

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

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

http://bugzilla.mindrot.org/show_bug.cgi?id=248 Summary: scp doesn't support ssh2 protocol Product: Portable OpenSSH Version: -current Platform: Other OS/Version: other Status: NEW Severity: normal Priority: P2 Component: scp AssignedTo: openssh-unix-dev at mindrot.org ReportedBy: liug

https://bugzilla.mindrot.org/show_bug.cgi?id=2519 Bug ID: 2519 Summary: Obsolete SSHv1 config options Product: Portable OpenSSH Version: 7.1p1 Hardware: Other OS: Linux Status: NEW Severity: enhancement Priority: P5 Component: ssh Assignee: unassigned-bugs at mindrot.org

http://bugzilla.mindrot.org/show_bug.cgi?id=88 ------- Additional Comments From markus at openbsd.org 2002-01-31 23:01 ------- this is an installation error on the target host, see: scp: warning: Executing scp1 compatibility. scp: FATAL: Executing ssh1 in compatibility mode failed (Check that scp1 is in your PATH). ------- You are receiving this mail because: ------- You are the assignee

OpenSSH still has this feature, SSH-1.2.27 no longer has it. Admittedly it can be useful sometimes, even though I'd prefer this to be done using a trivial shell wrapper, which would be the UNIX way of doing things. Not being able to call OpenSSH's ssh by another name (say ``ssh1'') can get in the way when having to maintain two versions of ssh in parallel because the ``ssh ->

Hi! I was browsing through archives and found out that somebody else was having the same problem as I'm. http://bugzilla.mindrot.org/show_bug.cgi?id=248 from the client, when I run scp to the server, I get: scp: warning: Executing scp1 compatibility. scp: FATAL: Executing ssh1 in compatibility mode failed (Check that scp1 is in your PATH). There are more details about this problem here:

Am I missing something obvious or does the scp in openssh not interoperate with the scp in ssh-2.4? I don't have any ssh-2.4 systems but a user here trying to fetch a file from a site which uses it (and doesn't have scp1 gets): scp -o 'protocol 2' -o 'loglevel debug3' -v herrada at eurus2.us.es:tf19.dat

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.

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.

Hi, I just deleted SSHv1 support in OpenBSD and portable OpenSSH. There's probably a little dead code still to be expunged, but all user-visible functionality and the bulk of the supporting infrastructure is gone. Sic transit gloria mundi. -d

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,

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

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

Hi all! I was scanning my servers with nmap, ( i have installed ssh), and the result gave me this: 22/tcp open ssh sshv1: Server Supports SSHv1 ssh-keyhost: 1024 ea:7e:77:b7:a1:78:18:70:6c:46:ee:a0:dd:08:0e:74 (RSA1) 1024 ba:d0:8a:44:16:fc:7c:7a:38:24:2e:72:06:fe:99:56 (DSA) 1024 ff:43:15:78:98:3c:75:f9:12:36:58:92:46:6c:1c:99 (RSA) could this be a threat for intruders? i know that sshv1

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

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