SFTP authentication failed

Question

I get the below exception when I try to Authorize using _sftp.Login(UserName, Password);
Message="SFTP subsystem request has failed."

Can you help me know what the issue could be?

With WinScp I get the below log:
. 2020-03-25 16:55:48.321 Server refused to start a shell/command
* 2020-03-25 16:55:48.345 (EFatal) Server refused to start a shell/command
* 2020-03-25 16:55:48.345 Authentication log (see session log for details):
* 2020-03-25 16:55:48.345 Using username "xyz".
* 2020-03-25 16:55:48.345
* 2020-03-25 16:55:48.345 Authentication failed.

Answer 1

This looks like the server is actually running SSH and accepting your credentials, but it's not willing to actually start an SFTP subsystem for the user. To find out the reason, you would have to check out the server logs.

Comments

SFTP server is running on linux kernel.
It seems the connection can be established from Linux terminal.
Are there any Rebex properties to set that bridges the difference between Windows and Linux ?

Here is the trace:
pc123@pc123-Lat:~$ sftp Administrator@1.2.3.4
The authenticity of host '1.2.3.4 (1.2.3.4)' can't be established.
ECDSA key fingerprint is SHA256:7LXexyz.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '1.2.3.4' (ECDSA) to the list of known hosts.
Administrator@1.2.3.4's password:
Connected to 1.2.3.4.

---

Rebex SFTP bridges the difference between Windows and Linux by default.

If the server is running on Linux, then it's most likely OpenSSH, the most common SSH server. Rebex SFTP should work out-of-the-box with OpenSSH (and other SSH/SFTP servers), no matter whether the server is running on Linux or Windows or other OS, and we are running automated tests to ensure we stay compatible with OpenSSH (and with other servers).

Based on the above, we assume that your issue is not due an incompatibility between different operating systems (or SFTP/SSH clients and servers), but due to some  aspect of the configuration of the particular server you are connecting to.

To find out why the server reported this error, please check out the server log, or ask the server administrator to check out the log to find out the reason. For example, the following article discusses one instance of an equivalent error, along with its cause: http://linuxhostingsupport.net/blog/sftp-error-subsystem-request-for-sftp-failed-subsystem-not-found

---

We find that the below command is getting executed in linux terminal before sftp.
ssh-keygen -f "/home/xyz/.ssh/known_hosts" -R 1.2.3.4

Can you help me know why it is done (like whitelisting?) and how to do it with Rebex libraries.

---

According to OpenSSH manual (http://man7.org/linux/man-pages/man1/ssh-keygen.1.html), such ssh-keygen command removes "1.2.3.4" from the current user's list of known SSH hosts. I cannot think of any good reasons to do that, other that executing it manually (and only once) when the server's SSH key has been changed intentionally.

But if it is getting executed every time, it would be a very harmful practice, as it effectively makes OpenSSH's clients bypass SSH server key verification with the server at 1.2.3.4. This disables an essential part of the security provided by SSH and opens the door for man-in-the-middle attacks - making it possible for anyone with control over your network traffic to impersonate the real SSH server to the client and intercepting all your communication.

If this is indeed what you would like to achieve with Rebex SFTP,  just don't check the server's key or fingerprint (don't check Sftp's Fingerprint or Sftp's ServerKey, and don't use Sftp's FingerprintCheck event to check them - see https://www.rebex.net/sftp.net/features/security.aspx#verify-fingerprint for more information). But due to the reasons above, such practice is strongly discouraged.

The recommended practice is for general purpose SFTP/SSH clients should to make sure the SSH server key provided by the server once has not been changed when connecting the next time (and displaying the key to the user on first connection). With Rebex SFTP, this is the responsibility of the application (otherwise, Rebex SFTP would have to keep a database of known hosts similar to OpenSSH client's), but it should not be neglected due to the reasons above.

For applications using SFTP/SSH internally, keeping the server's host key along with the server's host name and port (in a configuration file, database, etc.) is the recommended practice.

---

There is also 'yes' supplied by user. Can you help me know how to provide that in rebex API?

:~$ sftp Administrator@1.2.3.4
The authenticity of host '1.2.3.4 (1.2.3.4)' can't be established.
ECDSA key fingerprint is SHA256:123456789.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '1.2.3.4' (ECDSA) to the list of known hosts.

---

Thanks, this confirms the purpose of that particular command was to make the SSH client connect to whatever server is listening at 1.2.3.4, without ensuring that it's actually the known server.

To achieve the same with Rebex SFTP, simply do not check the server's SSH key (use the code like this, and do not verify the server's key or fingerprint between the Connect and Login methods: https://www.rebex.net/sftp.net/features/easy-to-use-api.aspx#transfer-file