SFTP Public Key Authentication

Using SFTP public key authentication is a great step towards securing your sftp server.

In this article, I'll run through our step-by-step instructions for getting SFTP public key authentication working for your users, along with an explanation of the main terms.

Setting up SFTP public key authentication - Basic Instructions

1. [Client-side] Generate a public/private key-pair
2. [Client-side] Add private key to client software
3. [Server-side] Add public key to user's account
4. [Client-side] Connect to server
5. [Client-side] Smile (or not)

Setting up SFTP public key authentication - Detailed Instructions

1. [Client-side] Generate a public/private key-pair: your SFTP client application may be able to do this for you, otherwise you can use a tool such as ssh-keygen (*NIX/OSX) or PuTTYgen (Windows). Some servers, such as CompleteFTP can also generate key-pairs. The reason why it's recommended to do it on the client-side though is that ideally the private key is only ever stored on the client machine. A key-pair usually consists of two files: one for the private key and one for the public key.
2. [Client-side] Add private key to client software: in client applications such as FileZilla and WinSCP private keys can be added via the GUI. In console clients the path to the private key file can be provided either on the command-line or in a configuration file. Software components such as edtFTPj/PRO and edtFTPnet/PRO have methods or properties for reading in the private key. If the key-pair was generated on the client-side then the user should already be in possession of the private key. If it was generated on the server-side then the server administrator must send it to the client user so that they can add it to the client software.
3. [Server-side] Add public key to user's account: Servers with GUI administration clients will usually allow you to add one or more public keys for each user. Obviously this requires you to obtain a copy of the public key. If the key-pair was generated on the client-side, as it ideally should've been then the client user should send it to the server administrator so that they can add it to the user's account. Conversely, if the server administrator generated it (not recommended) then they will already have the public key and they should send the private key to the user.
4. [Client-side] Connect to server: the client should now be able to connect to the server. They generally only need their user-name and their private key, but sometimes a password is also required.
5. [Client-side] Smile (or not): if the connection fails without a clear error-message then check the logs of the server, or ask the server administrator to do this. The server will often deliberately withhold detailed information on failed authentications so as not to provide unintended assistance to hackers.

Definitions

Key

A cryptographic key is the digital equivalent a real-world key that you lock a safe with. You can use it to encrypt and/or decrypt data. Encrypting data is like putting it in a safe and locking the safe. Decrypting is like unlocking the safe and taking the data out. When data is encrypted it can be passed around safely, with the knowledge that it can't be unlocked by anyone who doesn't have the key. This form of key is called an 'symmetric key' since the same key can be used to lock and unlock the safe.

Public/private key-pair

A public/private key-pair consists of two related keys: the public key and the private key. They are paired so that any data encrypted with one can only be decrypted with the other. This means that if you give copies of one of the keys (the public key) to all your friends, and send messages to them that are encrypted with the other key (the private key), then they'll know that it definitely you who sent it.

Public Key Authentication

Public key authentication relies on the ability of public/private key-pairs described above, that is, data encrypted with one key can only be decrypted with the other. When the server asks the client to authenticate, the client uses the private key to encrypt some data that is already known by the server (e.g. the user-name); the client sends the encrypted data back to the server; the server decrypts it with the public key. If the decrypted data matches the known data then it must've been encrypted with the private key. The server thereby knows that the client has possession of the private key and assumes that it's therefore OK to permit access. This illustrates the importance of keeping the private key confidential.

SFTP

SFTP is a protocol that allows file-transfer over SSH connections. It's not just encrypted FTP like a lot of people think, but an entirely different protocol. It has a major advantage over FTP in that it uses only one connection (usually on port 22), which means that it can operate through firewalls by simply allowing a single port through.

SSH

SSH stands for Secure Shell. It was designed for secure terminal connections over the Internet. It did not originally support file-transfer. File transfer was added later via SFTP and SCP.