"Bad message" error when Renci SSH.NET calls SSH_FXP_OPENDIR

[n0h]

We have a .NET application that uses the Renci SSH.NET library to connect to an SFTP server.

In one of our test environments we started using PowerShell OpenSSH as the SFTP server. It was working fine as of v0.0.4.0. But it broke in v0.0.5.0, and we have tested the later releases through v0.0.8.0 with the same results. We have tried SSH.NET versions 2014.4.6.0 and 2016.0.0 and see the same behavior. Other SFTP clients like WinSCP and FileZilla do not encounter the errors.

Our .NET application encounters the error when calling the following method:
Renci.SshNet.SftpClient.ListDirectory(string path, Action<int> listCallback = null)

This method internally calls Renci.SshNet.Sftp.SftpSession.RequestOpenDir(String path, Boolean nullOnError) which tries SSH_FXP_OPENDIR, and that is where the Renci.SshNet.Common.SshException gets thrown.

Here is the stack trace where the error occurs:

Renci.SshNet.dll!Renci.SshNet.Sftp.SftpSession.RequestOpenDir.AnonymousMethod__37(Renci.SshNet.Sftp.Responses.SftpStatusResponse response) Line 567          C#
Renci.SshNet.dll!Renci.SshNet.Sftp.Requests.SftpRequest.Complete(Renci.SshNet.Sftp.Responses.SftpResponse response) Line 30            C#
Renci.SshNet.dll!Renci.SshNet.Sftp.SftpSession.HandleResponse(Renci.SshNet.Sftp.Responses.SftpResponse response) Line 1159        C#
Renci.SshNet.dll!Renci.SshNet.Sftp.SftpSession.OnDataReceived(uint dataTypeCode, byte[] data) Line 226                C#
Renci.SshNet.dll!Renci.SshNet.SubsystemSession.Channel_DataReceived(object sender, Renci.SshNet.Common.ChannelDataEventArgs e) Line 189          C#
Renci.SshNet.dll!Renci.SshNet.Channels.Channel.OnData(byte[] data) Line 331 C#
Renci.SshNet.dll!Renci.SshNet.Channels.Channel.OnChannelData(object sender, Renci.SshNet.MessageEventArgs<Renci.SshNet.Messages.Connection.ChannelDataMessage> e) Line 686          C#
Renci.SshNet.dll!Renci.SshNet.Session.OnChannelDataReceived(Renci.SshNet.Messages.Connection.ChannelDataMessage message) Line 1531         C#
Renci.SshNet.dll!Renci.SshNet.Session.HandleMessage(Renci.SshNet.Messages.Connection.ChannelDataMessage message) Line 1185         C#
[External Code]
Renci.SshNet.dll!Renci.SshNet.Session.HandleMessageCore(Renci.SshNet.Messages.Message message) Line 16  C#
Renci.SshNet.dll!Renci.SshNet.Session.MessageListener() Line 1767       C#
Renci.SshNet.dll!Renci.SshNet.Session.Connect.AnonymousMethod__4() Line 587        C#
Renci.SshNet.dll!Renci.SshNet.Session.ExecuteThread.AnonymousMethod__3c(object o) Line 25          C#

Here is the stack trace where the exception is caught:

Renci.SshNet.dll!Renci.SshNet.Sftp.SftpSession.RequestOpenDir(string path, bool nullOnError) Line 578                C#
Renci.SshNet.dll!Renci.SshNet.SftpClient.InternalListDirectory(string path, System.Action<int> listCallback) Line 1589             C#
Renci.SshNet.dll!Renci.SshNet.SftpClient.ListDirectory(string path, System.Action<int> listCallback) Line 451                C#

We are logging this against PowerShell OpenSSH rather than SSH.NET because SSH.NET can connect to other SFTP servers without errors, and it could connect to v0.0.4.0 of PowerShell OpenSSH without errors.

[bagajjal]

1. I'm unable to download the SSH.NET (any version) through package manager console,
   

2. Since its working with other SFTP clients like WinSCP and FileZilla, its possible that the issue is with SSH.NET as well. I can't comment unless I reproduce it. Please help us in reproducing the problem.

[n0h]

You may be trying to install SSH.NET into a project that's not targeting a framework that's supported by SSH.NET. The supported frameworks are listed on their GitHub readme which can be viewed at https://github.com/sshnet/SSH.NET/#framework-support .

This means that you will most likely just need to change the project properties. In Visual Studio, for a C# console application setup, a user would open the project, click Project->"project name" Properties...->Application tab, and the target is available as a dropdown.
For us specifically, we're targeting .NET Framework 4.5.

[n0h]

Attached is a sample project that you should be able to use to reproduce the issue.
SshNetTest.zip

From our developer:
It doesn't have the SSH.NET DLL, but it has the source code in the solution so that you can debug and edit easily. It should be easy to remove the project reference and install the DLL if you prefer -- I'm just not able to debug when I do that. I really don't know why, but a guess is that the DLL doesn't have debugging information.

[bagajjal]

Thanks for attaching the sample project.

The bug is with the Renci SSH.NET library.

Its appending the current working directory to the path passed based on the assumption that the full path always starts with the "/". In windows the paths doesn't start with "/" so their code is appending the current working directory to the path passed. This is working earlier because of a bug in our code which is now fixed.

You can verify the path received at the server side by enabling the sftp verbose logs.

I am closing this bug. You can file a bug against the Renci SSH.NET team.

[bagajjal]

sftp server logs (enable verbose logs)..

[n0h]

Thank you for looking into this, we will log it with SSH.NET.

My only further question for this project is whether there could be an improvement to the way this error is handled or reported back to the sftp client, keeping in mind the goal of not diverging unnecessarily from OpenSSH main line. Thanks again.

[bagajjal]

We are not diverging from the OpenSSH main line. We adhere to the SSH protocol that's the reason the other SSH clients like winscp and FileZilla are working..

There are changes required when we move from unix world to windows world because of the file systems are different (file paths representation), etc.

[n0h]

Sorry, just to clarify my last comment. I didn't intend to suggest that this project is diverging or should diverge from the main line.

What I meant is that even if the error message is somewhat unclear, I recognize that changing/improving it wouldn't be feasible if doing so required a divergence from how OpenSSH main does things. And as you mentioned, it's not even just OpenSSH main, but the SSH protocol, which apparently defines the error codes. So I retract my last question.