This is a known Strato issue.
There is something wrong with Strato server’s implementations of rsa-sha2-256 host key cipher. This cipher is supposed to use SHA-256 hash algorithm for its RSA signature (see RFC 8332), but the signature received from Strato's server is actually a signature based on SHA-1. Therefore, Rebex SFTP client rejects this mismatched signature, which is correct behavior.
Interestingly, common SFTP/SSH clients such as WinSCP, FileZilla and PuTTY’s psftp do not support RFC 8332 and the rsa-sha2-256 cipher yet, which means that they are not affected by this server-side issue.
Disabling rsa-sha2-256 (and rsa-sha2-512 which is also not working properly at Strato’s server) in Rebex SFTP makes it connect successfully as well:
var client = new Sftp();
client.Settings.SshParameters.SetHostKeyAlgorithms("ssh-rsa", "ssh-dss", "x509v3-sign-rsa", "x509v3-sign-dss", "ecdsa-sha2-nistp256");
client.LogWriter = new ConsoleLogWriter(LogLevel.Debug);
client.Connect("ssh.strato.de");
For the sake of completeness, these are lists of supported host key ciphers of WinSCP, FileZilla (as of 2019-09-01) and Rebex SFTP (with default settings), in order of preference:
- WinSCP:
ssh-ed25519,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-rsa,ssh-dss
- FileZilla:
ssh-rsa,ssh-ed25519,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-dss
- Rebex SFTP:
rsa-sha2-256,ssh-rsa-sha256@ssh.com,rsa-sha2-512,ssh-rsa,ssh-dss,x509v3-sign-rsa-sha256@ssh.com,x509v3-sign-rsa,x509v3-sign-dss,ecdsa-sha2-nistp256
The server at ssh.strato.de claims to support the following ciphers:
ecdsa-sha2-nistp256,ssh-ed25519,rsa-sha2-512,rsa-sha2-256,ssh-rsa,ssh-dss
This means that the following ciphers are negotiated:
- WinSCP uses
ssh-ed25519 by default
- FileZilla uses
ssh-rsa by default
- Rebex SFTP uses
rsa-sha2-256 by default (and runs into an issue because the server’s implementation is broken)
We strongly recommend reporting this issue to Strato so they can fix it. Our customer who originally reported this issue in September 2019 informed us that they are going to ask their customers to report it as well, but apparently the problem still persists as of February 2020.
