OpenSSH-2.5.1p1 scp hangs when scping into an RH (6.0|7.0) box

[Jim Breton]

I just compiled OpenSSH-2.5.1p1 from source on my Debian potato box
using:
--prefix=/usr/local/openssh --enable-gnome-askpass --with-tcp-wrappers
--with-ipv4-default --with-ipaddr-display
--libexecdir=/usr/local/openssh/lib --disable-suid-ssh --with-pam

I am running OpenSSL-0.9.5a compiled from source with:
--prefix=/usr/local/openssl --openssldir=/usr/local/openssl

I can scp into my other Debian (woody/testing and potato/stable) boxes
and my OpenBSD 2.8 box without issue.

However, when trying to scp a file to an RH 6.0 or 7.0 (the only two
available to me currently) machine, scp hangs after authentication.
Even if I use -v, there is not much useful output:

$ scp -v -v filelist (host):
Executing: program /usr/local/openssh/bin/ssh (host)
(host), user (unspecified), command scp -v -t .
jimb@(host)'s password: 
(hangs here for a long while, 5 minutes or more)
Read from remote host (host): Connection timed out
lost connection

(The username jimb is specified in .ssh/config for this server.)
(I have also tried with the user at host: syntax.)

Also an sshd process is left laying around on the server if I kill the
client process with Ctrl+C (not sure if the same thing happens after a
time-out).


The two machines I'm connecting to are:

RH6.0, OpenSSH-2.5.1p1 compiled from source:
--prefix=/usr/local/openssh --with-tcp-wrappers --disable-suid-ssh
--with-pam
and OpenSSL-0.9.6 also compiled from source.

RH7.0, OpenSSH-2.5.1p1 RPMs (from ftp.openbsd.org), and RH's OpenSSL
RPMs (openssl-0.9.5a-14).


I'm not on the -dev list so if anyone sees anything obvious which I'm
doing wrong please do copy me on it.  ;)  I've been trying to keep up
by viewing the archives though.

Thanks.

(P.S. scp was also broken in 2.3.0p1 but of course that was already a
known issue, and that was not RH-specific in my experience.  Afaict this
problem I am having is only on RH, though I can't confirm that it
doesn't exist elsewhere (other than Debian and OpenBSD).)

-- 

Jim B.
vader at conflict.net