Bug 167955 (DelayedCompression)

Summary: openssh update breaks -C flag at least for some clients
Product: [Fedora] Fedora Reporter: Michal Jaegermann <michal>
Component: opensshAssignee: Tomas Mraz <tmraz>
Status: CLOSED NOTABUG QA Contact: Brian Brock <bbrock>
Severity: medium Docs Contact:
Priority: medium    
Version: rawhide   
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2005-09-09 17:27:50 EDT Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Description Michal Jaegermann 2005-09-09 17:02:34 EDT
Description of problem:

After the last update there are no issues with doing 'ssh -C ...' between
machines with the same version of openssh.  It actually works as well
with a client running FC3.  But if I will try the same from a client
running RH7.3 with openssh-3.1p1-18.73 I see when using '-v' flag:

debug1: Remote protocol version 2.0, remote software version OpenSSH_4.2
debug1: match: OpenSSH_4.2 pat OpenSSH*
Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_3.1p1
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
no matching comp found: client zlib server none,zlib@openssh.com
debug1: Calling cleanup 0x8063520(0x0)

and a connection is dropped.  There was no problem in connecting before
the last update.  There is no difference if a server is x86 or x86_64
machine.  Doing the same in the other direction works fine.

It is still possible to connect to openssh-4.2p1-1 server if '-C' flag
is dropped although I cannot tell if something else will not jump out with
other clients.  My guess that machnines with RHEL 2.1 will have at least
the same issue (but I do not have one to test).

Version-Release number of selected component (if applicable):

How reproducible:
Comment 1 Tomas Mraz 2005-09-09 17:27:50 EDT
This is known bug in the older ssh clients. You can:
1. Either drop the -C flag from the ssh command line of the older ssh clients
2. Or modify the /etc/ssh/sshd_config on the server so it contains "Compression
yes" which will disable the delayed compression.