SCP Problem

Vu Pham vu at sivell.com
Wed Oct 24 20:15:17 PDT 2007


On Wed, 2007-10-24 at 20:38 -0400, Kurt Wall wrote:
> Hola, list,
> 
> I have an interesting problem. The short version is that there is host
> out there into which I can ssh without incident from my systems here
> at KurtWerks (using either password or public key authentication - I 
> use public keys). I can also ssh back to KurtWerks. Similarly, from the
> remote host, I can scp files to and from KurtWerks. 
> 
> The problem, though, is that scp from KurtWerks to the remote system, that
> is, when KurtWerks is the orgin of the scp session, will not work. I
> start the session, authenticate, and then it stops. No data is
> transmitted. When I turn debugging with scp -vvv, the last few lines
> read like so:
> 
> debug1: Sending command: scp -v -r -p -d -t /usr/www/users/kwall
> debug2: channel 0: request exec confirm 0
> debug2: fd 3 setting TCP_NODELAY
> debug2: callback done
> debug2: channel 0: open confirm rwindow 0 rmax 32768
> debug2: channel 0: rcvd adjust 131072 
> 
> That last line is the last thing I see; 10 minutes later, it hasn't
> moved and I just kill the session with Ctrl-c. I ran an strace on the
> scp session, and the last few lines look like so:
> 
> rt_sigaction(SIGTERM, NULL, {SIG_DFL}, 8) = 0
> rt_sigaction(SIGTERM, {0x80001d50, [], 0}, NULL, 8) = 0
> rt_sigaction(SIGINT, NULL, {SIG_DFL}, 8) = 0
> rt_sigaction(SIGINT, {0x80001d50, [], 0}, NULL, 8) = 0
> rt_sigaction(SIGHUP, NULL, {SIG_DFL}, 8) = 0
> rt_sigaction(SIGHUP, {0x80001d50, [], 0}, NULL, 8) = 0
> read(7,
> 
> Yes, that's an incomplete read() syscall because that's where the strace
> output stops. Finally, running a tcpdump on the session, I see much the
> same thing: session initiation followed by authentication, and then
> nothing. Again, the last few lines of tcpdump's output:
> 
> 02:06:22.710183 IP latte.local.51303 > the.remote.host.ssh: P
> 2238:2366(128) ack 2088 win 93 <nop,nop,timestamp 2640818 4136540140>
> 02:06:22.749597 IP the.remote.host.ssh > latte.local.51303: P
> 2088:2136(48) ack 2366 win 32942 <nop,nop,timestamp 4136540183 2640818>
> 02:06:22.789387 IP latte.local.51303 > the.remote.host.ssh: . ack 2136
> win 93 <nop,nop,timestamp 2640838 4136540183> 
> 

I did have similar problem on my FC7, but I am just not sure how that
problem was fixed. When it happened (about 3 weeks ago ) I was in a
hurry to do something so I just transfer files by other methods then I
forgot it. Now, after reading your email, I just checked it again and it
works just fine. 

One thing I can be sure is that I did an update my system last week ( by
using the update tool of FC7 ).

Vu 




More information about the Linux-users mailing list