OK, so guys, let’s have a serious talk…

TL;DR - Just read the thing, it could keep you out of trouble, and in some jurisdictions out of jail.

The Internet is a scary place, especially when you work with potentially sensitive information. There are bad guys out there who would love to steal your sensitive information, we need to make it as difficult as possible for them.

One key tool in preventing the bad guys getting at your data is to always use encrypted connections when working with remote stuff. So make sure your links to web sites are https and not http.

When transferring files, there are very many options. Many businesses will use some form of file transfer protocol to transfer files full of information. A very long time ago, the standard was called (surprise surprise!) File Transfer Protocol (FTP). By default, FTP is not encrypted in any way, so it’s fallen out of favour.

The new(ish) hotness

The new (for some values of new, it’s been around for decades) hotness is Secure File Transfer Protocol (SFTP), this is built on top of the Secure Shell (SSH) protocol, which is strongly encrypted and strongly authenticated.

While SFTP does allow for simple username and password authentication, this is not the most secure way to tell an SFTP server that you are who you claim to be (a bad guy could have gotten hold of the password somehow, or even guessed it). A better method to use is Key authentication.

Key authentication, you say?

SFTP key authentication (which is exactly the same thing as SSH key authentication) makes use of two strong cryptographic tokens in a pair. One is a secret key and one is a public key that matches the secret key. When a client (a client is a program that uses a server) connects to a server, there is a complicated back-and-forth between the two involving encrypting, signing, and decrypting some challenges with the key pair to establish that the client has the secret key that matches the public key the server has for that username.

Note the important words above “the client has the secret key that matches the public key the server has for that username”. One crucial thing that many people (including some IT professionals) don’t always pay attention to is key handling.

Some important key handling principles

The secret key is a secret. A secret key must never leave the machine it was generated on, unless you have a very secure (as in, off the network) way of copying it. If an SFTP server administrator sends you a secret key to connect to their server, throw that compromised junk out immediately.

The public key is public information. Unlike the secret key, the public key is public information and can be sent to anyone. The public key is used on the server to identify the client that has the matching secret key. If someone decides to apply your public key on an SFTP account you don’t use it doesn’t matter. Either you will never even try to connect to that account, or it’s their fault for applying it to the wrong account if you do happen to connect to it.

The server only needs to know the public key. This follows on from the previous point. For the server to authenticate the client, it has to have the public key that matches the secret key the client is using.

SFTP servers allow for multiple public keys on one account. Remember the bit about secret keys being secret and not leaving the machine they were created on? If we keep to that, only one computer can connect using that secret key, but what happens if you have a second computer that also needs to connect to that one SFTP account? Simple, you generate a key pair on the second computer and send the public key of that pair to the SFTP server administrator to add as another authorized public key for your account.

So how do I handle keys?

If you are on the client side, generate keys pairs on all the computers you need to access the SFTP server from and send the public keys to the SFTP server provider to apply to your account. Then when you set up your SFTP client, such as FileZilla, tell it to use the secret key when connecting to that account. Never send your secret keys anywhere. If the SFTP server provider sends you a secret key, discard it and advise them to come read this blog post.

If you are on the server side, request that the client send you their public keys and apply those public keys as authorized keys on their account. Never generate a secret key for the client and send it to them. If the client accidentally sends you their secret key, delete it and advise the client to delete it and generate a new pair.

How do I create these keys?

Well now, that’s beyond the scope of this article, there are different ways of doing it depending on what client software you use.

I will, however, say that there are several different key types. My personal preference is to use ed25519, but ecdsa if the server doesn’t support ed25519 yet. If the server doesn’t support either, it is rather out of date, but a nice big (at least 2048 bit, but 4096 bit preferred) rsa key will do until the server is upgraded to support proper secure keys.