Error in downloading files because of SSH_FXP_STATUS and SSH_MSG_CHANNEL_CLOSE

[acloudmonk]

Hi,

We are facing one problem where we cannot download files from sftp client whereas its working normally if we are doing it manually and we are sure that this is related to sftp code.

To sum up, our R&D analysis show that the remote SFTP server does not reply as expected to a message extension. The fact that the extension is not supported by the server is not a problem, as this type of situation is handled and defined in the RFC. According to the RFC, if a message extension is not supported by the server, the server should send a SSH_FXP_STATUS with error/status set to SSH_FX_OK, but not with a SSH_MSG_CHANNEL_CLOSE. In our case, the server did not send the SSH_FXP_STATUS, and instead did reply by a SSH_MSG_CHANNEL_CLOSE, which is not correct according to the RFC.

[eikenb]

I'm sorrry, but I not sure I understand the problem. The SFTP library server code doesn't send SSH_MSG_CHANNEL_CLOSE anywhere, which makes me think you are bringing up a client issue. But then you talk about how it sends SSH_MSG_CHANNEL_CLOSE and how that is against the RFC.

Maybe restate the problem or provide some example code to reproduce it.

[acloudmonk]

we are using this sftp client https://www.weonlydo.com/SSHServer/ssh-telnet-server.asp?rnotes=1 and it look like we are not getting proper response from sftp server to our client. can we check what we are sending to each client and if that is correct as per RFC? i will collect some logs and other details if required.

[puellanivis]

So that we can be clear: you have what you feel is a non-RFC-compliant server (which you cannot control/fix/replace) and you would like to see support added to the client side of this package to support its aberrant behavior?

Unfortunately, reading the RFC behavior for SSH_MSG_CHANNEL_CLOSE, I cannot agree with your interpretation that responding with that message would be out of the spec:

When either party wishes to terminate the channel, it sends SSH_MSG_CHANNEL_CLOSE.

There is simply nothing we can do here. The server is perfectly within spec to close any connection for any reason by sending SSH_MSG_CHANNEL_CLOSE at any time. And we are not permitted to do anything but comply.

Unfortunately, I think the only way here forward, would be for you to isolate which message extension is triggering the server to close the connection, and then we can consider some way to set some option which would inform the client code to avoid using that extension. But until then·… there is nothing we can actually do. (And to not get your hopes up, perhaps the extension is so intricately necessary to our design that we cannot avoid using that extension.)

[acloudmonk]

I agree with you. one thing, i also checked that i was using the 1.8.3 version which is now i am going to upgrade in latest(1.10.0). do we have something in new release which already handling this in code?

[acloudmonk]

it look like below code also works in this scenario too: v1.10.0: client can now detect sftp connection close @eikenb eikenb tagged this on Feb 6 · 1 commit to master since this tag

Implments a clintConn.Wait() method. Fixes: #278

[eikenb]

It sounds like you figured out that the change for #278 also allows you to address your issue and so this issue can be closed?

[acloudmonk]

i have not tested this. i need some time to release it in production and test it with customer if this resolve the issue. Please hold this ticket for some days.

[acloudmonk]

customer is still getting the error. they are using asftp client "Axway B2Bi version 2.3.1"

[puellanivis]

I’m completely confused here. You’ve now stated two different SSH clients: Axway B2Bi version 2.3.1 (which was released in October 12, 2017) and weonlydo SSHServer (which besides being a server, is ActiveX, and unlikely to be Go code at all). So, neither of these seem related to this package. :confused:

What exactly are you connecting up to what, and how is this repo involved?

[acloudmonk]

Hi,

through this repository, we created sftp platform which is also use by our customer. one of our customer facing this issue. I got these two ssh client from customer and may be both are somehow related or dependent to each other.

customer is only getting error when they are downloading the files from our sftp server out directory. error is below: Reason(Event(Messaging.Transport.ReceiveFailure), Transport_Failure(Error(Incomplete data received), Transport_Error(SshException. Unexpected error: 'com.maverick.ssh.SshException: The channel unexpectedly terminated [Unknown cause]')))

I checked at our end and there is no error and in logs, its saying file transferred, session complete while in actual its failing for customer. I am not sure if this is client side issue or something in sftp repo which is causing this sftp client to fail?

[eikenb]

Hey @sachinsingh2005, sorry for the delayed response.

I'm not sure what else we can do with the information provided. There is no way for me to reproduce the issue and I've never seen the error before. It very well could be an error in the client (client's do all sorts of crazy things), but there is no way to be sure without more information.

Would it be possible to suggest for them to use a different sftp client?

[acloudmonk]

I am not sure if customer will use different client as they are using it from long time. what i will do that i will install client locally and will test it if that is failing or not. from this, we can validate if this is related to sftp client or sftp server.

[eikenb]

Sounds good. Please let me know what you find out.