Once you decide to switch to VPS for your hosting you’ll probably get a machine with root access and a password. That’s not very secure, because if you use the root user to access a server, any attacker already knows half of your defense system – the user root. So in this tutorial we will disable the root password and allow access via SSH and a key pair.
For this tutorial I’m using a DigitalOcean cloud server, because it takes only 5 minutes to set up and then I can shut it down anytime and not spend money anymore on the server. So, first things first, we are going to connect to the DigitalOcean server using Putty, the root and the root password they provided after I created the droplet.
Let’s see what steps we have to follow in order to secure a Centos 7 server
- create a new user that has the same rights as the root user
- create the public and private keys that are going to be used instead of the regular password
- disable the root user and password authentication
Creating a new user in Centos and giving it sudo access
First, you have to login using Putty to the new server. To do this, open Putty and fill in the Host Name field with the IP of your server. Click Open. Putty will then connect to the IP and asks login as: root. To fill in the password you can select it from the email you got from your hosting provider, then right click in the Putty window (you will not see anything changing) and hit Enter. If you copied the password right, you should be logged in as root.
Let’s create a new user. I’ll create the demouser user as an example (you should create an user that is familiar to you and don’t copy the # sign):
# adduser demouser
Let’s give it a password (don’t forget the password as it’s going to be needed each time you need to do stuff on the server);
# passwd demouser
and insert the password twice.
Besides creating a server user and setting a password, the steps above also create a folder “demouser” inside the /home folder on your server. Keep this in mind, as you will find stuff belonging to you user (like the pair keys we are going to create later) there.
Now, if we later prevent access to the server using the user root, we have to make sure the new user demouser has all the rights the root user has. To give to an user specific rights, you have to add it to a group that has these specific rights. In our case, for a Centos server, we have to add the user demouser to the group wheel. Yeah, that’s right, in Centos, to have sudo rights you have to belong to the group wheel. Let’s do this:
# usermod -aG wheel demouser
As things can go wrong (and they will go wrong if they can), we have to test that the demouser user has the sudo rights. To do this, we have to switch from the root user to the demouser user and test the sudo command. In Linux you can change the user using the su command.
# su – demouser
You will see now that the lines in the console start with something that looks like your user. In my case:
Let’s test the sudo with an easy command – top – it should show the load on your server.
$ sudo top
It’s going to ask the password for the demouser user. If everything goes well Top should display a bunch of processes and how much RAM and CPU they are using.
Press Q to exit Top.
Create the public and private keys to authenticate on the Centos 7 server
Keys, how to create them and how to use them can be a challenge to understand. But let’s keep thing simple: you need a Public key that is placed on the server and a private key that you keep on your computer. When you need to authenticate the sever, you should use Putty with the private key. The server will make all the rest, will check if there is a match between the public key he has stored and the private key you are using in Putty. Let’s generate the keys.
From the steps above you are using the newly created user that has Sudo rights. It’s exactly right – you should be using the user that it’s going to access the server with the keys and make the following steps:
$ ssh-keygen (don’t copy the $ sign)
The server will reply something like this:
Generating public/private rsa key pair.
Enter file in which to save the key (/home/demouser/.ssh/id_rsa):
So, let’s give the file a name, let’s say: accert. It’s going to ask for a password (and I strongly recommend you use one that it hard to guess). If everything goes well, it will say: Your public key has been saved in accert.pub.
Now, we have the public and private keys, but the server doesn’t know that the public key it’s a key we want to use it to access the server via SSH. So we have to “copy the Public Key Using SSH-Copy-ID”:
$ ssh-copy-id -i accert.pub xx.xxx.xxx.xxx (where you replace xx with your server IP)
The server will say something like “The authenticity of host … can’t be established. ECDSA key fingerprint is…” – which you have to agree and get in return something like:
/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed
/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed — if you are prompted now it is to install the new keys
Good. Now we have to copy the private key to our local computer. As the public key was called accert.pub, the private key is named accert. And guess what, it’s located in the user’s folder inside Home. So. Use something like Winscp, connect to the server using the IP, the root username and the password you got from the hosting company and copy the file accert to your computer from:
Delete the private key from /home/demouser/. Still some work to do….To be able to user the accert private key in Putty we will have to modify it in a .ppk file using the Puttygen software (it’s free, just like Putty). Open Puttygen and click on the Load button and browse to the location where you saved the accert file (select “All files” if the accert file it’s not appearing where it should).
Write the good secure password that you saved when creating the keys. Looks good, the following message should appear:
Save the new key (.ppk format) by clicking on Save Private Key button:
Now, we are ready to try to connect with the new user demouser and they new private key. Let’s create a new connection in Putty. Close Putty and open it again. At host name put the IP of the sever. At saved sessions put something to remember, let’s say demouser. On the left side, you have Connection and a + called SSH that you can open and select Auth:
On the left side, scroll back up to Session, then, save the session on the right side. Click Open – it should connect to your server. Login as: demouser. Passphrase for key “imported-openssh-key”: – the good password you set when creating the keys. If you can login, you’re done with this step.
Disable the root user and password authentication
If you are absolutely sure that you can login with the new user using keys and the new user has sudo powers, it’s time to close down password authentication and root login. It’s done from the same place. You have to edit the SSH config file and restart SSH. Easy.
$ sudo nano /etc/ssh/sshd_config
Press CTRL + W and write (CTRL + W means search in nano):
Delete the # sign at the beginning of the line, and set the PasswordAuthentication to no. CTRL+O to save, CTRL+X to exit.
Let’s restart the SSH service. In Centos, this is done with:
$ service sshd restart
Close Putty, and try to login using the root user like you did at the very beginning: open Putty and fill in the Host Name field with the IP of your server. Click Open. Putty will then connect to the IP and asks login as: root. Shouldn’t work.
Let’s disable the root login for good. Set PermitRootLogin no. Restart the sshd service again and give it a try with the root user.