I am trying to upload a file to a client server. However, they have some very strict security rules that secureBlackbox is having trouble complying with. Every other SFTP client I have tried works fine ( PuTTY, FileZilla, WinSCP..).

It seems that they may be rejecting the 'open' command that is initiated as part of the secureBlackbox 'uploadStream' funtion. They do not allow our user to overwrite files, and the open command being sent by secureBlackbox has a flag of 'truncate' and an SSH_FILEXFER_ATTR_PERMISSIONS value of 0666, which means full read/write access.

I have tried changing the transfer method on the upload Stream command to be ftmSkip instead of ftmOverwrite, but this does not actually change the open command (still includes 'truncate' and 0666). It just seems to add an extra 'stat' command first to check if the specfied file exists or not.

Is there a way of suppressing the truncate flag, or altering the SSH_FILEXFER_ATTR_PERMISSIONS attribute secureBlackbox is using when sending files?

Unfortunately, there is no way to suppress the Truncate flag at the moment. We will implement means for doing this in the future build update.

Regarding the permissions -- SBB does not request them at all, forcing the server to create the file under the default permissions. So the 0666 value is chosen by the server and is unlikely to be the reason for the problem.

However, this command is still being rejected by the sftp proxy we are connecting to. After asking the proxy admin, we got the following response:

Quote

Regarding these file transfers, it looks like commands SSH_FXP_OPEN or SSH_FXP_STAT are from a different version than SFTP V3.

It confirms my first hypothesis on the issue. Whatever configuration your client uses, it looks like your version settings (switched from V6 to V3) do not cover every part of your process. Please, could you have a look in your sftp client and see if there is no other parameters you have to update when forcing SFTP V3?

I would rather say that their SFTP proxy is not exactly standard-compliant in version 3, because version 3 is the most widely used one and SecureBlackbox has no problems transferring data using this version (the only problems that appear, are related to buffer size and use of pipelining, but both are solvable).

BTW it can be that you need to change buffer sizes too. BTW you can set AutoAdjustBufferSize to false, set pipelining to 1, AND also change SftpBufferSize (decrease it's value by 50%, for example) and UploadBlockSize.

Also (forgive me if I asked already, but there are many similar questions regarding SFTP so things are mixed up in memory), is it possible for us to have some test access to this server (if you have a contact with proxy admin, maybe we can arrange this in some way)?
If no, is it possible for us to get a copy of this proxy for testing?

This appears to be failing on the 'OpenFile' command, which comes before the 'Write' commands. Therefore, wouldn't the UploadBlockSize be irrelavant? We are manually writing the file using the 'Write' command in chunks of 1024 bytes.

However, I can try these changes though if you feel it would be worthwile?

Unfortunalty, due to out client's security policy, we do not have access to their SFTP server, or Proxy. We need to request any information we require from their end specifically.

Furthemore, they will not divulge what type of proxy they are using, so we can not even create a test instance.

Tom Marshall wrote:
This appears to be failing on the 'OpenFile' command, which comes before the 'Write' commands. Therefore, wouldn't the UploadBlockSize be irrelavant? We are manually writing the file using the 'Write' command in chunks of 1024 bytes.

You are right, if it fails during Open, this has nothing to do with buffer sizes. This was just a guess. Unfortunately I don't see what we can do in this situation - we would spend weeks trying to guess what kind of incompatibility their unknown proxy has.

BTW -- just a guess -- can you please re-check that you are passing the right file path (either relative or absolute) to the OpenFile/UploadStream method? The easiest way to check this is to try to upload the file using the SimpleSFTPDemo sample.

We use cookies to help provide you with the best possible online experience. By using this site, you agree that we may store and access cookies on your device. You can find out more about and set your own preferences here.