Announce: OpenSSH 4.6 released

Darren Tucker dtucker at
Fri Mar 9 07:25:22 EST 2007

Corinna Vinschen wrote:
> Hi,
> On Mar  7 16:10, Damien Miller wrote:
>> OpenSSH 4.6 has just been released. It will be available from the
>> mirrors listed at shortly.
>> OpenSSH is a 100% complete SSH protocol version 1.3, 1.5 and 2.0
>> implementation and includes sftp client and server support.
> A user on the Cygwin mailing list found a problem with 4.6p1 when
> using protocol version 1.  The bug report was rather short:
> $ ssh -1 somemachine
> Disconnecting: Corrupted check bytes on input.
> I can reproduce this behaviour and when starting ssh with -vvv flags,
> the above error message is printed in this context:
>   debug1: Found key in /home/corinna/.ssh/known_hosts:221
>   debug1: Encryption type: 3des
>   debug1: Sent encrypted session key.
>   debug2: cipher_init: set keylen (16 -> 32)
>   debug2: cipher_init: set keylen (16 -> 32)
>   debug1: Installing crc compensation attack detector.
>   Disconnecting: Corrupted check bytes on input.
> The problem is that only the Cygwin 4.6p1 version seems to be affect.
> I tested the following combinations, the rows are the ssh version
> with which I tried to connect to the sshd versions in the columns,
> always with version 1.5 protocol.
>     sshd:   Linux 4.5    Linux 4.6    Cygwin 4.5    Cygwin 4.6
> ssh:
> Linux 4.5     ok            ok            ok        corrupted
> Linux 4.6     ok            ok            ok        corrupted
> Cygwin 4.5    ok            ok            ok        corrupted
> Cygwin 4.6  corrupted    corrupted    corrupted         ok
> Apparently it doesn't have anything to do with the last minute patch I
> sent to this list a couple of days ago.  It doesn't matter whether I use
> text read/write, or text read/binary write, or binary read/write.
> The effect is always the same.  Since the checksums are transmitted
> using sockets, and sockets are unconditionally using binary read/write
> mode anyway, this was not to be expected.
> So, my question is this:  Is there any change in the protocol 1 code
> which could explain this behaviour?  Where shall I look if I try to
> debug this further?  I'm rather a bit stumped right now.

If you're using OpenSSL 0.9.8e you could try backing out this bit in

/* OpenSSL 0.9.8e returns cipher key len not context key len */
#if (OPENSSL_VERSION_NUMBER == 0x0090805fL)
# define EVP_CIPHER_CTX_key_length(c) ((c)->key_len)

Darren Tucker (dtucker at
GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4  37C9 C982 80C7 8FF4 FA69
    Good judgement comes with experience. Unfortunately, the experience
usually comes from bad judgement.

More information about the openssh-unix-dev mailing list