SFTP connections hit-and-miss

SFTP support in 3.7.1 seems to be hit-and-miss. I've tried it against 3 SFTP servers and it's only worked with one.

The working server is running sshd (OpenSSH) on CentOS 5.1.
The two non-working servers:
sshd (OpenSSH) on Red Hat Enterprise Linux WS release 4
WinSSHD on Windows

In both failure cases, the connection fails immediately, before it prompts me about the server's key or sends login information.

[R] Connecting to 207.54.225.41 -> IP=207.54.225.41 PORT=22
[R] Connected to 207.54.225.41
[R] Socket Error: 10054: Connection reset by peer
[R] Connection failed

If you'd like to test against 207.54.225.41 (a personal server of mine running WinSSHD), go ahead - - since the failure happens before the login attempt, you don't even need an account. This is what showed up in the server log:

000000000122 2008-06-29 00:42:13.484Z WinSSHD 4.23 [021] Info
  Session thread 1023 handling connection from XXX.XX.XXX.XX:65469: Connection from XXX.XX.XXX.XX:65469 accepted.

000000000123 2008-06-29 00:42:13.505Z WinSSHD 4.23 [022] Info
  Session thread 1023 handling connection from XXX.XX.XXX.XX:65469: Client version string: SSH-2.0-SecureBlackbox.6

000000000124 2008-06-29 00:43:13.523Z WinSSHD 4.23 [093] Info
  Session thread 1023 handling connection from XXX.XX.XXX.XX:65469: The client was 
disconnected by intermediate network components or chose to disconnect without 
sending a disconnect message.

To verify that this is not a network problem, I have attempted to connect to the machines from multiple locations. Also, I verified using both WinSCP and command-line sftp that the servers were accessible and working.


[Update]

I tried running FlashFXP locally on the machine running WinSSHD and connecting to it (localhost) and it worked. So it doesn't seem to be a server compatibility issue, it may have to do with how "local" the server is. The CentOS machine that I reported success on above is on my local subnet but the failure machines were not. I'm still calling it a bug since connections work fine in WinSCP / command line sftp (Cygwin).

Hello,

Thank you for your feedback.

I have tested WinSSHD many times over on my lan without having any connection issues. I'm not entirely sure what to make of the connection failures.

I attempted to connect to your SSH server and I was able to connect and do a server handshake, of course I failed the login without the proper login information.

You should be able to connect to your sftp server exactly the same way as with WinSCP.

Are you using the Bind to IP option in FlashFXP, other than that I can't think of any other settings that may be a factor.

If you got the server handshake, then you got further than I got.

No, I'm not using the Bind to IP option. Though, just now, I tried it using Bind to IP (selecting the correct IP) and that didn't help any.

It's just SFTP that has the problem as well, I am able to connect to the same server using regular FTP.

Is there anything I can do on the client side to give you debug info?

Thanks,
- Aaron

debug messages are enabled, the problem is that this issue didn't reach any of the checkpoints to display anything useful.


During the handshake process we know that the following occurred Socket Error: 10054: Connection reset by peer and I know that this error message is shown when there's an error sending data to the server, a 10054 error occurs when the server closes connection without warning.

However on the server side we saw Session thread 1023 handling connection from XXX.XX.XXX.XX:65469: The client was disconnected by intermediate network components or chose to disconnect without sending a disconnect message. when you take the error messages from both it almost seems like maybe a firewall issue or something similar but it's really hard to say.

I don't think its a FlashFXP issue though.

I agree that it looks like a firewall/network issue, however... Since WinSCP and others work, I've gotta believe FlashFXP is at least doing something different.

I'll try some packet traces later and see if I can glean anything from them.

I took a network capture of FlashFXP and WinSCP connecting to the same SFTP server. I've uploaded the network capture files here - - you can open them with Microsoft Network Monitor.

Right before the disconnect, FlashFXP sends a near-duplicate frame (frames 11 and 12 in this capture) - - I noticed no such duplicates from WinSCP, though the conversation does flow pretty much the same up until that point.

But anyway, a connection is definitely established and FlashFXP starts talking to the SFTP server, then something odd happens and it gets bumped.

Because the initial connection goes through, I don't see how this can not be a FlashFXP issue... I'm not running any software firewall on my machine besides what Windows provides (which only blocks unsolicited incoming connections by default).


It's also worth noting that I'm at a different location now and I'm unable to successfully connect to the CentOS machine I was able to connect to before. So far, I have not had any successful connections out of my subnet.

Hopefully these captures lets you at least get an idea of where this issue is. Let me know if I can provide any more information.

Thanks.

I've looked into this a bit more and I noticed that winSSHD has advanced debug logging, The debug log may shed some light on this issue. Since its the weekend my time is rather limited right now but tomorrow I will look into the possibility of adding additional debugging to FlashFXP.

Also it might be worth wild to know your WinSSHD configuration, I am using the default config and everything works great, perhaps you set something custom and its causing some sort of difficulty with FlashFXP.

FlashFXP uses SecureBlackBox for sftp support, its a sftp library that has been throughly tested and used by many commercial applications.

I didn't make any big changes to the WinSSHD configuration, just stuff pertaining to user setup. I don't think it's a WinSSHD problem, since I'm able to connect to that server (although only locally) and I'm also having trouble connecting to regular Linux servers running sshd (OpenSSH).

Anyway...
I'll look into turning on advanced debug logging and see if that turns up anything interesting.

(Reproduced connection failures on 3 machines now, two Vista and one XP. Far many more failures than successes.)


Is there another SecureBlackBox app that is either free or has a free trial that I can test with?

I just wanted to give you a status update that I'm still looking it this issue and i'll post an update as soon as I have something for you.

I experience unexpected connection losses like this also, however this is not caused by the client as far as i can tell. For me the same servers have the same connection issues regardless of the client used (eg putty), and on these servers sometimes other protocols also have connection drops and so on (such as telnet or dcc chat through an irc client to a perl bot)

The best i have been able to come up with in the past is some server side router/firewall issue, possibly related to packet filtering/anti-ddos/etc type settings. However my knowledge/experience with them is not great enough to narrow anything down.

This is not the case with me...
Some of the servers FlashFXP won't connect to are here on the campus LAN, and I never have connectivity issues with them using other clients.

Please download this special compile with extended sftp debug dumping
http://www.flashfxp.com/?d=140

[Edit] I posted inline but it was huge. Get the dump here.

From the dump it looks like flashfxp sent a data packet to the socket and the server disconnected, I don't see any reasons or errors for the disconnection. This is quite a mystery to me.

You might try making a backup of your flashfxp.ini (simply renaming it will do) and let flashfxp recreate it using the default settings, maybe there's something in your configuration that is playing up with the server.

Yeah, I tried a clean config a while back with no luck.

Can you try connecting to earth.ecs.baylor.edu via SFTP and see if you can complete the handshake?

I had a chance to get out of here yesterday and now I think that the problem only occurs when...

I'm connecting from a machine on the campus network to another machine on the campus network (unless I happen to be sitting in the same subnet).
I'm connecting from a machine on the campus network to another machine not on the campus network.
I'm connecting from a machine not on the campus network to a machine on the campus network.

(Note: Other clients still work in all of these cases.)

But it does not occur when I'm not touching the campus network.
So anyway, I'm curious to see if you can reproduce by connecting to earth.ecs.baylor.edu.

Thanks.

After a lot of trial and error and using the above mentioned server I determine the cause of this issue, apparently the problem relates to the list of client side encryption methods.

As odd it may seem simply including certain algorithms in the list cause the failure, once these algorithms are disabled the connection works without an issue.

Comparing to other sftp clients they don't appear to support these algorithms or at least don't have them enabled by default.

I need a couple weeks to design the user interface and work out all the details for managing the algorithms.

Great, well, at least now I know that I'm not crazy. :-P
Glad to hear that you're working on it, I look forward to trying the next release.

I don't mean to sound bad when I say things like "Look at WinSCP, it works!". I really would prefer to dump WinSCP for FlashFXP, I like the UI and behavior of FlashFXP so much better. So I'm looking forward to using FlashFXP as my main SFTP app once this gets worked out.

Thanks!

I've added you to our beta team, The next time you log into the customer portal you will have access to all beta releases.

I just posted a new beta that adds the ability to select the encryption ciphers.

The default selection should work well in your situation.

Have a great weekend!

Thanks for the quick turnaround...
I found build 1263 on the portal and in there I found the encryption settings in prefs. Without changing anything from default, I tried to connect to one of my problem servers and found it working great. Thanks! :-)

I'll let you know if anything else comes up.