Securing SSH Access with SSH Keys
Using passwords with SSH is inherently insecure; passwords can get lost, brute forced, and when administrating hundreds of machines, difficult to remember. This tutorial will show you an easier, more secure way to login via SSH. By using SSH keys, not only will you not need to ever remember a password again (unless you want) but breaking in using brute force alone is all but impossible using today's technology.

A SSH key is made up of two parts, a public key, which can optionally be password protected and a private key. The public key sits on the server while the private key is placed on the client side of the connection, or the computer that will be connecting to the server. When connecting, the private key is then compared with the public key and if there is a match, SSH access is granted. Even better, the same key pairs can be used on different machines ensuring ease of access when administrating numerous machines. In the interest of security, we still recommend only using one key per machine ensuring that if someone ever gains access to your public key (very rare, but possible), they cannot break into all of your machines.

Step 1 - Key Generation

First you will need to generate the public and private key on the client side. Most likely this will be the computer you are using to connect to the server.

ssh-keygen -t rsa

Step 2 - Store the Key and Set a Passphrase

Once you enter the commands from Step 1, you will be prompted with a few additional questions.

The first: Enter file in which to save the key (~/.ssh/id_rsa): is where you would like the public and private keys to be stored. If the default location is fine, just press enter, otherwise enter where you would like them stored

The second question: Enter passphrase (empty for no passphrase): is optional. This is where you will enter a password you wish to use as an additional security precaution. If you wish just to use a key to connect without needing a password, just press enter.

The entire process will look like:

ssh-keygen -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (~/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in ~/.ssh/id_rsa.
Your public key has been saved in ~/.ssh/
The key fingerprint is:
42:33:0d:cf:35:a9:00:ed:97:98:99:11:14:ad:a3:77 root@localhost
The key's randomart image is:
+--[ RSA 2048]----+
|            .2o     .   |
|    e        .  o  .E  |
|        +       .  o   |
|     . =       = .     |
| d        =    = .    |
|  o    + =     +     |
|           .  + o  .   |
|   ee     . o         |
|                        |

The public key is now located in ~/.ssh/ The private key (for use on the server) is now located in ~/.ssh/id_rsa. If you changed the storage location from step 2, they will be in the directory you specified.

Step 3 - Copy Public Key to the Server

Once the key has been generated, you will need to place the newly generated public key to the server you wish to use the key pair with. This command will copy the public key to the authorized_keys file on the server.

ssh-copy-id root@

You can also use the following (use the first example or this one, not both):

cat ~/.ssh/ | ssh root@ "mkdir -p ~/.ssh && cat >>  ~/.ssh/authorized_keys"

Be sure to change the username (root in the example) to the username you use to login to the password. The IP address ( in the example) should also be changed to your server's IP address.

You will be asked to enter your server's password one more time at which point, the public key will be installed.

Step 4 - Test the SSH Keys Generated

Try to login as you normally would with SSH:

ssh root@

Replacing root with the username you used earlier and with your IP address instead. You should have been able to login to the server via SSH without the need for entering a password (unless of course, you entered a passphrase).

Step 5 - Disable Password Logins for SSH (Optional)

This step is completely optional but highly recommended once you have thoroughly tested your new SSH key pairs and that is to disable the password logins for the SSH service on the server. Note that this will prevent anyone from accessing your server unless they have your public key pair installed on their computer or a public/private key pair of their own installed. It is recommended you make a backup of your public key (client side key) in a safe place so that you can get in should you lose the original.

vi /etc/ssh/sshd_config

Scroll down to PasswordAuthentication and change the yes to no

Save and exit vim. Restart the SSH Server service with the following command (may vary depending on Linux distro):

service sshd restart

Your server has now been secured to use a SSH public/private key pair only! No more of those annoying alerts that someone tried to login as root and (hopefully) used the wrong password. Without the proper key pair, the connection will fail. We recommend repeating this process for each additional server/client computer you need SSH access for. Although using the same public/private key pair for every client/server you administrate might be easier, it is a security risk.

If you are using a Windows client to connect via SSH to your Linux box, you may need to consult your SSH client's manual on how to generate a key pair and then upload the private key generated to the server. In most cases, it is pretty self explanatory. You can also use your Linux server to generate the key pair as well and just move the private key to the proper location it needs to be to be read by SSH and then download the public key to your client computer instead. If doing the later, pay attention to what key you are placing where as it might get a bit confusing working backwards!

Mean Servers hopes our tutorial on securing SSH access with SSH keys has helped you. Please note that this information is provided as-is and with no warranty or support. Implement this tutorial at your own risk and as always, backup your data regularly! These commands should only be performed be a true Linux administrator professional as there is a good chance you can accidentally delete important information or cause your server to become inaccessible if you do not know what you are doing.

  • Email, SSL
  • 0 Users Found This Useful
Was this answer helpful?

Related Articles

CSF Error: *WARNING* URLGET set to use LWP but perl module is not installed, reverting to HTTP::Tiny

A common error clients come across after initially installing the Cnfig Server Security and...

What firewall do you recommend to secure my Linux server?

Mean Servers recommends the CSF (ConfigServer Security & Firewall) firewall for all clients...

Installing CSF (ConfigServer Security & Firewall)

The CSF, ConfigServer Security & Firewall, is a powerful firewall that is made for Linux...

CSF Error: Unable to connect to

This tutorial has been written to help resolve a CSF dependency issue in regards to running...

Reduce spam with the Mean Servers SBL

Mean Servers runs a DNSBL that specializes on spam received via addresses scrapped from public...