Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

I use the following scp syntax in order to transfer a lot of files from Linux red-hat 5 to windows machine (under Temp directory).

SSH server is already installed on windows machine. I use this line in my shell scripts:

sshpass -p '$password'  /usr/bin/scp -o StrictHostKeyChecking=no  $FILE USER_1@14.187.12.139:'D:/Temp'

For most cases files transferred successfully, but sometimes scp seems to get stuck during file transferring? Connectivity appears OK like ping, etc.

I get the following error from scp (after a long time):

ssh_exchange_identification: read: Connection reset by peer
  1. why scp isn't stable and stuck, and what's the solution for this problem?
  2. What are others good alternative for scp? (consider that I need 100% of stability)
share|improve this question
    
My first hunch would be a firewall. What is the firewall configuration on the client, on the server, and on all the hops in between? –  Gilles Jul 29 '13 at 23:50
    
Please don't cross post on the various SE sites: stackoverflow.com/questions/17933347/… –  slm Jul 30 '13 at 1:23
add comment

1 Answer

up vote 0 down vote accepted

Hardware

I wouldn't be that suspicious of scp. If it's working some of the time this sounds much more like a hardware issue with either your:

  1. network card (linux or windows host)
  2. wiring
  3. switch/router

I would perform some benchmarking to eliminate these items first. You can see these U&L Q&A's for starters:

Software

Debugging scp & ssh

You can add -v switches to both of these commands to get more verbose output. For example:

# generate sample data
$ dd if=/dev/zero of=10MB.testfile bs=1k count=10k
10240+0 records in
10240+0 records out
10485760 bytes (10 MB) copied, 0.0422862 s, 248 MB/s

$ ls -l 10MB.testfile 
-rw-rw---- 1 saml saml 10485760 Jul 29 17:09 10MB.testfile

# test copy 10MB file
$ scp -v 10MB.testfile remoteserver:~
Executing: program /usr/bin/ssh host removeserver, user (unspecified), command scp -v -t -- ~
OpenSSH_5.5p1, OpenSSL 1.0.0e-fips 6 Sep 2011
debug1: Reading configuration data /home/saml/.ssh/config
debug1: Applying options for *
debug1: Applying options for removeserver
debug1: Applying options for *
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: auto-mux: Trying existing master
Control socket connect(/home/saml/.ssh/master-sam@192.168.1.200:22): Connection refused
debug1: Connecting to 192.168.1.200 [192.168.1.200] port 22.
debug1: Connection established.
debug1: identity file /home/saml/.ssh/id_dsa type 2
debug1: identity file /home/saml/.ssh/id_dsa-cert type -1
debug1: identity file /home/saml/.ssh/qm-dev-servers type 1
debug1: identity file /home/saml/.ssh/qm-dev-servers-cert type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_4.3
debug1: match: OpenSSH_4.3 pat OpenSSH_4*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.5
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-md5 none
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Host '192.168.1.200' is known and matches the RSA host key.
debug1: Found key in /home/saml/.ssh/known_hosts:30
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: Roaming not allowed by server
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,gssapi-with-mic,password
debug1: Next authentication method: publickey
debug1: Offering public key: /home/saml/.ssh/id_dsa
debug1: Authentications that can continue: publickey,gssapi-with-mic,password
debug1: Offering public key: /home/saml/.ssh/qm-dev-servers
debug1: Server accepts key: pkalg ssh-rsa blen 279
debug1: Authentication succeeded (publickey).
debug1: channel 0: new [client-session]
debug1: setting up multiplex master socket
ControlSocket /home/saml/.ssh/master-sam@192.168.1.200:22 already exists, disabling multiplexing
debug1: Entering interactive session.
debug1: Sending environment.
debug1: Sending env XMODIFIERS = @im=none
debug1: Sending env LANG = en_US.utf8
debug1: Sending command: scp -v -t -- ~
Sending file modes: C0660 10485760 10MB.testfile
Sink: C0660 10485760 10MB.testfile
10MB.testfile                                                                           100%   10MB   3.3MB/s   00:03····
debug1: client_input_channel_req: channel 0 rtype exit-status reply 0
debug1: channel 0: free: client-session, nchannels 1
debug1: fd 0 clearing O_NONBLOCK
debug1: fd 1 clearing O_NONBLOCK
Transferred: sent 10499080, received 4936 bytes, in 4.0 seconds
Bytes per second: sent 2610912.6, received 1227.5
debug1: Exit status 0

You can add additional -v switches to get more verbose output. For example:

$ scp -vvv ...

Windows Firewall

In researching this a bit more I came across this workaround which would back up @Gilles notion that this may be a firewall issue. The solution was to disable stateful inspection on the Windows side that's running the sshd service using the following command (as an administrator):

% netsh advfirewall set global statefulftp disable

References

share|improve this answer
    
Yes I already check the HW ( network is OK ) issues and I don’t see any problem - what I think maybe is that I use scp allot of times so maybe because the port 22 that is full? or something like this ? I really don’t know –  Eytan Jul 29 '13 at 21:02
1  
@Eytan - no it doesn't work that way. The connections are TCP based and by it's very design it's built to deal with multiple connections reliably. Please elaborate on how you determined that it wasn't a hardware problem. Based on my experience of 30+ years, that's where there is the most likely place to find smoke 8-). –  slm Jul 29 '13 at 21:04
    
@Eytan Ports don't get “full”. Well, they can “get full” if you have tens of thousands of clients at the same time. But not from doing a lot of successive connections or long connections, and it wouldn't lead to “connection reset” anyway. “Connection reset” is almost always a firewall. –  Gilles Jul 29 '13 at 23:53
    
@Gilles - I still have my money on it's a hardware failure. –  slm Jul 30 '13 at 0:17
    
@slm While in principle hardware failures can result in pretty much anything, a reset TCP connection is not a common consequence. TCP reacts to data loss by resending a packet; a connection that loses so many packets that the connection breaks is unlikely to work to transfer any file. Funky firewall rules that take bandwidth, usage patterns, endpoints and moon phases into accounts, on the other hand, quite often drop connections for no apparent reason. –  Gilles Jul 30 '13 at 0:21
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.