0

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?

ShieldOfSalvation
  • 261
  • 5
  • 15
  • `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. – HBruijn Apr 09 '19 at 23:30
  • So supposing I give my fingerprint detail in text form to my users to visually verify against what they see in the interactive warning, would that suffice? I suppose that's what the warning's cryptic information is intended to be used for. Are you saying that in fact, encryption is already active for my file transfers from here on? – ShieldOfSalvation Apr 09 '19 at 23:33
  • Yes, inspect the fingerprint over a second independent channel (other options than manual exist with for instance instance https://tools.ietf.org/html/rfc4255) and if good then scp, sftp And ssh will be encrypted – HBruijn Apr 09 '19 at 23:45
  • That's fantastic! I did follow your RFC link, but unfortunately Azure (my server host) does not currently support DNSSEC. This desired feature is gathering support though! (https://feedback.azure.com/forums/217313-networking/suggestions/13284393-azure-dns-needs-dnssec-support) For now, I guess it will have to be a manual verification. – ShieldOfSalvation Apr 09 '19 at 23:52
  • Why not use something like FileZilla as the SFTP client? It would be much easier than the command line for the vast majority of users. – Michael Hampton Apr 10 '19 at 00:47
  • Of course! I will do that. It's just that whether it was FileZilla or the command line, I wasn't sure whether I needed to take additional steps to enforce data transfer encryption past giving everyone a username and password. I thought that the username/password authentication I had set up simply wouldn't be enough, that I had to manually also set up encryption keys and import them myself on both client and server sides or ask my client users to do so. That was daunting for them. But from the looks of the comments above, all that won't be necessary! – ShieldOfSalvation Apr 10 '19 at 00:52

0 Answers0