Bump SSH version string for new versions. Incorporate derived client app name

[denisbider]

In Bitvise case 29613, we have identified that there exist deployed Renci.SshNet clients which advertise a maximum channel packet size larger than the actual SSH packet size accepted by the client.

Specifically, the client advertises a maximum channel packet size of 65536, but does not accept a packet of length 39452.

I suspect the application that uses Renci.SshNet is most likely using a version older than CodePlex commit 34953, which appears to be the first version that implemented a flexible maximum packet size larger than 35000 bytes:

https://sshnet.codeplex.com/SourceControl/changeset/view/34953#Renci.SshClient/Renci.SshNet/Session.cs

Previous versions, up to commit 34949, had a fixed maximum packet size:

https://sshnet.codeplex.com/SourceControl/changeset/view/34949#Renci.SshClient/Renci.SshNet/Session.cs

However, the client would send a maximum channel packet size larger than 35000 bytes if the user of SshNet instructed this:

https://sshnet.codeplex.com/SourceControl/changeset/view/34949#Renci.SshClient/Renci.SshNet/Channels/Channel.cs

Due to this behavior of a particular user of Renci.SshNet, we are implementing a workaround in Bitvise SSH Server which will detect the version string:

"Renci.SshNet.SshClient.0.0.1"

... and will limit packet size to a safe value when the client sends a matching SSH version.

Unfortunately, it looks like all Renci.SshNet versions that have existed over the years currently use this same version string. This means this workaround will also apply to current SshNet versions.

I propose the following improvements:

• Increment the version number sent by Renci.SshNet in its SSH version string whenever a new version is released.

• Add a setting for the user to disable sending the exact version number, in case they wish to disable this. According to our experience, some users will want this.

• Require the application developer to pass a name for their application. Incorporate that name into the SSH version string.

If you make these changes, the pattern "Renci.SshNet.SshClient.0.0.1" will no longer match, and future versions of Renci.SshNet will avoid the compatibility workaround in our SSH Server.

In addition, if you incorporate an application name in the SSH version string, it will be possible to implement compatibility workarounds that apply only to a particular Renci.SshNet application that has a particular, specific bug.

[drieseng]

Sorry if you guys have to implement a workaround for an issue we introduced.

Before we discuss a solution, I'd first like to be able to confirm that such an issue exists and in what version of SSH.NET.

I'm not yet convinced that the issue existed up to commit 34949. The Channel class is internal, so a client would not be able to modify the maximum channel packet size.

Perhaps the issue exists in newer versions in which we advertise support for a 64 KB packet size when we open a channel. Perhaps there's a bug due to which we don't actually support a packet of that size.

Do you happen to have a public-facing Bitvise server available that I can test against?

[denisbider]

Hey!

Thank you for looking into this.

I have more information from the user, and it looks like you're correct that the user is not supplying the incorrect maximum packet size.

Instead, it looks like the issue is that the SshNet version being used by this user is conflating local and remote max packet sizes. In the channel open confirmation sent by the client, it looks like it simply echoes back to the server the maximum packet size received in the server's channel open.

So you are correct that this issue was a bug in SshNet, rather than an error by the user. However, it does appear that the issue was last present in the CodePlex commit I identified above (34949), and that it was fixed in the other commit I identified (34953).

In commit 34953, it appears SshNet begun to properly distinguish local and remote max packet size.

[denisbider]

We welcome any testing you might be able to do using Bitvise SSH Server, and encourage you to download it from here:

https://www.bitvise.com/ssh-server-download

The SSH Server can be installed as Personal Edition free of charge. Speaking as an authorized representative of Bitvise, we have no problem with the use of the Personal Edition for testing and development, and encourage its use.

Current SSH Server versions will work on any desktop or server edition of Windows starting with XP and 2003, and up to Windows 10 and 2016.

The current latest version, 7.26-r2, already implements the workaround I discussed above. To test without the workaround, you can do the following:

• Raise the product version sent by Renci.SshNet in its SSH version string, e.g. from 0.0.1 to 0.0.2; or to any value that does not contain "-0.0.1". (Note that raising it to 0.0.10 will continue to trigger the workaround.)

• Alternately, you can test the last version that did not implement the workaround. This is version 7.25, which can be downloaded here:

  https://bvdl.s3-eu-west-1.amazonaws.com/BvSshServer-725.exe