Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
sftpfs: don't set preferred hostkey methods too restrictively.
This fixes "sftp: failure establishing SSH session (-5)" error that may appear on some systems when using SFTP link feature. The error appears even when connecting to the same host via the "ssh" command works. Whether the error appears or not depends on the content of ~/.ssh/known_hosts file. Problem description: Midnight Commander uses ~/.ssh/known_hosts for two reasons. Obviously, one reason is checking for hostkey match after the SSH handshake. The second reason is to set preferences which host key the remote side should send us during the SSH handshake. And this is the problematic place. Entries in ~/.ssh/known_hosts store host names either in plain text or in a hashed form. libssh2 does not export host name hashes, only plain text host names. When mc tries to find a matching entry to set hostkey preferences, it cannot cannot reliably match the hashed host names. Before this change, mc assumed that any entry with hashed host name matches the connecting host and set hostkey preference to the type of that key. In many cases, this was incorrect. For example, when the first hashed entry in ~/.ssh/known_hosts appeared before the matching non-hashed one, and its key type was ssh-rsa, which is disabled by default since OpenSSH 8.8 (released 2021-09-26), then mc requested only the ssh-rsa host key from the remote host. Since this host key is likely disabled these days, no key was sent by the remote host and mc reported error -5 (LIBSSH2_ERROR_KEX_FAILURE). Solution: In this commit, we fix the problem as follows: 1. When finding a matching known_hosts entry in order to set the preferred hostkey method, we ignore the entries with hashed host names. If we find no matching entry with the plain text host name, no preference is set, resulting in the server sending us whatever key it wants and our libssh2 supports it. Likely, that key will match an entry with hashed host name later during the host key check. 2. If, on the other hand, a matching plain text entry is found, we use its type as a preference, but newly, we add other methods as a fallback. If the matched entry has a server-supported key type, it will be used. If it is not supported by the server (e.g. the old ssh-rsa type), the added fallback ensures that the server sends us some host key, which will likely match an entry with hashed host name later during the host key check. This solution is not ideal, but I think it's good enough. For example, the following situation is not solved ideally (I think): The known_hosts file contains a single entry for some server. It has a hashed host name and key of type B. Since we ignore hashed entries, the server can send its host key as type A, which is higher on the preference list. To the user, it will appear as that she has never connected to that server before. After accepting the new key, it will be added to known_hosts and the problem disappears. Ideal solution would IMHO be to create libssh2_knownhost_find() function in libssh2. It would allow finding all matching entries (even with hashed host names) in known_hosts. Midnight commander would then use all key types of found entries as its preference. Note: Since the code modified by this commit was inspired by code from curl, curl has the same problem. See libssh2/libssh2#676 (comment). Signed-off-by: Andrew Borodin <[email protected]>
- Loading branch information