Setting up SSH and Using Identity Keys

Imagine you have a computer that you want to access while you are not physically near it. How do we access this computer, but more importantly, how do we do so securely? Secure Shell is a technology that lets you connect to computers that are running the SSH server software remotely using the SSH client. Using cryptography it establishes a connection to the remote server securely and allows the client to issue commands as if they were accessing it physically.

Using SSH

Let us suppose we have a remote computer on our network, but physically located elsewhere. This machine is called the host. Our hypothetical host has an IPv4 address of 194.168.0.0, but it doesn’t have to be an IP address, it can be a resolvable domain name or an alias too. The host we are connecting to has a few different user accounts with various privileges. Naturally each user has – or should have – a password too. For our hypothetical machine we have the root user, as well as george.

Those three components, the host, user, and password, are all you will need to connect to a machine using SSH straight out the gate; You do this by opening up your terminal and entering the following:

# we call 'ssh' then provide our info structured like so...
ssh user@host

# using our example credentials...
ssh root@194.168.0.0

This will present a prompt for that user’s password, and once authenticated will enable the client computer to interact with the remote computer as that user.

There is one problem with our example; We logged into root remotely. This is a security risk so we need to stop root being accessible via ssh.

If you are going to be configuring your machine remotely do not lock root out until you have another user. After root is locked out and there isn’t another user you can use with sudo, you’re locked out indefinitely.

Configuring the SSH server

The SSH server runs as a daemon named sshd on your system, and configuring sshd is a simple task. The sshd config file is at /etc/ssh/sshd_config so using a text editor open that file with sudo.

sudo vim /etc/ssh/sshd_config

There are a few settings here that we should change, such as PermitRootLogin which you want to change from yes to no.

You also want to enable public key authentication so that we can deny the use of passwords to log in, giving us two settings that we should change. PubkeyAuthentication yes and PasswordAuthentication no.

The sshd_config file once edited should have the following settings:

PermitRootLogin no
PubkeyAuthorization yes
PasswordAuthentication no

Before you make these changes follow the steps in the next section to allow a remote computer to connect with authentication keys! If you do not have physical access to the remote machine you will be locked out if you disable the use of passwords before setting up your authentication keys.

Creating our authentication key pair

One way of beefing up your security when connecting remotely using SSH is through the use of authentication keys. Authentication keys increase security and productivity by eliminating the need for passwords. By not using the remote user password it stops it from leaking in the event that our client machine becomes compromised, leading to our remote machine also becoming vulnerable.

Creating a key pair is a quick and easy process involving a single command:

ssh-keygen -t rsa

By default this will save a private key (id_rsa) and public key (id_rsa.pub) into your active directory. It is important that you, as the name implies, keep your private key private. The client uses the public key to authorise the client, so you can share the public key freely with little consequence.

During key creation you can name your keys, as well as give your keys password protection for added security if you wish to do so.

Authenticating our private key

Now that we have created our key pair we need to make sure that the user that we want to login to on the remote server can access the public key. This way whenever we attempt to login, the server will use that public key to verify that you own the private key. Therefore, we need to send our public key to the server for it to use. There are several ways that we can achieve this.

physical transfer

Copy your public key (id_rsa.pub) to a USB pen drive.
Go to the remote machine and log into the user you are authenticating.
Now, assuming that our USB is mounted at /media/usb we want to append our public key to the users authorized_keys file:

cat /media/usb/id_rsa.pub >> ~/.ssh/authorized_keys

What this does is take the contents of the id_rsa.pub file and appends (shell command ‘>>‘) the contents to the authorized_keys file. This file contains all public keys that are permitted to the account.

remote transfer

If you can log onto the server using a password, we can also use secure copy (scp) to send the file to the server and then perform the previous steps.

send the public key to the remote server using scp
append the contents of the public key to the authorized_keys file.
remove the public key from remote.

scp ~/.ssh/id_rsa.pub george@194.168.0.0:~/.ssh/
cat ~/.ssh/id_rsa.pub >> authorized_keys
rm ~/.ssh/id_rsa.pub

However, you can cut down on all of those commands by using the ssh-copy-id command. Again, this does require that you can login to the remote machine with a password.

ssh-copy-id -i ~/.ssh/id_rsa.pub george@194.168.0.0

The only difference here is the -i option, which indicates the public key you want to copy to the remote.

Passwordless, but…

We can now login to our remote machine without a password if you have followed along so far. To do this, we login using ssh as usual, except when you next run the ssh command you won’t require a password!

Note: If you save your private key to its own folder you will need to use the -i option to point to the private key you are using.

ssh -i ~/.ssh/keys/website_rsa user@host

With this guide so far we have been using IPv4 addresses to log into our remote machines. This is fine if we only have one or two remotes to login to that we can memorise the addresses; But what if we also have multiple identity keys? Firstly, having to store, memorise, and type long commands and having to remember which private key goes with which host can be a bit tedious. Thankfully there’s a solution to that; The config file.

Setting up client config

The config file allows us to specify options for various different hosts. We can use the config file to turn an ugly connection command that takes time and effort to type out into the simplest thing in the world.

We want to transform the following command which is used to connect to an imaginary remote server on port 12345, into something easier to work with. Imagine every time you wanted to ssh into the server you have to type the following:

ssh -i ~/.ssh/keys/work/server1_rsa workuser13524@203.0.113.0 -p 12345

To make this easier, we need to be aware of a number of important components to the config file.

Host specifies a name, or an alias to refer to your remote host.
User specifies the user on that remote host that you will be connecting to.
HostName is the IPv4 or resolvable domain name that we have so far been using.
Port is to be used if the remote uses a different port to the default 22.
PubkeyAuthentication tells ssh that we want to use a private key to connect.
IdentityFile is a path to your identity file.

Let’s create our config file. Within the users ~/.ssh folder, if a config file does not already exist use ‘touch config‘ and then open the file in your favourite editor. The following is the config entry that we can use for our example:

Host workserver
    User workuser13524
    HostName 203.0.113.0
    Port 12345
    PubkeyAuthentication yes
    IdentityFile ~~/.ssh/keys/work/server1_rsa

Save your config file, and that’s it. Now, when we want to connect to our hypothetical work server, we won’t need to type in that lengthy command or, because we set up auth keys, our password. We just type the following:

ssh workserver

The SSH client handles the rest. We get logged in, no password needed, no typing for ten minutes having to make sure you got the username right, the IP address right, the port correct, it’s just all done for you.

Note

I have written this post as much for myself as it was for others. If you know of better ways to do this, or feel that I am doing things incorrectly and know better methods I would appreciate you commenting and letting me know.