Scott and Tim,
Thank you both for your responses.
< X is the login grace time that's set in the server's sshd config. The default is 120 seconds. The login process should be sub second. 40 failures in 60 days is extraordinarily high.>
Tim, I was informed, don't remember by who, that SFTP client Expect 5.43 via PASE does NOT use the ssh client/server config defaults, so the 120 would not be in use here, can we confirm?
Also, some addition info.
When the SFTP is successful, the entire SFTP job completes normally, averaging 45 to 50 seconds.
When I get error, this occurs within 11 to 30 seconds.
Scott,
<"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.>
I guess at this point, we have to identify who sent the packet with RST.
Paul
-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Scott Klement
Sent: Wednesday, January 20, 2016 3:13 AM
To: Midrange Systems Technical Discussion
Subject: Re: SFTP client Expect 5.43 via PASE intermittently failing
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/
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options,
visit:
http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a moment to review the archives at
http://archive.midrange.com/midrange-l.
Please contact support@xxxxxxxxxxxx for any subscription related questions.
midrange.com
