Configuring Secure Shell for Key Authentication on Linux [A How-To Guide]

If you are a Linux admin or developer, chances are pretty good that you have to work on a remote server or two. When it comes time to log into those remote machines, there’s only one tool for the job—SSH (aka Secure Shell). 

For those that have never used the tool, SSH is a cryptographic network protocol for remote logging and operating network services securely over an unsecured network. With Secure Shell you can:

• Log into remote computers
• Run commands remotely
• Copy files to and from remote servers

Although SSH is far more secure out of the box than the protocol it replaced (telnet), there are still things you can do to make it more secure. This is especially important if you’re logging into remote machines housing sensitive data, such as application code for a .NET development company, or client information.

One of the most important steps you can take for the securing of SSH is to configure secure key authentication.

What is secure key authentication?

• Understanding secure key authentication is actually quite simple:
• You create a key pair (which contains a private and public key).
• You copy the public key to the server you want to log into.
• You log in using SSH key authentication.

Why is this more secure than the out-of-the-box encrypted password method is because, without the private key, you can’t log into the server. So unless you share that private key with someone, only you will be able to log in. It’s that simple.

You could, of course, share that key with all of the .NET developers on your team, or make them all create their own SSH keypairs for a more secure login process.

But how do you make this work? Let me show you.

Creating your SSH key pair

Before we dive into this, I’ll give you a bit of information about my setup. I’ll be demonstrating with a Pop!_OS Linux desktop and a Ubuntu 18.04 Server installation. The IP addresses of my test machines are:

• 192.168.1.7 - desktop
• 192.168.1.39 - server

The first thing to do is to create an SSH key pair on the desktop machine. Log in to the desktop, open a terminal window and issue the command:

ssh-keygen -t rsa

Answer the required questions for the key (they are straight forward) and make sure to give the key pair a strong password. Although you are given the option of creating the key pair without a password, do not do this. You definitely want a strong password for your key.

Copying your SSH public key

Next, we need to copy the SSH public key to the remote server. Fortunately, the developers of SSH have built-in a tool for this very purpose. The tool is the ssh-copy-id command, which does all the work for you. With a single command, you can copy your public key to the remote server and it will be saved in the correct location.

I’m going to assume your user name is the same on both desktop and server. To copy that key, go back to your terminal window and issue the command:

ssh-copy-id REMOTE_SERVER

Where REMOTE_SERVER is the IP address of the remote server. If we’re following my example, the command would be:

ssh-copy-id 192.168.1.39

You will be prompted for your remote user password. Once you successfully authenticate, the key is copied and you’re ready to log in.

If you want to go the manual route of copying your public key, you can do that as well. Here’s how. 

The first thing to do is to copy your public key. From the terminal window, issue the command:

less ~/.ssh/id_rsa.pub

The output of that command will start with ssh-rsa and end with USERNAME@HOSTNAME (where USERNAME is your username on the client machine and HOSTNAME is the hostname of the client machine). Copy that complete string of characters and paste it into a file.

You can then copy/paste the key to the

~/.ssh/authorized_keys

With that file copied to the remote servers, you can remotely log into that server from any machine that has a copy of the id_rsa key ( the private side of the key pair).

Conclusion

I would be remiss if I did not repeat that you must not give your private key away to anyone. If you do need to share a private key with a team, consider creating a separate account, outside of your regular user account, and only share the private key with those you know you can trust.

Other than that, you are set up and ready to go with SSH key authentication.