Displaying 20 results from an estimated 9000 matches similar to: "Corrupted check bytes on input with SSH1 - OpenSSH-4.3 and OpenSSL-0.9.6b"
2001 Jan 09
1
sshd: DES in SSH1 ?
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
2003 Nov 06
3
SSH1 vs. SSH2 - compression level
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
2010 Feb 09
0
[Bug 1712] New: partial server keep-alive implementation for SSH1
https://bugzilla.mindrot.org/show_bug.cgi?id=1712
Summary: partial server keep-alive implementation for SSH1
Product: Portable OpenSSH
Version: 5.3p1
Platform: Other
OS/Version: Linux
Status: NEW
Severity: enhancement
Priority: P2
Component: ssh
AssignedTo: unassigned-bugs at mindrot.org
2002 May 28
1
'Corrupted check bytes on input' when connecting to 1.2.30 server
Hello,
I get this error when trying to connect to an ancient server from the 3.2.3p1
client on Linux 2.2 (OpenSSL 0.9.5):
[root at XXX openssh-3.2.3p1]# /usr/local/bin/ssh -vv LOGIN_STRIPPED at decef.elf.stuba.sk
OpenSSH_3.2.3p1, SSH protocols 1.5/2.0, OpenSSL 0x0090581f
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Rhosts Authentication disabled,
2011 Jan 31
1
Generate SSH1 host key by default?
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
2015 Mar 26
2
FYI: SSH1 now disabled at compile-time by default
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
2002 May 12
3
[Bug 138] Incorrect OpenSSL version requirment?
http://bugzilla.mindrot.org/show_bug.cgi?id=138
patl at cag.lcs.mit.edu changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|RESOLVED |REOPENED
Resolution|FIXED |
------- Additional Comments From patl at cag.lcs.mit.edu 2002-05-13 00:55
2015 Mar 26
4
FYI: SSH1 now disabled at compile-time by default
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
2001 Feb 08
0
[CORE SDI ADVISORY] SSH1 CRC-32 compensation attack detector vulnerability
CORE SDI
http://www.core-sdi.com
SSH1 CRC-32 compensation attack detector vulnerability
Date Published: 2001-02-08
Advisory ID: CORE-20010207
Bugtraq ID: 2347
CVE CAN: CAN-2001-0144
Title: SSH1 CRC-32 compensation attack detector vulnerability
Class: Boundary Error Condition
Remotely Exploitable: Yes
Locally Exploitable: Yes
Release Mode:
2001 Sep 08
1
force SSH1 and SSH2
This is small patch for scp. It allows to force SSH1 or SSH2.
P.S.: give me Cc: - I'm not subscribed...
--
---------------------------------
pozdr. Pawe? Go?aszewski
---------------------------------
R.I.P. - rest in pieces ...
-------------- next part --------------
--- ./scp.c.org Sat Sep 8 23:37:22 2001
+++ ./scp.c Sun Sep 9 00:07:36 2001
@@ -244,9 +244,11 @@
2015 Mar 22
5
[Bug 2369] New: `ssh-keygen -A` errors on RSA1 when building with SSH1 disabled
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
2015 Jan 23
9
[Bug 2343] New: test_fuzz.c won't compile if ssh1 support is disabled
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:
2003 May 28
2
SSH1 security with Kerb5
Hi,
I am trying to decide if it is worth the time to test the Kerberos support in a port I am working on of Openssh 3.5p1.
Does using Kerb5 with SSH1 solve the security problems inherent in protocol 1 and bring it up to par with the security level of SSH2 or are there other issues that Kerb5 authentication won't help for SSH1?
Thanks,
Greg Lambert
---------------------------------
Do
2006 Sep 14
6
sshd audit not happy with ssh1 and scp
I think I've found a bug with sshd handling audit events for commands (like
scp) over ssh1 connections. Specifically, after updating to a recent FreeBSD
6.x with audit support, I'm getting log messages like these when using scp
over ssh1:
Sep 12 14:13:16 <auth.info> bm55 sshd[12335]: Accepted rsa for xxx from
A.B.C.D port 2981
Sep 12 14:13:16 <auth.crit> bm55 sshd[12335]:
2002 May 15
3
ssh3 with ssh1
On Solaris 8, I have ssh 3.1.0 and on other box Sol 7 I have 1.2.26 (min
version for comtable with ssh 3), I checked also /etc/ssh2/sshd2_config
file
## SSH1 compatibility
# Ssh1Compatibility <set by configure by default>
# Sshd1Path <set by configure by default
2) generate key for ssh3 # ssh-keygen2 -P /etc/ssh2/hostkey
2016 Aug 03
2
Configure option '--with-ssh1' breaks openssh-7.3p1
On 08/03/16 03:19, Darren Tucker wrote:
>
> Yes. Debugging something on a system you can't interact with is hard
> enough without having information withheld.
>
I'll run again and add the relevant unedited texts as attachments.
There is nothing in /var/log/secure.
Also a diff between the config.h 's without and with --with-ssh1 is
attached.
I have a centos-6.7 under
2002 Jun 28
0
[Bug 138] Incorrect OpenSSL version requirment?
http://bugzilla.mindrot.org/show_bug.cgi?id=138
------- Additional Comments From rob at adso.com.pl 2002-06-29 07:46 -------
Created an attachment (id=121)
Patch for openssh 3.4p1, which corrects problems with blowfish + ssh1 + OpenSSL 0.9.5a
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
2003 Mar 31
1
resource leak in ssh1 challenge-response authentication
If an ssh1 client initiates challenge-response authentication but does
not submit a response to the challenge, and instead switches to some
other authentication method, verify_response() will never run, and the
kbdint device context will never be freed. In some cases (such as
when the FreeBSD PAM authentication code is being used) this may cause
a resource leak leading to a denial of service.
2016 Aug 03
2
Configure option '--with-ssh1' breaks openssh-7.3p1
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
2015 Mar 26
2
FYI: SSH1 now disabled at compile-time by default
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.