× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



Paul,

"Connection reset by peer" means that the peer (i.e. the computer you are connected to) sent a network packet with the RST ("reset") flag set. This is done when there is a network error to terminate a connection immediately when there is an error.

1) This depends on a lot of factors. An SSH handshake (SFTP uses the SSH network protocol) involves exchanging of cryptographic details and validating them. The server has to do a reverse DNS lookup on the client's IP address as part of that validation, and I've found this to be the slowest part. Of course, if DNS caching is available, this might be very fast if the client's address is already in the cache... but when it's not, then the DNS lookup can sometimes take as long as 5 seconds. During a denial-of-service attack, the DNS lookup may fail altogether.

I'd expect the actual handshake (not including the DNS part) to take between 100-600 milliseconds. But, of course, this will depend on the speed of the computers, how busy they are, the speed of the network, and how busy it is, etc.

2) Absolutely... DOS attacks often overload the network. When network devices (switches, routers, NICs, etc) have more traffic than they can handle, they start to drop packets. That is to say that data is actually discarded because the machines can't keep up. TCP based protocols such as SSH will re-send dropped packets, but it takes time to detect that a packet was lost and needs to be resent. If the same packet gets dropped a second time, it will "back off" (wait longer) before resending it again... if it gets dropped a 3rd time, the wait before resending increases even further, etc.. so this could definitely cause a timeout.

Then, you have to factor in the DNS lookup I mentioned above. DNS is not a TCP protocol, so packets are not automatically resent. When a DNS packet is dropped, the requestor will eventually give up on getting an answer (after maybe 5 seconds) and then will ask again. How quickly it retries and how many times will depend on the server's TCP/IP configuration, but it could easily add some serious time, which could cause the either the server or client to time out.

Then again, it may not even be a time out situation at all... if enough packets are lost, it will reach a point where it feels there were too many errors (on either the TCP connection for SSH or the UDP packets for DNS) and may give up due to exceeding the error retry threshold.


At any rate, none of this is unique to SFTP. Any of this could happen with plain old FTP or any other network protocol, too. But, due to the extra work that's done to exchange crypto info, validate the hosts, etc for security purposes, there may be more room for things to go wrong, especially during a DOS attack.

Only 40 failure in two months during a DOS attack seems to show that your process is pretty robust. It's always wise to assume that communications will fail sometimes, the world isn't a perfect place! I would plan for this to fail occasionally, and re-try if needed.


On 1/19/2016 11:45 PM, Steinmetz, Paul wrote:
I have an SFTP client Expect 5.43 via PASE intermittently failing.
This process runs every 15 minutes, 6 am to 9 pm, Sun thru Sat, so about 60 times per day.
40 failures since 11/20, when this converted from an FTP to SFTP.

When it fails, I get this error message.

ssh_exchange_identification: read: Connection reset by peer
Connection closed

The remote side has not found any issues on their side.
We haven't found any issues on our side.

What was discovered that at the same time of some of the failures, our ISP was having DOS attacks.

My question is two-fold.
1) During the initial SFTP handshake process, how long does this normally take?
2) Could the DOS attacks be slowing down the SFTP handshake process, thus not allowing it to complete in its required time interval X, whatever X is?

Thank You
_____
Paul Steinmetz
IBM i Systems Administrator

Pencor Services, Inc.
462 Delaware Ave
Palmerton Pa 18071

610-826-9117 work
610-826-9188 fax
610-349-0913 cell
610-377-6012 home

psteinmetz@xxxxxxxxxx
http://www.pencor.com/





As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.