SSH (Secure SHell) is a protocol that is used for remote administration of Linux systems. Obviously, it is secure, but what if I told you that you can make it even more secure by disabling the password?

Passwordless?

Yes, you heard it right, passwordless. Using it, you are able to just run:

user@client:$ ssh user@server
// connecting
user@server:$

Surely, it is convenient. But it is not just convenience and security: one task that absolutely needs it is automation. If you want your scripts (deployment, maintenance, etc.) to perform any SSH-related tasks, you will need this enabled.

But you might be wondering, how can it ever be secure? Surely, nothing can protect you more than a long password? In theory, yes. In practice, it is really easy to leak the password, forget it, use it elsewhere, or use a common one that can easily be hacked. Passwordless, on the other hand, is immune to all kinds of attacks, as long as your own system is not compromised or your attackers have a quantum computer. Fair to say, nothing is going to be secure when we get quantum computers, so let’s just ignore it for now.

So how does it work?

Firstly, you have to understand what public/private keys are. A private key is a very long, random stream of bits (2048 is used most often). private key is kept secret and never leaves the client (your PC). public key is another stream of bits, and it is derivative of private key. That is, you can generate a unique public key from the private key, but cannot get the private key from a public key, this is a one-way process. Think of it as a human fingerprint: a fingerprint can be used to (somewhat) uniquely identify humans, but you cannot recreate a human from only his fingerprint. Thus, your public key is available for everyone and is stored both on client and server.

Why do you need these pairs though? I will not go into advanced mathematics here, and it is not necessary. What you need to understand, though, is that these pairs have a unique feature. Using the public key, you can encrypt (or sign) any message, and it will only be possible to decrypt it using the private key. In other words, anyone with your public key can send you encrypted messages that only you will be able to read.

Sounds cool, isn’t it? Moreover, it is not limited to SSH. This principle is used in many applications around us, including HTTPS, FTPS, PGP (email encryption) and many others.

So, if the SSH server has your public key saved (this is important), it can authenticate you like this:

1. Encrypt a message using your public key and send it to client
2. Client decrypts the message using its private key and sends it back
3. Server ensures the message is decrypted correctly, and, if it is, authenticates the user

So, in the end, you are still using a password, just a more sophisticated one (more on that later).

How to set up passwordless SSH?

Firstly, you have to create a public/private key pair. Before we do that, let’s first make sure you do not overwrite any existing ones:

$ ls ~/.ssh

If in the output you see any id_rsa.pub files, skip to the next step. If not, or you see an error, you will need to generate a key pair. Do this by running:

$ ssh-keygen

Depending on your distro, this tool may or may not be included. If not, just install it using package manager of choice. ssh-keygen will ask you a number of things:

1. The filename to save, leave it default
2. Passphrase. This can be used to protect the private key with a password. This will help you achieve highest security as cost of convenience and automation. Leave empty for no password or enter one.

Once done, your public key will be saved in ~/.ssh/id_rsa.pub, and you can proceed to the next step.

Copy public key to SSH server

These are a number of approaches here. The easiest one is using ssh-copy-id tool. If it is not installed, install it using package manager of choice or proceed to the second method. Once available, you can use this tool like this:

$ ssh-copy-id -i ~/.ssh/id_rsa.pub user@server

Replace user and server with username and host, respectively. Then you will be prompted for your password on the server, just like a regular SSH connection. Once it is done, the tool will copy your public key to the server and SSH passwordless authentication now works!

If ssh-copy-id is not available on your system, there is another way using only built-in commands. Firstly, ensure that the .ssh folder exists on the server:

$ ssh user@server mkdir -p .ssh

This will execute mkdir -p .ssh on the remote server. -p argument means create if does not exist, which is precisely what we want. Once the folder is created, you can upload your keys like this:

$ cat ~/.ssh/id_rsa.pub | ssh user@server 'cat >> .ssh/authorized_keys'

This command will take the contents of ~/.ssh/id_rsa.pub and pipe them to the command cat >> .ssh/authorized_keys that is executed on the server. In it cat will forward the key to the .ssh/authorized_keys file. If it does not exist, it will be created, and if it exists, a line will be appended to it. This is it, you can start using the passwordless SSH login now!

Disabling password login

Even though you have enabled passwordless login, you are not secure yet. To be truly secure, you need to disable the password login altogether.

Proceed with caution. If you disable passwords and lose your private key, you will not be able to log in. A good practice is printing out your private key and storing it someplace safe

To do this, open and edit /etc/ssh/sshd_config and make these changes:

ChallengeResponseAuthentication no

This disables challenge response.

PasswordAuthentication no

This disables password.

UsePAM no

This disables PAM (Pluggable Authentication Modules)

PermitRootLogin no

This disables logging in as root (make sure you are in the sudoers group!)

Once you are done, reload the config by running:

$ systemctl reload ssh

If that does not work, replace ssh with sshd (on CentOS/RHEL/Fedora). That’s it, your SSH connection is as secure as it gets!

Closing notes

Thank you for reading, I hope you liked this artice. Let me know what your challenges with managing Linux systems so I can write more!

Resources

• man ssh
• A Deep Dive on End-to-End Encryption
• User Management in Linux Explained