That error indicates that the server rejected the authentication attempt. Unfortunately, the SSH protocol doesn’t make it possible for the client to determine the exact reason, so the actual cause cannot be reported by the client. The only way to determine the cause is to check the server log which should state clearly why it rejected client’s authentication attempt.
However, in most cases, when Rebex SFTP triggers the “A public key corresponding to the supplied private key was not accepted by the server or the user name is incorrect” exception, a wrong username or public key is the cause. Other possible causes include temporary authentication outage at the server (seems unlikely) or some kind of incompatibility (possible but rare).
To address the problem, try following these steps:
1. Double-check once more that you are in fact connecting to the same server, same port, using the same username, password and key.
2. If no misconfiguration is discovered, see if it’s possible to check out the server log to see why it is rejecting the authentication attempts.
3. If this is not possible or doesn’t reveal any clues, try experimenting a bit. First, if authenticating using both a public key and a password (this does not refer to the private key password), try submitting the password before the public key:
sftp.Settings.TryPasswordFirst = true;
4. Otherwise (or if the above doesn't help), try announcing the public key to the server before attempting authentication:
sftp.Settings.EnsureKeyAcceptable = true;
5. Of that doesn't help either, try enable signature padding to rule out the possibility that the server suffers from a padding bug in RSA signature validation:
sftp.Settings.EnableSignaturePadding = true; // if this doesn’t help, make sure to remove this!
6. If nothing above helps, try using a third-part SFTP client (such as WinSCP) that can create a verbose communication log. Then compare that with the Rebex log to see whether there is any difference in the way the two clients try authenticating. We can help with this. (As far as I know, Filezilla cannot produce such verbose log.)