EldoS | Feel safer!

Software components for data protection, secure storage and transfer

Help understanding TElSimpleSFTPClient.Versions property

Also by EldoS: CallbackDisk
Create virtual disks backed by memory or custom location, expose disk images as disks and more.
#33932
Posted: 07/07/2015 15:22:21
by Ben Way (Standard support level)
Joined: 07/02/2015
Posts: 5

We are getting an "SFTP component not connected" when attempting to transfer a file after successfully connecting to a server running Maverick_SSHD. In looking over other posts here for that error message it seems a common thread is the SFTP Version that is used to connect.

After connecting without changing the Versions property I can inspect my TElSimpleSFTPClient object and see that:
Versions = 124 (all available for negotiation)
Version = 8 (actually connected using SFTP3).
When attempting to upload a file with this connection it will fail with the above error.

If I explicitly change the Versions property to SBSftpCommon.Unit.sbSFTP3, connect, and inspect the client object I see that:
Versions = 8 (SFTP3)
Version = 8 (SFTP3)
Uploading a file using this connection will now succeed.

In both instances it appears the connection has been made using SFTP3, why is it that in the case where I haven't explicitly set the allowable versions a file transfer will fail?

Is this a bug? It seems like if SBB gets the proper Version setting during the connection it should just work. As it stands, we will need to implement a lot of unwanted micro-managing code since we cannot rely on SBB to use the negotiated SFTP version.

Is there something we are missing?
#33933
Posted: 07/07/2015 15:37:11
by Eugene Mayevski (EldoS Corp.)

Quote
Ben Way wrote:
In both instances it appears the connection has been made using SFTP3, why is it that in the case where I haven't explicitly set the allowable versions a file transfer will fail?


Thank you for the interesting observation. I think the reason is some issue in implementation of the server - when the client declares that it supports all versions, the server erroneously starts to do some things in correct "version 3" mode and some other things are done assuming that the client uses (or understands) later version. This leads to miscommunication and thus loss of connectivity.

It makes sense to report the issue to the authors of the server so that they check what's going on inside the server in both cases. We can only made educated guesses, but not more.


Sincerely yours
Eugene Mayevski
#33934
Posted: 07/07/2015 16:17:31
by Ben Way (Standard support level)
Joined: 07/02/2015
Posts: 5

Eugene,

Thanks for the quick reply! Your answer suggests that this could only be a server issue, but we can connect to the same server with other clients and client software APIs and we do not have the same problem.

How can you be so sure that it is in fact a server problem? Is there a way that we can test your theory? I have supplied the call stack info below, but it isn't really helpful to confirm that the server may be sending messages from mixed sftp versions.

Code
   SecureBlackbox.SFTP.dll!SBSimpleSftp.TElSimpleSFTPClient.DoError(object Sender, int ErrorCode) + 0xac bytes   
   SecureBlackbox.SSHCommon.dll!SBSSHCommon.TElSSHClass.DoError(int ErrorCode) + 0x68 bytes   
   SecureBlackbox.SSHClient.dll!SBSSHClient.TElSSHClient.SSH2ParseServerDisconnect(byte[] Buffer, int Size) + 0x232 bytes   
   SecureBlackbox.SSHClient.dll!SBSSHClient.TElSSHClient.SSH2ParseOnTransportLayer(byte[] Buffer, int Size) + 0x433 bytes   
   SecureBlackbox.SSHClient.dll!SBSSHClient.TElSSHClient.AnalyseBuffer() + 0x16af bytes   
   SecureBlackbox.SSHClient.dll!SBSSHClient.TElSSHClient.DataAvailable() + 0x291 bytes   
   SecureBlackbox.SFTP.dll!SBSimpleSftp.TElSimpleSFTPClient.DataAvailable() + 0xf7 bytes   
   SecureBlackbox.SFTP.dll!SBSimpleSftp.TElSimpleSFTPClient.IntMessageLoop() + 0x35 bytes   
   SecureBlackbox.SFTP.dll!SBSimpleSftp.TElSimpleSFTPClient.DoMessageLoop() + 0x3c bytes   
   SecureBlackbox.SFTP.dll!SBSimpleSftp.TElSimpleSFTPClient.HandleSftpMessageLoop() + 0x35 bytes   
   SecureBlackbox.SFTP.dll!SBSftp.TElSftpClient.RequestAttributes(string Path, bool FollowSymLinks) + 0x1be bytes   
   SecureBlackbox.SFTP.dll!SBSftp.TElSftpClient.RequestAttributesSync(string Path, bool FollowSymLinks) + 0xae bytes   
   SecureBlackbox.SFTP.dll!SBSimpleSftp.TElSimpleSFTPClient.RequestAttributes(string Path, bool FollowSymLinks, SBSftpCommon.TElSftpFileAttributes Attributes) + 0xbd bytes   
   SecureBlackbox.SFTP.dll!SBSimpleSftp.TElSimpleSFTPClient.CreateRemoteFolder(string Path) + 0xdc bytes   
   SecureBlackbox.SFTP.dll!SBSimpleSftp.TElSimpleSFTPClient.UploadStream(System.IO.Stream LocalStream, string RemoteFileName, SBTypes.TSBFileTransferMode Mode, long RestartFrom) + 0x55e bytes   
   SecureBlackbox.SFTP.dll!SBSimpleSftp.TElSimpleSFTPClient.UploadFile(string LocalFileName, string RemoteFileName, SBTypes.TSBFileTransferMode Mode, long RestartFrom) + 0x391 bytes   
   SecureBlackbox.SFTP.dll!SBSimpleSftp.TElSimpleSFTPClient.UploadFile(string LocalFileName, string RemoteFileName, SBTypes.TSBFileTransferMode Mode) + 0x57 bytes   


SecureBlackBox looked promising and was pretty easy to start using, but if we truly need to micro-manage every connection we might need to keep looking for a suitable client tool.
#33935
Posted: 07/07/2015 16:48:25
by Eugene Mayevski (EldoS Corp.)

Thank you for the call stack. It shows that the server has sent an error response. You can handle OnError event of TElSimpleSFTPClient component to get the error code and the accompanying error message - this will shed some light on what the server doesn't like. If you post this information here, maybe we'll have some better ideas of where to look at.

Quote
Ben Way wrote:
SecureBlackBox looked promising and was pretty easy to start using, but if we truly need to micro-manage every connection we might need to keep looking for a suitable client tool.


SSH server developers are not keen to follow the standards or test their servers with anything besides their own SSH clients, so certain tune-up is required in many cases if you want to get optimal performance. SecureBlackbox beats in speed even native solutions like WinSCP and Putty. This is partly because we use security- and speed-oriented settings by default. Of course we can lock all properties to "compatibility mode" which will be slow, will lack many features etc, but will work out of the box with everything. However for us this is not acceptable as we must expose what we can offer. If having slow code is acceptable in your usage scenarios (it's fine when you need to upload just a couple of files or when the process goes in the background), then you can turn off pipelining, lock SFTP version to version 3, turn off modern algorithms and the component will connect to all but the most buggy servers.


Sincerely yours
Eugene Mayevski
#33960
Posted: 07/08/2015 15:52:14
by Ben Way (Standard support level)
Joined: 07/02/2015
Posts: 5

Eugene,

Valid points on watering down SBB to allow it to be more compatible. There is a much bigger learning curve to SFTP processing than I was anticipating.

The errorCode passed to the OnError handler is 2. I don't see a property specifically labeled error message, but the ServerCloseReason of the client says "Failed to read binary packet data!" is that helpful? Is there another place to capture the error message?

After the OnError handler if I inspect the exception in a catch block the SBSftpCommon.EEISFTPError message says "SFTP Component not connected" and the ErrorCode is 6.
#33961
Posted: 07/09/2015 00:26:08
by Eugene Mayevski (EldoS Corp.)

The SSH layer closes connection, and then the SFTP layer's errors become irrelevant.

We'll install Maverick server to check, but I don't think we'll be able to do much if it's their bug. Also it can happen that this bug has been fixed in their later version.


Sincerely yours
Eugene Mayevski
#33962
Posted: 07/09/2015 02:19:45
by Ken Ivanov (EldoS Corp.)

Hi Ben,

In addition to Eugene's ideas, I would only add that there is a known bug in Maverick server. The server requires connecting clients to start their SFTP conversations with absolute path request command. If the first command issued by the client is a different one, the server will just close the connection without any reasons.

So please check your code and if the first SFTP command you send is not an absolute path request, please make it so. Just add client.RequestAbsolutePath(".") line just after the Open() call returns and you should be fine then.

Cheers,

Ken
#33963
Posted: 07/09/2015 03:55:34
by Eugene Mayevski (EldoS Corp.)

The strange part is that the server works when the version is locked to SFTP3.


Sincerely yours
Eugene Mayevski
#33968
Posted: 07/09/2015 08:32:06
by Ben Way (Standard support level)
Joined: 07/02/2015
Posts: 5

Ken and Eugene,

I tried the file again using Ken's suggestion, not specifically setting the version to SFTP3 and instead called client.RequestAbsolutePath(".") after the client.Open(), and the file was transmitted without any errors.

So we now have two solutions to the issue, set SFTP3 or call client.RequestAbsolutePath("."). Is there one that you would recommend over the other?

I was leaning toward just setting SFTP3 as we could do that for connecting to all servers and everything should work. If we were to leave in the call to client.RequestAbsolutePath(".") for connecting to all servers would that work as well or will that call cause some servers to fail?

Thanks for all the help and ideas!
#33969
Posted: 07/09/2015 09:00:52
by Ken Ivanov (EldoS Corp.)

I would stick to the RequestAbsolutePath()-based solution due to its universality (version 3 of the protocol is quite outdated and certain servers might not support it or prefer to negotiate a higher version - while the path translation functionality is supported by the absolute majority of the servers).

We also use this solution in our higher-level SFTP solution, BizCrypto, and we had no compatibility issues with that approach whatsoever.

Ken
Also by EldoS: CallbackProcess
A component to control process creation and termination in Windows and .NET applications.

Reply

Statistics

Topic viewed 2438 times

Number of guests: 1, registered members: 0, in total hidden: 0




|

Back to top

As of July 15, 2016 EldoS Corporation will operate as a division of /n software inc. For more information, please read the announcement.

Got it!