SFTP server authentication via known_hosts check

[asdfasdfasdf]

Hi,
it seems to me, that FFS doesn't consolidate the .ssh/known_hosts file when it establishes a SFTP connection, and just happily connects to any (potentially malicious) server.

(Why do I think this? Because it didn't complain when connecting to a server whose fingerprint I previously removed from the known_hosts file.)

I'm concerned about this because of the following scenario:
- I have a SFTP server at home (say at 192.168.1.2), to which I sync at 10am via a cronjob and FFS.
- At some days, however, I'm connected to other networks (in the same 192.168.0.0/16 range) at that time, say, my employer's office network.
- My concern: what if some malicious actor in the office network somehow learns that I try to connect to a 192.168.1.2 SFTP server, and creates a SFTP server at that IP address which just accepts any user connection? Then my data would end up in the wrong hands.

A suitable fix would be to check whether the server's SSH key's fingerprint matches a fingerprint in .ssh/known_hosts and, if not, prompt the user "Server unknown (fingerprint: <...>). Accept connection?".

If I'm wrong here, or there's a workaround that I'm not aware of (besides creating an external script that checks the known_hosts file and only then runs the FFS batch job), please tell me.

Otherwise, it's a really great product - thank you!

Cheers,
Jonathan

[xCSxXenon]

In your testing, where you removed the fingerprint of a server, did you also try connecting via the native file manager or another software? If that works, then FFS isn't alone here, but if it doesn't, FFS is definitely the target of this behavior. Just inquiring in case the fingerprint is saved somewhere else unknowingly. The FFS code is available, I suppose one could dig through to see if SSH is handled via a package or implemented internally.

[asdfasdfasdf]

I removed the fingerprint via `ssh-keygen -R 192.168.1.2`. I then tried to connect via OpenSSH (i.e., `ssh me@192.168.1.2`) and it gave me the "The authenticity of host '192.168.1.2 (192.168.1.2)' can't be established. [...]" message. My backup.ffs_batch script, however, just ran as always, without any message. I have not tried with other software.

I've taken a very brief look at the FFS code:
- It seems like libssh2 (https://libssh2.org/) handles the underlying SSH connection:
- https://github.com/hkneptune/FreeFileSync/blob/master/libssh2/libssh2_wrap.h
- https://github.com/hkneptune/FreeFileSync/blob/master/FreeFileSync/Source/afs/sftp.cpp
- I couldn't find any calls to `libssh2_knownhost_*`, meaning, FFS probably just doesn't check the known_hosts file.

I'm not very familiar with the FFS code, nor with libssh2, but to fix it one should probably introduce the `libssh2_knownhosts_*` stuff after a successful SSH handshake in line 250 in sftp.cpp (https://github.com/hkneptune/FreeFileSync/blob/master/FreeFileSync/Source/afs/sftp.cpp#L250). I just saw that there's a comment at exactly that position, that seems like a TODO to me that might be related to our discussion:
```
//evaluate fingerprint = libssh2_hostkey_hash(sshSession_, LIBSSH2_HOSTKEY_HASH_SHA1) ???
```