This guide is inteded as a short checklist of some fundementals to employ to secure an ubuntu server exposed to the internet. Whilst nothing can ever be truly secure, this should help make a default server (Digital Ocean etc) a little more secure.


  • Create a user
  • Create private and public keys and configure SSH
  • Configure firewall
  • Keep your server updated


Assuming you have an Ubuntu Server with IP address and root password.

Open a terminal and access into your server with SSH using root account;

ssh root@ip.address

Create a user

Logged in as root you can create a new user, let’s call it apps:

adduser apps

Now type two times a new password for the user, make it complex and hard to guess. When asked about Full name, phone etc just type Enter, you don’t need to fill all the fields.
You need to add the user to the sudo group:

usermod -aG sudo apps

The new user is now a privileged user. You can now end the session as root:


and login as apps user using the password you typed creating it:

ssh apps@ip.address

Create private and public keys and configure SSH

If you do not already have an SSH key, you can create one now. You create SSH keys (a private and a public one) on your computer and then upload the public key on the server.
Open a terminal on your computer and move into the SSH folder (it’s the same for Linux and MacOs):

cd .ssh

Create the keys with the command:

ssh-keygen -t rsa -b 4096

You will get an output similar to this:

Generating public/private rsa key pair.
Enter file in which to save the key (/home/myuser/.ssh/id_rsa):

Set a passphrase for extra security, and you can copy the public key on the VPS into the authorized_keys file, use this one-liner command to do it

cat | ssh apps@ip.address “mkdir -p ~/.ssh && cat >> ~/.ssh/authorized_keys”

Remember to backup the SSH key securely.

We can now configure SSH on the server to start using the keys as login method. Login one last time with the password:

ssh apps@ip.address

and edit the SSH config file:

sudo nano /etc/ssh/sshd_config

Remove the comment (the # character) from the following lines:

AuthorizedKeysFile %h/.ssh/authorized_keys

and change yes to no on the line:

PasswordAuthentication no

Additionally we can change the default SSH port to prevent automatic port scans and malicious automated bots. Change the number 22 in the line Port to a number preferably less than 1024:

Port 1015

Remember to allow the custom SSH port on the firewall otherwise you will be locked out of your server!
Save (CTRL+O and Enter) and close the file (CTRL+X). Restart the SSH service and exit the session.

sudo service ssh restart

We can now test if login using SSH works fine and if positive we can disable root login. From now on you will use this command to login into your server.

If you are on Linux:

ssh -i /home/myuser/.ssh/apps -p 1015 apps@ip.address

Enter the passphrase and you should log in, once logged we can disable root login and root account. Let’s edit again SSH config file:

sudo nano /etc/ssh/sshd_config
and change to no the following lines:
PermitRootLogin no
X11Forwarding no

Save and close the file, restart SSH service:

sudo service ssh restart

You can no longer login as root.
To disable root account on the server type the command:

sudo passwd -dl root

Configure Firewall

Last step is to install a firewall and keep open only the ports that server needs to be operative. Let’s install UFW, a front-end for iptables:

sudo apt-get update
sudo apt-get install ufw

The full node needs open 3ports, the custom SSH port for our login, the 6868 for P2P and the http (80) port for system updates. We instruct the firewall with this two commands:

sudo ufw allow 1015
sudo ufw allow https (If you are hosting websites) 

To enable the firewall use:

sudo ufw enable

That’s what you need to setup the firewall.
There’s one more package to install to protect SSH and HTTP ports from excessive number of requests such as brute force attacks. Install fail2ban with:

sudo apt-get install fail2ban

We need to edit the fail2ban config file since we changed the default SSH port. Open the file:

sudo nano /etc/fail2ban/jail.local

and edit the lines relative to SSH:

port = ssh

to your custom SSH port, in our example to 1015:

port = 1015

Save and close the file, don’t forget to restart fail2ban:

sudo service fail2ban restart
Keep your server updated

A server with up to date software is more resistant against known bugs and common hacking techniques. You can manually update your server with:

sudo apt-get update
sudo apt-get upgrade

It’s better to handle security updated automatically and the package unattended-upgrades does that for you. Install it with:

sudo apt-get install unattended-upgrades

and configure it with the command:

sudo dpkg-reconfigure unattended-upgrades

Select Yes and Ok on the next two questions to finish configuration.

Auto Sudo (Risk)

You probably know that in Ubuntu/Debian, you should not run as the root user, but should use the sudo command instead to run commands that require root privileges. However, it can also be inconvenient to have to enter your password every time that you use sudo. Here’s a quick fix that removes the requirement to enter you password for sudo.

Open the /etc/sudoers file (as root, of course!) by running:

sudo visudo

You should never edit /etc/sudoers with a regular text editor, such as Vim or nano, because they do not validate the syntax like the visudo editor.

At the end of the /etc/sudoers file add this line:

username     ALL=(ALL) NOPASSWD:ALL

It is important to add this line at the end of the file, so that the other permissions do not override this directive, since they are processed in order.

Finally, open a new terminal window and run a command that requires root privileges, such as sudo apt-get update. You should not be prompted for your password!


A server connected to the Internet might get targeted by hackers, bots and automated scripts as soon as is available online, with this tutorial you can effectively reduce the risk of passwords brute force and attacks to open ports.
You need to keep your password and passphrase secret and never share online your SSH private key. Use a set of SSH keys only for one node and create a new set with a different passphrase for every new node.z