Connecting with SSH.NET to OpenSSH 7.4p1 fails with "The server response contains a null character at position" but works in WinSCP

I am trying to connect to an SFTP server using SSH.NET (2020.0.0).

My code looks as simple as this:

try
{
    var x  = new ConnectionInfo(FtpIpAddress, 22, FtpUser,
        new PasswordAuthenticationMethod(FtpUser, FtpPw));

    using (var sftpClient = new SftpClient(x))
    {
       sftpClient.Connect();
       sftpClient.Disconnect();
    }
}
catch (Exception e)
{
    Console.WriteLine(e.Message);
}

But when I run the code, I get following error:

The server response contains a null character at position 0x00000028:  
00000000  53 53 48 2D 32 2E 30 2D 4F 70 65 6E 53 53 48 5F  SSH-2.0-OpenSSH_  
00000010  37 2E 34 70 31 20 44 65 62 69 61 6E 2D 31 30 2B  7.4p1 Debian-10+  
00000020  64 65 62 39 75 32 0A 00                          deb9u2..  
A server must not send a null character before the Protocol Version Exchange is complete.

I have no clue how to solve it, when using WinSCP manually it works fine, when using WinSCP.NET, it works fine as well with code. But I can not use WinSCP.NET on a Linux distribution.

So anyone got an idea what's wrong?

The SSH.NET (2020.0.0) expects that the SSH server version string ends with CRLF (0D0A) sequence.

Your server seems to send only LF (0A).

WinSCP is more tolerant – It's happy with the LF.

Checking the OpenSSH source code, it seems that OpenSSH 7.4p1 (only that specific version) is sending the LF only. Older versions did not have this problem. And it was fixed in OpenSSH 7.5. It seems that they didn't not even consider this a bug, as the change was not included in 7.5 release notes.

As you have found out yourself, SSH.NET 2016.1.0 is also happy with the LF only.

SSH.NET 2020.0.1 was released specifically to address this issue.

A completely different problem that can lead to the same error message: "The server response contains a null character" when connecting to FTP site on port 990 using SSH.NET.