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


  • SSH server 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@'D:/Temp'

on most cases files transferred successfully

but sometimes scp stuck during file transferring ? , in spite connectivity is ok like ping etc

and 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 the solution for this problem?
  2. What the others good alternative for scp ? , (consider that I need 100% of stability)
  • 1
    Please do not crosspost (and if you do, wait a day or two): scp stuck when trying to copy files from Linux to windows
    – Marco
    Jul 29, 2013 at 21:04
  • A network tracing tool like Microsoft Network Monitor or Wireshark might be able to give you more details on why the connection is being reset.
    – 0xFE
    Jul 29, 2013 at 22:23
  • Rsync over SSH would seem like being a much better fit for you than straight SCP, is there a reason why you're not using rsync?
    – Gagravarr
    Jul 29, 2013 at 22:36
  • 1
    I would imagine you are coming across a named pipe (or FIFO) because you are copying from the temp directory. I would go with gagravarr and say in this case you may want to look at rsync as a viable alternative. Examples in stackoverflow.com/questions/1228466/…
    – Drav Sloan
    Jul 29, 2013 at 23:02

3 Answers 3


This could be a sign of network issues - ping doesn't catch all issues. The most likely culprit is a firewall or NAT device that is dropping the connection.

Adding -v for verbose output to scp will give you more detail as to what it's doing, and may give a better clue as to what is going on. If you want to post the output of a failed transfer with the -v option, I may be able to give a more exact answer.

Connection reset by peer means exactly that - the destination server reset/closed the connection. NAT devices will do this if there hasn't been any data sent for awhile, or if they are not working correctly.

Some ISPs will do this as a form of traffic shaping to limit peer to peer traffic - unfortunately some apply it to SSH connections as well. This likely won't be an issue on business connections, but if either end has a residential internet connection, it may apply.

The SSH server on windows could also be flaky. You don't specify which one you use, but not all of them work reliably.

In one real life example of weirdness, I had a friend who had similar issues - it turned out to be a bug in his cable modem's firmware that corrupted one out of every couple million packets. Rare enough that small transfers worked perfectly, but large ones would die every time.

Or it could just be normal internet issues. The internet is not 100% reliable, and never will be. Sometimes connections fail, sometimes packets get lost along the way. Sometimes the tiny men inside the ethernet cable go on strike and don't feel like carrying your packets. So you need a tool that can handle that, and keep retrying until it succeeds.

rsync would be a better choice here, simply because it allows resuming. This blog post explains how to setup rsync with resuming in place of scp. If necessary, you could write a simple shell script to check the exit code of rsync and keep retrying if it fails. This other blog post has an example of such a script.


What the others good alternative for scp ? , (consider that I need 100% of stability)

Consider flipping it and using WinSCP from the Windows machine to connect and grab the files on the Linux server.


Eytan, you don't mentioned if you able to install other tools on windows machine and if need a encrypted connection , here my comments and suggestion:

  • Today I have problem with rsync to copy big tree structures with lot of files... where it just crash, but the good thing when you run it again they will "continue" from where they stop before....
  • rsync needs ssh or rsh utilities... supposing the problem is your ssh server with rsync you will create a new point of failure. But personally I would test before discarding this solution since it is versatile.

My suggestion

  • I have great experience using the cygwin for solutions like yours needs.
    So, install the basic packages + open ssh + cygrunsrv (to create the windows service).
  • Then, to avoid rewrite your solution, try use the cygwin ssh server instead windows or any other ssh server you use.
  • Alternatively you can install a rsh-server and try it with rsync.
  • Other option is a FTP server (proftpd or pureftpd) and use the ncftp/ncftpput on linux to connect into you windows.
    The ncftp able to identify preexists/older files and decide if overwrite it or not and recursive directories. You probably can find the ncftp RPM into you Red Hat DVD.
    Considering performance, the FTP will be the best....

As you see, I like cygwin, it help me a lot of times on windows... and is a "must have" tool on my windows desktop.

Good luck.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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