Goblimey 

SSH Authentication Keys

To access your server securely, you need ssh keys. These are just two plain text files stored on your local machine, one public and one private. They're called keys because your droplet will be locked and only somebody with the keys can get in. You need to set up some keys before you create your droplet. I believe that you can set up keys on a smartphone, but I never have. Here I assume that you are using a laptop or desktop computer.

If you use a Mac see this document.

If you use Microsoft Windows version 10 or newer, see this document.

If you have an older version of Windows, use the instructions here. That document suggests two options, PuTTY and Git Bash. I suggest you use the Git Bash option.

Unfortunately the resulting command is called ssh_keygen (with an underscore) on a Mac but ssh-keygen (with a hyphen) on some Windows machines.

If you take the defaults when you create your keys, they will be created in a directory called .ssh in your home directory. You will produce files in there called id_rsa (your private key) and id_rsa.pub (your public key). You need to keep the contents of the private key file to yourself, but it's safe to let anyone see the contents of your public key. That's the essential idea - nobody else knows what's in your private key file but anybody can know what's in your public key file. The private key is password protected. You need to supply the password to use it.

First, check that you haven't already created a pair of key files months or years ago, and forgotten. If so, the files that you need will be in the .ssh directory in your home directory

If not, create your keys using the ssh_keygen command (or possibly ssh-keygen). On a Mac, start a terminal and run the command in that. Under Windows, start a command window and run the command in that. (Type "cmd" in the search bar at the bottom of the screen and double click on the black icon that appears.)

You should create a pair of files id_rsa and id_rsa.pub. On a Mac, that's the default action. Under Windows 11 the command tries to use different names but you can change them to the default.

The files contain encryption keys. If you take a piece of text and encrypt it using your private key, somebody else can use the matching public key to decrypt it.

You can use the keys to authenticate yourself - verify your identity. It goes something like this: We meet up and you give me a copy of your public key file. We agree a piece of text, say "Abracadabra". This text is called the challenge. Later, you want to send me an email which is guaranteed to come from you and not some imposter. You encrypt the agreed challenge with your private key and put the result in the email. The encrypted version is a pile of unreadable junk. If I can decrypt this junk with your public key and the result is "Abracadabra", then I know that it was you that sent the email, because only your private key can produce the unreadable junk that, when decrypted, produces the challenge.

(To be pedantic, I know that the email was sent by somebody who has the private key that matches the public key that you gave me, which is why you need to keep the contents of your private key to yourself. Also, the scheme only works if we meet up, so that I know that it was really you that gave me the public key. That's called "the key distribution problem.")

The same principle can be used to authenticate yourself and log in from the computer on your desk (the local machine) across the Internet to the computer you are renting from the hosting company (the remote machine). As we will see later, when you set up your remote machine, you supply your public key. Under the covers, the authentication procedure goes something like this: when you try to log into the remote machine from your local machine, behind the scenes the two machines agree a challenge. Your local computer encrypts the challenge using your private key and sends the result across the Internet to the remote machine. The remote machine decrypts what it receives using your public key and checks that the decrypted version matches the agreed challenge. If so, it lets you log in. You still have to supply a password to open your key, but it's not sent across the network. The Internet is a public medium and various people could be monitoring the traffic between the two computers, but they can only see the encrypted challenge and they can't use what they can see to masquerade as you and log in to your server.

Actually, the scheme is a bit more complicated than that, to prevent an eavesdropper simply copying the encrypted challenge and reusing it, but that's the general idea.

As we will see, as soon as you set up your server, people will try to log into it using software that guesses passwords. If any of your users have passwords, however complex, the password guessers will succeed eventually. The key mechanism allows you to create users on your server that don't have a password and can only connect to it using the keys. Authenticating using keys rather than passwords is much more secure.

You can use an SSH key pair to authenticate yourself on all sort of systems. For example github.com .

If you create keys on one computer to access a remote system, and you want to connect to it from another computer, you have to create a .ssh directory in your home directory on the second computer and copy the keys across. (Don't forget to set the access permissions - the private key should be readable only by you.)

If you overwrite or remove your key files, you can't recreate them, so you will lose access to whichever system you were using them to connect to. It's a good idea to keep a backup copy on a memory stick.