Enabling Public Key SSH Authentication on Your VPS
Enabling Public Key SSH Authentication on Your VPS
As the last few months have shown, cybersecurity is more important than ever. Learn how to protect your server using these SSH best practices.
Join the DZone community and get the full member experience.Join For Free
What Is Public Key Authentication?
As general computer users, we all know what password authentication is. It is where we just require a password (usually 8-20 characters long) to login to a computer. But, with the computational power of computers exponentially increasing and with the number of attacks on servers vastly increasing, can a password of length 8-20 characters prevent your server from being breached through an SSH login?
SSH (Secure Shell) is the method we use to login to remote servers and do whatever task we want through the server's terminal. If you keep using password authentication and the common users and usernames for login (like 'root') there is a possibility that your server can be breached if the password is not lengthy enough and strong enough. For example, if you have a VPS, and are using any common user name, like root, to log in, check your logs located at /var/log/secure. Most likely, you will see something like this in it. It doesn't mean that you have been hacked, but it means that there have been attempts to breach the system. Therefore, it is better to take measures to make your system more secure.
Apr 10 06:39:27 echo sshd: reverse mapping checking getaddrinfo for 222-237-78-139.tongkni.co.kr failed - POSSIBLE BREAK-IN ATTEMPT! Apr 10 13:39:27 echo sshd: Received disconnect from 188.8.131.52: 11: Bye Bye Apr 10 06:39:31 echo sshd: Invalid user edu1 from 184.108.40.206 Apr 10 06:39:31 echo sshd: reverse mapping checking getaddrinfo for 222-237-78-139.tongkni.co.kr failed - POSSIBLE BREAK-IN ATTEMPT! Apr 10 13:39:31 echo sshd: input_userauth_request: invalid user edu1 Apr 10 13:39:31 echo sshd: Received disconnect from 220.127.116.11: 11: Bye Bye Apr 10 06:39:35 echo sshd: Invalid user test1 from 18.104.22.168 Apr 10 06:39:35 echo sshd: reverse mapping checking getaddrinfo for 222-237-78-139.tongkni.co.kr failed - POSSIBLE BREAK-IN ATTEMPT! Apr 10 13:39:35 echo sshd: input_userauth_request: invalid user test1 Apr 10 13:39:35 echo sshd: Received disconnect from 22.214.171.124: 11: Bye Bye Apr 10 06:39:39 echo sshd: Invalid user test from 126.96.36.199 Apr 10 06:39:39 echo sshd: reverse mapping checking getaddrinfo for 222-237-78-139.tongkni.co.kr failed - POSSIBLE BREAK-IN ATTEMPT! Apr 10 13:39:39 echo sshd: input_userauth_request: invalid user test Apr 10 13:39:39 echo sshd: Received disconnect from 188.8.131.52: 11: Bye Bye
A description can be found on this Ubuntu Community Post:
With public key authentication, the authenticating entity has a public key and a private key. Each key is a large number (1024,2048 or 4096 bits long) with special mathematical properties. The private key is kept on the computer you log in from, while the public key is stored on the .ssh/authorized_keys file on all the computers you want to log in to. When you log in to a computer, the SSH server uses the public key to "lock" messages in a way that can only be "unlocked" by your private key - this means that even the most resourceful attacker can't snoop on, or interfere with, your session (because predicting the private key is impossible under currently available computational power due to its length). As an extra security measure, most SSH programs store the private key in a pass-phrase-protected format, so that if your computer is stolen or broken in to, you should have enough time to disable your old public key before they break the pass-phrase and start using your key.
Simply put, you generate a key pair (a private key and a public key) where any encrypted text is using the private key and it can only be decrypted by the corresponding public key and vice versa. In order to make your SSH login more secure, using public key authentication is recommended over password authentication.
How to Enable Public Key Authentication
Step 1: Generating Key Pair
As mentioned above, SSH keys come in pairs (a private key and a public key). Usually, the keys are stored in the ~/.ssh directory. You should make sure that directory exists and its permissions are 700 (to prevent other users from accessing your keys).
If the directory is not there, create it.
mkdir ~/.ssh chmod 700 ~/.ssh
Then, you have to generate the key pair.
ssh-keygen -t rsa -b 4096
Here, -t rsa means that we are creating an RSA key pair. -b 4096 means that we are creating a key pair of length 4096 bits. Other common key lengths are 1024 and 2048. But, for increased security, using a 4096-bit length key pair is better. You will be asked several questions like:
When asked for the location to which the key pair is to be saved, press enter to keep the default ~/.ssh/id_rsa. Otherwise, specify the file. Then give a password to make sure the locally stored private key cannot be easily stolen and used.
Now you will see 2 files in your ~/.ssh directory, id_rsa which contains the private key and the id_rsa.pub which includes the public key (note that if you specify a path other than the default file path to store the key pair, you will find these files in that directory). Now our first step is complete.
Step 2: Uploading the Public Key to the Remote Server
Then login to the remote server using SSH. You have to use password authentication as usual for this step in order to log in. Then, create the ~/.ssh directory if it is not there.
cd ~ mkdir .ssh
Then, you can use secure copy (SCP) to copy the public key to the remote server as follows. Remember, this command should be run from your local computer, not from the terminal in which we logged into the remote server.
scp ~/.ssh/id_rsa.pub firstname.lastname@example.org:~/.ssh/uploaded_key.pub
The scp command takes two arguments here. First is the location of the public key file on your local computer. The second argument includes the remote user name, remote server's IP address, and the location to which the public key should be uploaded.
scp <local location of the public key> <remote user>@<remote server address>:<destination file>
Then, we have to move the uploaded public key to the authorized_keys file in the .ssh directory. To move that, switch to the terminal with which we logged into the remote server using SSH. Then go to the ~/.ssh directory. You will see the uploaded_key.pub has been copied to this location. Then, use the following command to put the public key into the authorized_keys file.
cat uploaded_key.pub >> authorized_keys
One more thing! You have to check the /etc/ssh/sshd_config file for the following lines.
RSAAuthentication yes PubkeyAuthentication yes AuthorizedKeysFile .ssh/authorized_keys
If those lines are commented with #, remove those. Then save the file. Now you have to restart the ssh service.
sudo service ssh restart sudo service sshd restart (on CentOS)
Now we are good to go!
You can now log in to the remote server with SSH using public key authentication by using the following command:
ssh -i <path to your private key> <user>@<remote server address> Ex : ssh -i ~/.ssh/id_rsa email@example.com
Now, you are logging in using public key authentication. This doesn't mean your server is secured because you are still using password authentication.
Step 3: Disable Password Authentication
Go to /etc/ssh/sshd_config file and do the following change.
Just set the password authentication to no. Then restart the SSH service again. Now you cannot login using the password. Just using the public key authentication.
Now your VPS is more secure!
You can change the port from which the SSH server is listening to incoming SSH connections by changing the following line to your preferred port.
Usually, it is 22. That is why you usually get this much attack attempts since you are using the default port. You can change this and prevent attacks coming from default ports. Still, an attacker can determine your port by port scanning, but this will drastically reduce the automated bot attacks coming to your VPS.
Then you can disable the root login by also changing the following line to no in the same file.
This will allow no one to log in as root. Therefore, you can log in as a general user and switch to the super user mode later in order to be the root. This will be an advantage since the attackers have to now guess your user name apart from the difficulty of finding your private key.
Thank you for reading!
Published at DZone with permission of Imesha Sudasingha . See the original article here.
Opinions expressed by DZone contributors are their own.