Disabling Password Authentication on Linux Servers

On this post we are going to explain how to add ssh keys to login to a Linux server and disable password authentication to increase the security of our VPS(Virtual Private Servers).

The problem

By default, when we create or deploy a VPS with Linux, password authentication for users is enabled. This is a big problem because we are letting the possibility for attackers to get access to our servers. To have an idea of the magnitude of this issue let’s check the file /etc/var/auth.log of a server under attack:

Feb 12 17:39:36 pruebas sshd[2453]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=103.59.40.178
Feb 12 17:39:38 pruebas sshd[2452]: Failed password for invalid user its from 103.59.40.178 port 51298 ssh2
Feb 12 17:39:38 pruebas sshd[2453]: Failed password for invalid user alyssa from 103.59.40.178 port 51432 ssh2
Feb 12 17:39:38 pruebas sshd[2452]: Received disconnect from 103.59.40.178: 11: Bye Bye [preauth]
Feb 12 17:39:38 pruebas sshd[2453]: Received disconnect from 103.59.40.178: 11: Bye Bye [preauth]
Feb 12 17:39:39 pruebas sshd[2456]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=58.242.83.9  user=root
Feb 12 17:39:41 pruebas sshd[2456]: Failed password for root from 58.242.83.9 port 15826 ssh2
Feb 12 17:39:46 pruebas sshd[2456]: message repeated 2 times: [ Failed password for root from 58.242.83.9 port 15826 ssh2]
Feb 12 17:39:46 pruebas sshd[2456]: Received disconnect from 58.242.83.9: 11:  [preauth]
Feb 12 17:39:46 pruebas sshd[2456]: PAM 2 more authentication failures; logname= uid=0 euid=0 tty=ssh ruser= rhost=58.242.83.9  user=root
Feb 12 17:40:13 pruebas sshd[2458]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=58.242.83.9  user=root
Feb 12 17:40:15 pruebas sshd[2458]: Failed password for root from 58.242.83.9 port 56533 ssh2
Feb 12 17:40:19 pruebas sshd[2458]: message repeated 2 times: [ Failed password for root from 58.242.83.9 port 56533 ssh2]
Feb 12 17:40:20 pruebas sshd[2458]: Received disconnect from 58.242.83.9: 11:  [preauth]
Feb 12 17:40:20 pruebas sshd[2458]: PAM 2 more authentication failures; logname= uid=0 euid=0 tty=ssh ruser= rhost=58.242.83.9  user=root
Feb 12 17:40:46 pruebas sshd[2560]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=58.242.83.9  user=root
Feb 12 17:40:47 pruebas sshd[2562]: Invalid user ubuntu from 159.89.225.14
Feb 12 17:40:47 pruebas sshd[2562]: input_userauth_request: invalid user ubuntu [preauth]
Feb 12 17:40:47 pruebas sshd[2562]: pam_unix(sshd:auth): check pass; user unknown
Feb 12 17:40:47 pruebas sshd[2562]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=159.89.225.14
Feb 12 17:40:48 pruebas sshd[2560]: Failed password for root from 58.242.83.9 port 42475 ssh2
Feb 12 17:40:50 pruebas sshd[2562]: Failed password for invalid user ubuntu from 159.89.225.14 port 47468 ssh2
Feb 12 17:40:50 pruebas sshd[2562]: Received disconnect from 159.89.225.14: 11: Bye Bye [preauth]
Feb 12 17:40:51 pruebas sshd[2560]: Failed password for root from 58.242.83.9 port 42475 ssh2
Feb 12 17:40:53 pruebas sshd[2560]: Failed password for root from 58.242.83.9 port 42475 ssh2
Feb 12 17:40:53 pruebas sshd[2560]: Received disconnect from 58.242.83.9: 11:  [preauth]
Feb 12 17:40:53 pruebas sshd[2560]: PAM 2 more authentication failures; logname= uid=0 euid=0 tty=ssh ruser= rhost=58.242.83.9  user=root
Feb 12 17:41:07 pruebas sshd[2564]: reverse mapping checking getaddrinfo for ney.51st-reg.org [149.202.23.137] failed - POSSIBLE BREAK-IN ATTEMPT!
Feb 12 17:41:07 pruebas sshd[2564]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=149.202.23.137  user=root
Feb 12 17:41:10 pruebas sshd[2564]: Failed password for root from 149.202.23.137 port 58088 ssh2
Feb 12 17:41:10 pruebas sshd[2564]: Received disconnect from 149.202.23.137: 11: Bye Bye [preauth]
Feb 12 17:41:16 pruebas sshd[2644]: Invalid user mongo from 159.89.225.14
Feb 12 17:41:16 pruebas sshd[2644]: input_userauth_request: invalid user mongo [preauth]

As you can see the attacker is trying to get access to our server using the user root. Some services as AWS EC2 creates the user ubuntu by default when a new VPS is initiated. This is a well known fact by the attackers and on this log you can see an attempt to break in using this user too.

The solution

A simple way to ensure our server, is disabling password authentication over ssh. But first we need to configure ssh keys to guarantee a secure access to our server and don’t let ourselves out of access to the VPS.

SSH Keys access configuration

Step One — Create the RSA Key Pair

The first step is to create the key pair on the client machine(probably your personal computer):

$ ssh-keygen -t rsa

Step Two — Store the Keys and Passphrase

Once your enter the command for generate the key, you will get some questions:

Enter file in wich to save the key (/home/user/.ssh/id_rsa):

If you press enter, it will save the key to the default location specified in parenthesis, otherwise you should enter a path to save your key.

Enter passphrase (empty for no passphrase):

It’s up to you wether you want to use a passphrase. The main benefit of using a passphrase is to add an extra layer of security to your key, the downside is that you must enter the passphrase every time you use your key.

The entire process looks like this:

$ ssh-keygen -t rsa

Output
Generating public/private rsa key pair.
Enter file in which to save the key (/home/user/.ssh/id_rsa): 
Enter passphrase (empty for no passphrase): 
Enter same passphrase again: 
Your identification has been saved in /home/user/.ssh/id_rsa.
Your public key has been saved in /home/user/.ssh/id_rsa.pub.
The key fingerprint is:
4a:dd:0a:c6:35:4e:3f:ed:27:38:8c:74:44:4d:93:67 user@a
The key's randomart image is:
+--[ RSA 2048]----+
|          .oo.   |
|         .  o.E  |
|        + .  o   |
|     . = = .     |
|      = S = .    |
|     o + = +     |
|      . o + o .  |
|           . o   |
|                 |
+-----------------+

The public key is now located in /home/user/.ssh/id_rsa.pub. The private key (identification) is now located in /home/user/.ssh/id_rsa.

Step Three — Copy the Public Key to the server

Now that we have the key pair generated, it’s time to copy the public key to the server we want to get access to. You can use ssh-copy-id utility like this:

$ ssh-copy-id user@198.10.150.15
Note: If your are a Mac user, you must install this utility on your computer first with:
$ brew install ssh-copy-id

Alternatively, you can paste in the keys using SSH:

$ cat ~/.ssh/id_rsa.pub | ssh user@198.10.150.15 "mkdir -p ~/.ssh \ && chmod 700 ~/.ssh && cat >>  ~/.ssh/authorized_keys"

No matter which command you use, you should see something like:

The authenticity of host '198.10.150.15 (198.10.150.15)' can't be established.
RSA key fingerprint is b1:2d:33:67:ce:35:4d:5f:f3:a8:cd:c0:c4:48:86:12.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '198.10.150.15' (RSA) to the list of known hosts.
user@198.10.150.15's password:

This message helps us to make sure that we haven’t added extra keys that you weren’t expecting.

It is recommended that you try to get access to the server with the recently added ssh key before disabling the password authentication:

ssh user@198.10.150.15

If you set a passphrase when creating your SSH key, you will be asked to enter the passphrase at this point (and whenever else you log in in the future).

Disabling password authentication

To disable this feature on our servers we must follow these steps:

Edit the file /etc/ssh/sshd_config
This is the main configuration file for the ssh service. We should then modify the file with these configurations:

PasswordAuthentication no 
ChallengeResponseAuthentication no
UsePAM no

PasswordAuthentication: allows or deny the use of the authentication schema defined in RFC-4252 section 8.

ChallengeResponseAuthentication: allows or deny the use of the authentication schema called keyboard interactive, which let the server to ask the user interactive questions to verify it’s identity (passwords) as defined on RFC-4256.

UsePAM: ssh service permit the use of Pluggable Authentication Module. Some Server’s Admins will argue that setting this configuration to no is not a good practice due to the fact that we are not only disabling password authentication but also any other form of authentication that uses PAM but in most cases this is not relevant enough. On a future post I will explain how to configure it to disable only password authentication for PAM.

Reload ssh service

service ssh reload

This command is for Ubuntu servers, use the appropriated one for your distro.

And that is all. Finally check your connection on another terminal to verify that you still have access to your server using SSH Keys. For any question please contact me.

Eng. Gustavo Gonzalez
Mail: gustavo@alturasoluciones.com
Twitter: @Aguardientico
LinkedIn: www.linkedin.com/in/gustavoagonzalez
Blog in spanish: http://aguardientech.blogspot.com