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/
midrange.com
