-
-
Notifications
You must be signed in to change notification settings - Fork 941
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Exception thrown when the server SSH identification is missing its"softwareversion" part #822
Comments
@chsoft-ag: I have the same issue with an external SFTP provider. Do you find a solution or a workaround? |
@toxis: In our case, the server was using proprietary software of the server owner and they changed their side to correctly provide the software version. Since that was the only occurrence so far, we had no reason to further look for a fix or workaround. |
I came across the same issue, forked the repo and changed the regex for parsing the version string to Version 2 mentioned in #749, looks good now and hope that this tolerant parsing will be incorporated as it is sometimes hard, slow or impossible to make someone change the server configuration. |
Consider raising a PR? |
created a PR, reverted back to only a minimal change of the regex, as there where some tests failing with the expression from #749 |
Co-authored-by: Martin Dörig <[email protected]>
We have actually run into a server in the wild which only provides an identification string of "SSH-2.0-" and omits the "softwareversion" part required by the standard. This leads to SSH.NET throwing an exception
`Renci.SshNet.Common.SshConnectionException: The server response contains a null character at position 0x0000000B:
00000000 53 53 48 2D 32 2E 30 2D 0D 0A 00 SSH-2.0-...
A server must not send a null character before the Protocol Version Exchange is complete.`
I've seen that there had been some discussion about less strict parsing in #749, with a suggestion of a potential strict/lenient property to allow for non-conforming servers that do not provide the software version part. Any thoughts on actually going forward with such a leniency option?
We've contacted the server operator about their non-conformance, but no idea if they have any interest in fixing this as apparently other clients are more forgiving about a missing software version. FileZilla for example connects without issues.
The text was updated successfully, but these errors were encountered: