How To Authenticate Over SSH With Keys Instead of Passwords

key   How To Authenticate Over SSH With Keys Instead of PasswordsSSH 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   How To Authenticate Over SSH With Keys Instead of Passwords

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   How To Authenticate Over SSH With Keys Instead of Passwords

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 <username>@<host>

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 <username>@<host> "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   How To Authenticate Over SSH With Keys Instead of Passwords

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

The comments were closed because the article is more than 180 days old.

If you have any questions related to what's mentioned in the article or need help with any computer issue, ask it on MakeUseOf Answers—We and our community will be more than happy to help.

5 Comments -

0 votes

Lee

My college has an open source lab (which is neat because it’s mostly student run, including the server room) and they use an interesting method to secure their servers. They have one server that is public-facing (for SSH anyway) and the rest aren’t. To access the other servers, you have to SSH into the public server first and then use that to SSH into the other servers.

I suppose it’s not much use if someone figures out your password (and you use the same password for the public server as the private ones) but they would need to know the address of the private servers too.

0 votes

jasray

It really helps, maybe more than anything else, that port 22 isn’t used. Period. Not essential for a full and fast functioning SSH server.

0 votes

Simon Slangen

You’re right, but most people will end up using a port from the higher ranges anyway. Forwarding low ports on your router can normally only be done through root.

0 votes

Aram Iskenderian

If you have a fairly modern/updated install of Linux (almost all of the new distros)It is as simple as

1. At the computer/server you want to access from, run:
ssh-keygen
Follow the on screen prompts
If the keys were generated earlier you will be warned, if that’s the case, you can skip this step.

2. From the same computer/server, run:
ssh-copy-id username@targetserver

You will be prompted for the password. If provided properly and you did not see any error message, that will be the last time you are prompted for a password.

To test, from the same computer/server run.
ssh username@targetserver

You should be logged in at the target server without any password prompts.

0 votes

Simon Slangen

Yep, that’s similar what we did in steps 2 and 3. Thanks for sharing.