Secure Remote Linux Server Logins with SSH Key Authentication
If you do any remote work on Linux servers (or containers), you most likely do so by way of a secure shell (SSH). And although the title of the software has “secure” in it, you shouldn’t assume that it’s locked down by default. Sure, it’s far more secure than, say, the old-school telnet but these days you always need to go the extra mile to ensure the safety of your systems and data.
Out of the box, Secure Shell works exactly how you might expect it to: with a username and password. So you issue the command ssh email@example.com and you’ll be prompted for the password for the user ralph on the server associated with example.com.
There’s a better way of doing this, one that is far less likely to lead to server break-ins. That method is SSH key authentication.
SSH key authentication works with an SSH key pair that is generated on your local machine. The key pair is comprised of a private and public key. The private key remains safe on your local machine and the public key is sent to the server you want to remote into. With the key pair in place, any time you log into the machine, the keys do a handshake to verify they match. If those keys match, you are given access to the server. If the keys don’t match, you’re out of luck.
This set up is far more secure than traditional username/password authentication and should be used for every Linux server you use.
Let me show you how to make SSH key authentication a reality.
What You Need
For this demonstration, you’ll need at least two Linux machines — one local and one remote. Since this is all done via the command line, you don’t have to have a desktop environment configured. Of course, you’ll need the IP address or domain of the remote server and the local machine must be able to remotely access remote server.
Create an SSH Key Pair
The first thing you need to do is generate your SSH key pair. This is done on your local client. Log into that machine and create the keypair with the command:
You’ll be asked where to store the key (default location is ~/.ssh) and will then be prompted to type and verify a password for the key pair. Make sure to use a strong/unique password for this.
The above command will generate two files: id_rsa (the private key) and id_rsa.pub (the public key).
Copy Your Key to the Remote Machine
The next step is to copy your public key to the remote machine. Fortunately, SSH has a feature built in to make this easy. To copy the key, simply run the following command:
Where USER is your Linux username and SERVER is the IP address or domain of the remote server. You will first be prompted for the remote user’s SSH password. Upon successful authentication, the public key will be saved to the ~/.ssh directory on the remote server.
You can then test SSH key authentication by attempting to log into the remote machine again, with:
Where USER is the username and SERVER is either the IP address or domain of the remote server. This time, you’ll be prompted for the SSH key password (and not your user password).
Congratulations, SSH key authentication is now working.
However, we can up the security even more.
Configure the SSH Server for Heightened Security
Before you take this next step, make sure to generate key pairs and copy the public key to the server on any client machines that need to have access to the remote server. If you don’t take care of this step, you’ll find those machines incapable of logging in (even with valid user accounts). The only way around this would be to manually copy/paste the contents of the SSH public key from the client machine to the ~/.ssh/authorized_keys file on the server.
What we’re going to do now is make sure public key authentication is enabled and password authentication is disabled (both on the remote server).
Open the SSH daemon configuration file (on the remote server) for editing with the command:
sudo nano /etc/ssh/sshd_config
First, look for the line:
Change that line to:
Next, look for the line:
Change that line to:
Save and close the file.
Restart SSH with the command:
sudo systemctl restart sshd
Before you exit from the current connection, open another terminal window (on a machine that you copied the public key to the server) and attempt to log in via SSH. If you are allowed access, you’ve successfully ensured the only way to log in via SSH is with key authentication.
At this point, anyone attempting to log in to your Linux server without a matching key pair will be denied.