Securing SSH: Disable Password Logins (Require SSH Key to Login)

SSH — Secure Shell — is a common method of securely logging into a remote server. First released in the mid 1990’s, it’s estimated that more than 2 million people now use SSH. Over the years, SSH has proven itself to be pretty secure, but by changing some of the default settings and behaviors it can be made even more secure.

This article is the first in a series that will cover some of the basic principles behind making SSH more secure. This introductory article will detail how to generate an SSH key, and then disable password logins for SSH. It will then cover a couple of basic security measures and best practices for securing your SSH key.

Why disable password logins?

When it comes to security, passwords are typically one of the weakest links. Secure passwords are usually hard to remember so users tend to compensate by reusing passwords for multiple accounts, writing down their passwords, or using weak passwords whenever they can get away with it. Using passwords also increases the risk of bruteforce attacks since the average user doesn’t use strong enough passwords to sufficiently stop all attacks.

Security aside, another great reason to disable password logins for SSH is convenience. When managing dozens, hundreds, or even thousands of servers, trying to use unique passwords or even typing in the same “secure” password each time is inconvenient at best, and verges on impossible at worst.

0. Generate an SSH keypair

Instead of a password, your SSH key is what you will use to login to your servers. If you already have an SSH key then you can skip this step. If you don’t know if you have an SSH key, then you probably don’t.

Run the following command to start creating your SSH key:

You’ll then be asked a couple of questions. The default answers are usually fine if you’re not sure what to answer.

The first question is where to save your SSH key. The default location is /home/you/.ssh/id_rsa.

The next question asks if you want to use a passphrase for your key. This step is completely optional if you want to add an extra layer of security. If I’m honest, I rarely use a passphrase and don’t know many people that do

That’s it, now your key will be generated and saved, and you’ll see output similar to the following:

A couple of things to note

Notice in the output of the above command that there were actually two files generated, one of which has a .pub extension. These two files together are what’s known as a keypair. The one with .pub extension is the public part of the keypair.

The above command generates an RSA key with a size of 4096 bytes. This is a pretty lengthy key (some would say borderline paranoid, and it might be, but I say better safe than sorry) but using a key this size shouldn’t cause any problems in 99% of situations.

1. Add your SSH key to other servers

Now that you have your SSH keypair generated you’ll want to add the public key to all of the servers you’ll be logging into. On most Linux distros you can use the ssh-copy-id command to do this. Note that a different method may be required for AWS EC2 instances, where a .pem key is required.

  • Replace /home/you/.ssh/ with the path to your public key (the one ending in .pub)
  • Replace user@host with the user and hostname of the remote server

If done correctly you should see similar output:

To test, try logging into the remote server. If you are able to login without entering a password then it worked:

3. Disable password logins

It’s important that you follow the previous steps before doing this, or you might get locked out of your server!

Begin by making a backup copy of the sshd_config file:

Open /etc/ssh/sshd_config for editing:

There are three directives that must be edited to disable passwords: ChallengeResponseAuthentication, PasswordAuthentication, and UsePAM. All three of these should be set to no.

After saving your changes SSH must be restarted:

Downsides and Warnings

There are a few of caveats to be aware of if you plan to disable password logins:

  • If your key is stolen or otherwise compromised – just like with a password that you use on multiple sites, if your key is ever compromised then the attacker will [theoretically] have access to all of the servers that use your key (there are other security measures that can be put in place to help stop attackers.)
  • If your key is ever lost – as you might have guessed, losing your key could mean being completely locked out of your server.
  • Reissuing keys – If you ever need to reissue keys (that is, create new keys) then you will have to repeat the above steps on each of your servers to replace your old key.

Securing and maintaining your SSH key

If you plan on using your SSH key to login, especially to production servers, then you want to make sure you secure it and keep up with it. Here are a couple of tips that might help:

Have multiple copies

Just like with your normal backups, you should have multiple copies of your key (you do have multiple copies of your backups, right?).

Ideally, you would have encrypted copies of your key stored in multiple places, including at least one offsite.

Print your keypair on paper

Your SSH key is basically just a bunch of random letters and numbers. As such, you can physically print your keypair on paper, and put it in a safe or safety deposit box (not in your filing cabinet!)

It would be painstaking work, but if you ever lost your key you could manually recreate it by typing it out from your printed copy.

Be sure to print the contents of both your private key (id_rsa) and your public key (

Take your key with you

Another option is to buy a sturdy thumbdrive and use it to store a (preferably encrypted) copy of your key. You can then throw this thumbdrive in your bag or put in on your key chain. This way you always have a copy of your key exactly when you need it.

Wrapping Up

In this article we covered how to generate an SSH keypair, add the public key to remote servers, and then disable password logins. These are the first of several steps that sysdamins should take to secure SSH on their servers. In future parts of this series we’ll discuss how to disable root login, restrict SSH access to certain users, and more.

Leave a Reply

Your email address will not be published. Required fields are marked *