| 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 access to a computer is locked and only somebody with the keys can get in. You need to set up some keys before you set up your computer. 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 . Microsoft Windows from version 10 onwards has the necessary command but the name is slightly different. You also need some software called Git Bash, which you can install from here.
Your key files will be created in a directory called .ssh in your home directory, for example 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 can be password protected, in which case you need to supply the password to use it. If somebody gets hold of your computer, the key is no use without the password.
SSH keys have all sorts of uses. First, check that you haven't already created a pair of key files months or years ago, and forgotten. Under Microsoft Windows, start a Git Bash window. On a Mac, start a terminal.
In the resulting window, type
ls $HOME/.ssh
and press the Enter (Return) key.
(To copy and paste that command under Windows, copy the text as normal, right click in the Git Bash window, which produces a dropdown menu, and use the Paste option. On a Mac, use the Edit menu and choose Paste.)
If that produces something like
ls: cannot access '/home/simon/.ssh': No such file or directory
then you don't have a .ssh directory,
or any key files.
If the ls command lists some files, look for pairs of key files. The private key file can have any name and the public key file has the same name but with ".pub" on the end, for example private key file id_rsa and public key file id_rsa.pub. If you can see files like that, you already have some keys. If they are password protected, you need to remember the password to use them.
If you have no usable keys, you need to create a new one. You can create keys with any name so you can avoid trashing your existmg ones - you might remember sometime what they are for. Under Windows start a command window and run ssh-keygen Under any other system, use ssh_keygen - an underscore rather than a hyphen.
Create the key in a command window. Under Microsoft Windows, type "cmd" into the search box at the bottom of the screen and click on the black icon marked Command Prompt that appears. In the windows that appears, type
ssh-keygen
and press the Enter key.
On a Mac,
start a terminal and type
ssh_keygen
followed by the Enter key.
The command will take you through creating a pair of key files. You can accept the default filenames or tell it to use names of your choice. As you will see, you will need these key files when you set up 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 with your public key, produces the original challenge.
Strictly, I know that the email was sent by somebody who has a copy of 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 a network to another computer (the remote machine). The difference is that all the challenge and response stuff goes on automaticall behind the scenes.
As we will see later, when you set up your remote machine, you supply your public key.
If all this seems to be a bit complicated and daunting, it's worth saying that if you have a chip and pin credit card you are already using a similar system. The chip in your card contains a key file which is password protected. The password is your Personal Identification Number (PIN). The bank that issued the card runs a computer that contains matching key files. When the till in a shop demands your pin, the chip unlocks the key file and it's used to set up a secure session between the till and the bank's computer system, allowing the till to debit your account. The bank is assured that this can only happen if the person at the till has the card and knows the PIN. All this clever stuff is done behind the scenes. You just present your card and type in the PIN.
The SSH 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, if you set up a server and connect it to the Internet, 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, because to connect you need a copy of the private key as well as its password.
You can use an SSH key pair to authenticate yourself on all sort of systems. For example github.com .
To access a remote machine in this manner, you must have a copy of your private key in your .ssh directory on that computer. If you want to do this from more than one computer, you nmust copy the keys onto each of them. (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.
If you have an account called simon on a computer called example.com and its authentication system uses ssh keys, you can connect from a Git Bash terminal (on Windows) or a terminal window (on a Mac) using the ssh command like so:
ssh simon@example.com
The ssh command rummages through the .ssh directory, finds the right key file and connects to the server as the user simon.
Once you are connected to the remote machine, the command that you type run there, not on your local machine.
End the session and disconnect by holding down the ctrl key and typing a single "d". No need to hit the enter key. Now any command that you type in the command window runs on your local computer.
Of course things are not always that simple ....
You may have to help ssh along by telling it where to find your private key file:
ssh -i ~/.ssh/id_rsa simon@example.com
If you only have the IP address of the computer rather than its name, you can use that:
ssh simon@192.168.0.64
You can make life easier for yourself by creating a text file called "config" in your .ssh directory. The config file contains entries like this:
Host example
HostName example.com
User simon
IdentityFile c:/Users/simon/.ssh/sihg/id_rsa
Host defines the name by which the remote computer will be known on your computer. It can be any name you like. HostName defines the computer's real name on the network, User defines the account used when connecting and IdentityFile defines the private key file.
Now you can just connect using the name that you gave the computer, in this case "example":
ssh example
The ssh command connects to the given HostName as the given User, using the given IdentityFile to authenticate.
If you have lots of key file pairs in your .ssh directory and/or you use them to connect to lots of computers, the ssh command can get confused and stop working properly. A config file irons out the confusions.
I advise that you set up all of your networked computers so that they can only be accessed using SSH keys. If the computer you are connecting to is owned by somebody else, they may require you to use a pasword instead. (Apparently not everybody listens to my opinions on how computers should be run.) The config entry for that would be something like this:
Host someotherexample
HostName someotherexample.com
User simon
PasswordAuthentication yes
When you connect to someotherexample using ssh, it will ask you for the password.
| Contents Page | Next --> |