SSH is a great way to gain remote access to your computer. Similar to FTP, you can connect over SSH FTP to gain secure access to a file server with your favorite FTP client, quickly accessing remote files, or even mounting a network disk to your computer. But there's more to SSH than remote file access. Logging in over SSH in Terminal (or using PuTTY on Windows) gives you remote shell access (after all, SSH is short for Secure SHell). It's how I manage my media server from a distance.

When you open the ports on your router (port 22 to be exact) you can not only access your SSH server from within your local network, but from anywhere in the world.

However, you don't want to risk using a weak password for authentication. If anyone gains access to your computer over SSH, they gain complete shell access. Just to be clear, that's not something we want. Luckily, it's very easy to set up your global SSH server in a very secure manner by using key-based authentication and disabling password authentication on your server altogether.

Is This For Me?

It's tempting to grow lax with personal security. If you're using the server for private means, you might think that people simply don't know about your server and hence won't try to hack it -- security through obscurity. That would be a very wrong assumption. Because (most) SSH traffic is transmitted on port 22, attackers routinely check the visibility of port 22 on random IP addresses, followed by a brute force attack. This is one of the ways botnets are made for use in DDOS attacks.

To make a long story short: if you broadcast your SSH server over the internet (i.e. forward port 22), then yes, this is for you.

The Idea of Key-Based SSH Log-ins

Key-based SSH logins rely on the idea of public key cryptography. It would take us too far to explain the intricacies, but we'll try to paint a simple picture of what is going on behind the scenes.

In the process below, your client computer generates two keys: a public key and a private key. The general idea is that you can encrypt data with the public key, but only decrypt it with the private key. We'll put the public key on the server and ask it to encrypt all outgoing communication with it. This makes sure that only those clients with the private key can decrypt and read the data.

1. Install OpenSSH

First, we're going to set up an SSH server using OpenSSH. If you already have an SSH server running and just want to know how to set up key-based authentication, you can skip this step. Use your favorite packet manager to install the OpenSSH server application. The simplest way might still be to run the apt-get command from the Terminal.

        sudo apt-get install openssh-server
    

Enter your password, confirm and wait a minute for it to finish installing. Congratulations, you now have an SSH server. (That was easy!)

ubuntu-install-openssh

You can either use the application as-is, or edit

        /etc/ssh/sshd_config
    

to configure it. Run the

        man sshd_config
    

command in Terminal to get more information. Another great resource to learn more about OpenSSH is the relevant Ubuntu help page.

2. Generate Keys

We'll generate a set of keys. Run the following commands (adapted from the OpenSSH/Keys Ubuntu Help page).

        mkdir ~/.ssh
    
        chmod 700 ~/.ssh
    
        ssh-keygen -t rsa
    

The first command creates a hidden directory '.ssh' in your home folder, the second command changes the access permissions of the folder while the third command actually generates a set of RSA keys. You'll first be asked for a location to save the keys (leave blank and press enter to save in the default location) and second for a passphrase.

rsa-key-generation-mac

This passphrase further encrypts the private key that's stored on your computer, essentially giving you more time to secure the SSH server if your private key is ever stolen. Make sure you choose a passphrase you're able to remember, as you'll have to enter it when you try to use your key.

3. Transfer The Public Key

Next, you'll need to transfer the public key you generated in the previous step to the SSH server computer. If your client machine also runs Linux, this can be achieved very easily by running the below command (substituting <username> and <host> for the username and IP address on your SSH server).

        ssh-copy-id <strong><username></strong>@<strong><host></strong>
    

If your client doesn't support the ssh-copy-id command, you can use the below command instead. It's a bit more convoluted, but essentially achieves the same results.

        cat ~/.ssh/id_rsa.pub | ssh <strong><username></strong>@<strong><host></strong> "mkdir ~/.ssh; cat >> ~/.ssh/authorized_keys"
    

You'll be asked to enter the user password for the SSH server. If the commands execute without errors, your public key will have been copied to the server.

4. Disable Password Authentication

Notice that your system still isn't more secure than after step one. Although at least one client is configured to use key-based authentication, this still leaves room for other clients to connect with a password. To finish, we'll disable password authentication altogether. After this step, only computers that have gone through the above process can connect to your SSH server.

To disable password authentication, edit the 

        /etc/ssh/sshd_config
    

file in your favorite editor. One of the easiest ways to edit a restricted file is, again, using Terminal. (I'm partial to nano, but you can use whatever you're most comfortable with.)

        sudo nano /etc/ssh/sshd_config
    

About 40 lines from the bottom of the file, you'll find

        #PasswordAuthentication yes
    

Remove the number sign (#) and change the setting to 'no', as below.

        PasswordAuthentication no
    

The final file should look something like this:

sshd_config

Save the file by pressing CTRL+X. Confirm the edit and the filename, and you're almost done. Just restart the SSH server to run it with these new settings.

        sudo restart ssh
    

You'll also notice that your client will stop asking for the passphrase to decrypt your key if password authentication is disabled on the server. Now that you have a secure SSH server, how do you intend to use it? As a secure file server, a remote shell, or to forward other services over SSH? Let us know in the comments section below!

Image credit: Shutterstock