| Contents Page | Next --> |
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. I believe that Windows from version 10 onwards has the necessary software, otherwise use the instructions in this page. It suggests two options, PuTTY and Git Bash. I suggest you use the Git Bash option, and in these notes I will assume that you have.
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. In your command window, type
ls ~/.ssh
ls: cannot access '/home/simon/.ssh': No such file or directory
If the ls command lists some files, check that id_rsa and id_rsa.pub are not already present. If they are, you already have what you need.
Create your keys using the ssh_keygen command. On a Mac, start a terminal and run the command in that. I believe that this command is now standard in Windows, so you can run it in a command window. (To start a command window, type "cmd" in the search bar at the bottom of the screen and double click on the black icon that appears.) If not, run it in a Git Bash window.
In all cases, run the command like so:
ssh_keygen
The command will take you through creating the files.
To create id_rsa and
id_rsa.pub,
just follow the default actions.
You can choose another name when you create your keys
but it make things a bit easier if you stick to the defaults.
As you will see, you will need these key files
when you create your server.
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.
Strictly, 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.
(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.)
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. 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. 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.
| Contents Page | Next |