F-secure v1 client has trouble connecting to openssh-2.5.1p1

[Mark D. Baushke]

Hi Kevin,

I believe this problem is worked around in the OpenSSH-2.5.1p2 release
(version 1.57 of session.c). You should try to upgrade your server and
see if that helps to fix your problem.

The bug is actually in your F-Secure ssh v1 client (see attached message).

	Enjoy!
	-- Mark

>Date: Wed, 7 Mar 2001 14:18:02 -0500
>From: Kevin Taylor <ktaylor at eosdata.gsfc.nasa.gov>
>
>I determined that this is only happening when X11 forwarding is turned on
>for the client. When turning X forwarding off the problem goes away.
>
>....but X forwarding is needed.

> Date: Wed, 7 Mar 2001 13:52:42 -0500
> From: Kevin Taylor <ktaylor at eosdata.gsfc.nasa.gov>
> 
> I'm observing that mac clients using F-Secure ssh v1 client log into the
> ssh server, and then the client just hangs with nothing on the screen.
> 
> In the SYSLOG file, I see this:
> 
> Accepted password for user from host port whatever
> 
> Packet integrity error (62 != 58) at session.c:350
> Disconnecting: Packet integrity error. (34)
> 
> This is sshd running on IRIX 6.5.3f



------- Forwarded Message

Date: Wed, 21 Feb 2001 19:00:39 -0500
Message-Id: <200102220000.TAA09881 at syrinx.oankali.net>
From: "Richard E. Silverman" <slade at shore.net>
To: OpenSSH Developers <openssh-unix-dev at mindrot.org>
Subject: Re: Packet integrity error. (34)


markus> it seems that SecureCRT sends a display 'screen' number in the x11
markus> request packet, but did not set the matching protocol flag in an
markus> earlier message. this worked before because OpenSSH-2.3.0p1 was buggy
markus> and ignored the protocol flag....

I actually also noticed this also a day or so ago, and was about to post about
it here when I checked and saw this thread.

This is a problem with the F-Secure client as well as SecureCRT.  Both
programs do not set the SSH_PROTOFLAG_SCREEN_NUMBER protocol flag in SSH-1
sessions, even though they do in fact include the X11 screen number field in
SSH_CMSG_X11_REQUEST_FORWARDING packets.  This was not a problem -- until
Markus added code to session.c in 2.5 to check actual vs expected packet
lengths on these requests.  Now, SSH-1 connections with X forwarding from
these clients fail immediately with the message, "packet integrity error."
I've submitted bug reports to both companies.

A small note: I think it would be good to change the error message -- "packet
integrity error" sounds like the crc-32 integrity check failed, which isn't
what happened.  Perhaps instead, "expected packet length did not match
actual."

- - Richard

------- End of Forwarded Message