8

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 [email protected]:'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)
Improve this question
3
  • 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 'SO- stop being evil'
    Commented Jul 29, 2013 at 23:50
  • Please don't cross post on the various SE sites: stackoverflow.com/questions/17933347/…
    – slm ♦
    Commented Jul 30, 2013 at 1:23
  • Had a similar problem when connecting from ubuntu to wsl 1 running on the same machine with virtualization enabled. I solved it by disabling virtualization
    – Andrey
    Commented Feb 19, 2023 at 8:08

3 Answers 3

Reset to default
4

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/[email protected]: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/[email protected]: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

Improve this answer
5
  • 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
    Commented Jul 29, 2013 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 ♦
    Commented Jul 29, 2013 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 'SO- stop being evil'
    Commented Jul 29, 2013 at 23:53
  • @Gilles - I still have my money on it's a hardware failure.
    – slm ♦
    Commented Jul 30, 2013 at 0:17
  • 1
    @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 'SO- stop being evil'
    Commented Jul 30, 2013 at 0:21
0

I encountered this issue, scp'ing on port 22 from a linux machine to a linux machine trough 2 NAT's. Since I had no control over the Windows Machines or the NAT boxes, only the 2 linux machines, my solution was to switch the ssh server from port 22 to 2222 and things got working.

Same issues, scping from windows machine to the linux box worked, scping from the linux machine to my machine worked, but sending data from my machine to the linux server ended in the server (Or the firewall on a NAT box in between) sending TCP RST packets to my server.

symptoms with scp:

debug2: channel 0: written 31 to efd 7
rapport.pdf                                                                             0%    0     0.0KB/s   --:-- ETAdebug3: send packet: type 1
packet_write_wait: Connection to 192.168.1.2 port 22: Broken pipe
lost connection

symptoms with git over ssh:

debug2: channel 0: request exec confirm 1
debug3: send packet: type 98
debug2: channel_input_open_confirmation: channel 0: callback done
debug2: channel 0: open confirm rwindow 0 rmax 32768
debug2: channel 0: rcvd adjust 2097152
debug3: receive packet: type 99
debug2: channel_input_status_confirm: type 99 id 0
debug2: exec request accepted on channel 0
Counting objects: 176, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (90/90), done.
debug2: channel 0: rcvd adjust 98457
debug3: send packet: type 176)   
packet_write_wait: Connection to 192.168.1.2 port 22: Broken pipe
fatal: The remote end hung up unexpectedly
fatal: The remote end hung up unexpectedly

some further digging got me to https://serverfault.com/questions/411629/tcp-connection-reset-in-linuxstrange-packet-loss-but-not-on-windows Which had the a solution if you only have control of your local Linux Machine:

 there is a broken firewall along the path that is filtering all IP packets that use TCP Timestamp option.

So to keep things working on port 22 I ran this on my machine:

echo 0 | sudo tee /proc/sys/net/ipv4/tcp_timestamps
Improve this answer
0

In my case, it was simple: The target computer was out of disk space.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .