Please help me dispel any confusion I may have about my Windows 2019 Server OpenSSH SFTP configuration. I've seen online that there are so many different ways to set this up and I'm trying to make heads or tails of it. I've currently got it working fine with username/password authentication against ActiveDirectory. My goal is to make SFTP use as simple as possible for my client users from their very first experience with it--while at the same time maintain a high degree of data security during file transfers by employing encryption.
Unfortunately, my experience with encryption is that I must create client certificates that have to be imported by client computers in order for data transmissions to be encrypted between them and my server. This is the case when I set up a VPN, for example. It's complicated.
Likewise, I thought I had to use the SSH keygen commands to create keys that I would then have to install on my client computers as well as on my server in order to enable OpenSSH's SFTP to safely encrypt file transfers. This makes the process somewhat tedious for my clients.
However, I am seeing now that upon initial login into my SFTP server, I get an interactive warning stating,
The authenticity of host 'blablabla.booboo.beep.haha.com (xxx.xxx.xxx.xxx)' can't be established. ECDSA key fingerprint is SHA256:XYZA3yyyyyGGGG/aaaaaYYYYYNosUXXXXGi/NNNNN1iE. Are you sure you want to continue connecting (yes/no)?
If I say "yes", then I get,
Warning: Permanently added 'blablabla.booboo.beep.haha.com' (ECDSA) to the list of known hosts.
Consequently, in my profile's .ssh folder, a known_hosts file gets a long random string appended to it which links back to my server name. That string isn't exactly the same as the interactive SFTP message I saw, but there must be some relation.
Does the above mean that some unique server key from my Windows 2019 OpenSSH installation has already been exchanged automatically with my Windows 10 client, thereby making it unnecessary for me to have to manually import any keys in either machine in order to encrypt the data transfers henceforth? That would be a sweet out-of-the-box experience!
If it's not so, then is there a way to get encryption to work with minimal effort (i.e., no additional steps required by client users other than establishing their SFTP session) and still prevent data snooping during file transfers?
For example, web servers can get a SSL/TLS certificate installed to secure and encrypt communications with web visitors, yet the web visitors usually don't have to consciously install any client side certificates for that to work. I understand those certificates are purchased by web hosts and can be automatically validated by any client web browser worldwide with trustworthy third-party sources.
Is such an easy-to-use scenario possible with SFTP, or are there any other easy alternatives that can keep my data transfers secure without having to complicate the initial client user setup?
The authenticity of host ... Are you sure you want to continue connecting (yes/no)?prompt , followed by an answer of “yes” without further inspection of the fingerprint of the key- does not secure your users against “man in the middle” type of attacks but otherwise you get pretty good transport security and encryption.