This article shows how to perform a secure Linux server setup by creating a VPS, adding a sudo user, enabling public key access, activating the firewall, and disabling root access.

Linux server

Here we consider a few different VPS (Virtual Private Server) providers. Then, we choose a provider and see a typical example of how to create a new Linux server.

VPS providers

There is a large number of cloud service providers where to buy VPS. When buying a cloud server, we typically choose between providers offering IaaS only or IaaS + PaaS solutions. The latter tend to have higher prices and more complex setups. For instance, if your provider offers seamless integration to scaling services, you pay an extra price for the option.

If we think critically, we should select a provider depending on the expected server usage. For instance:

  • If we need a server for a small project or we want to manage the infrastructure directly, we choose a bare-bone IaaS provider. (i.e. DigitalOcean, Linode, OVH, etc..)
  • When we have a large project or we need to orchestrate AND scale cloud services, we choose a provider offering IaaS + PaaS solution. (i.e. AWS, Azure, Google Cloud, Etc..)

In this article we demonstrate a simple Linux server setup, hence we opt for a simple (and cheaper) IaaS solution.

Linux VPS setup

For this linux server setup, I use DigitalOcean because is fast, cheap, and has good support for developers. For example, we can create a linux cloud server (called droplet) in just a few clicks. Indeed, as you can see below, we just need to select the OS, choose the server size/speed, and add the ssh public keys for root access.

steps for VPS setup on digital ocean

No matter which VPS provider you use, if you choose an IaaS provider, instantiating a new VPS should be similar to the example above. Differently, when you choose a PaaS solution, you typically have a more complex service configuration.

For this example, I instantiated a VPS with Ubuntu 18.04, a few GB of RAM, and I added the ssh keys of my workstation directly during the server creation.

First ssh connection as root

When the server is up and running, you can connect via ssh as root user.

ssh root@123.45.67.890

For security reasons, operating as root is dangerous. Indeed, it is common practice to use the super user only for the initial setup and rarely using it again. For further operations that need root privileges, it is common to create a sudo user.

Firewall setup

The first step to secure the linux server is to setup a firewall. Assuming we still operate as root on the server, we set up ufw (Uncomplicated FireWall) on the system.

At first, we check OpenSSH has a profile to allow ssh connection over the firewall using the ufw app list command. If the OpenSSH profile exists, we can enable SSH and activate the firewall with the below commands.

ufw allow OpenSSH
ufw enable

When done, check the status with ufw status. If the system is correctly configured, you should see an output similar to the one in the image below.

VPS setup: Output of ufw status when installing the firewall

Add a sudo user

As anticipated, operating as root is unsafe, and it is common practice using a user with sudo privileges. Therefore, we create a new sudo user with the commands in the snippet below.

# as root, on remote server
USR=myuser
adduser $USR --gecos "My User,,,"
usermod -aG sudo $USR

Set up public key authentication via ssh

To secure access to the linux server, we setup public key authentication. For this purpose, we see two different options to enable PK authentication via ssh. The first is copying the ssh keys from the root user to the new sudo user. The second is creating a new key pair for the user.

Option 1. Copy root ssh keys

This method is used when you already copied the ssh keys to the root user, and you need to have the same public keys for the sudo user. In this case, you can just copy the ssh key in the remote server, from the root user to the sudo user using the rsync command.

# as root, on the remote server
rsync --archive --chown=$USR:$USR ~/.ssh /home/$USR

Note: If you have security concerns, you should avoid copying the root keys, but prefer generating a new keypair as you can see in the next section.

Option 2. generate a new keypair

When you need a new key pair for the sudo user, you first need to generate the new key pair on the local workstation, and then you can copy the generated public key to the remote server.

To generate the keypair on the local workstation, you should use the ssh-keygen utility from terminal (bash or git-bash). In the snippet below, you see the command to generate a 4096 bit rsa key with comment.

# from local workstation
ssh-keygen -t rsa -b 4096 -C "new key for VPS"

By default, the command generates two keys: id_rsa and id_rsa.pub. The first is the private key, and the second is the public key that we want to upload to the server.

In the snippet below, you see how to copy a public key from the local workstation to the remote server using the ssh-copy-id command.

#copy PK from local to remote as remote-root
ssh-copy-id -i ~/.ssh/id_rsa.pub root@123.45.67.890

Test ssh access

After copying or adding the ssh keys to the server, we connect to the remote server and restart the ssh service. In the snippet below, you see how this is done on Ubuntu Linux.

# as root on the remote server
systemctl restart ssh

To test you have ssh access with the new sudo user, you should log out as root, and perform a connection test with the newly created sudo-enabled user.

ssh myuser@123.45.67.890
sudo whoami

After verifying the new user can access via ssh and perform sudo commands, we can safely disable the root access to the server. To do so, edit the sshd_config, disallow root login by setting PermitRootLogin to no, and check that PassowrdAuthentication is set to no

#as sudo user on the remote server
sudo nano /etc/ssh/sshd_config
#set PermitRootLogin and PassowrdAuthentication to no, then save
systemctl reload sshd

Conclusion

This article shows how to perform an initial linux server setup, by enabling firewall, adding a sudo user, and enabling PK access via ssh.

References


0 Comments

Leave a Reply

Avatar placeholder

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