Skip to end of metadata
Go to start of metadata

It is very common for Linux servers to get hacked via SSH Bruteforce. This is mainly because of laziness or lack of knowledge. Securing your virtual machine is very very easy and should not take you more than 10 minutes. Here is a guide on how to make your linux VPS Safer!


Always keep your system up to date. Run updates periodically.

If you do not add a user with sudo privileges prior to disabling root, this will make your machine unusable and it will only work in rescue mode / after a fresh reinstall.

Do not use ROOT as default user.

Many hackers know that the default login user for Linux is root. So the brute force attacks concentrate on attacking and getting the password for root via SSH. There is a very simple solution for this, add an user and disable root login.

Adding a user in Linux
  1. Login as Root or with sudo privileges to your virtual machine
  2. Add a user with the following command where username is the user you want to add. Note that it matters if the user has capital letters or lowercase letters for login.

    sudo adduser username
  3.  Set a password for that username.

    sudo passwd username


Give sudo privileges to a user.
  1. Go to the file where permissions are stored.

    nano /etc/sudoers
  2. At the end of the file add the following code, where username is the user you wish to add privileges to.


    username ALL=(ALL) ALL
  3. Test the account by login it to it with the following command.

    	su - username
  4. Check sudo privileges. 

    sudo -v
    sudo ls

    Normally, you will not see any response. If you get "Sorry, user [username] is not allowed to execute '/bin/ls' as root on [hostname]." it means that the user was not created or given sudo privileges properly.


Remove ROOT access to the server
  1. Go to the file where users are stored.

    sudo nano /etc/passwd
  2. Edit the root user that looks like this: 

    root:x:0:0:root:/root:/bin/bash

    to

    root:x:0:0:root:/root:/sbin/nologin
  3. Test by login in with the root user, you should not be able to login anymore if done properly.


Change SSH port

You need to make sure the port you wish to change to is currently open on the firewall.

Changing SSH port
  1. Let's modify the SSH configuration file

    nano /etc/ssh/sshd_config
  2. Edit the default port, you will see this lines on the file 

    #Port 22
    #AddressFamily any
    #ListenAddress 0.0.0.0
  3. Remove the commenting and put the port of your choice. In this case I added the port 1090 just as a random port. Make sure this port does not interfere with any other services you are currently running.

    Port 1029
    #AddressFamily any
    #ListenAddress 0.0.0.0


Making sure firewall ports are open.
  1. Add the ports to the firewall, in this case I am adding port 1029

    firewall-cmd --add-port=1029/tcp --permanent
    firewall-cmd --reload

    Another way of opening ports is via iptables where 1029 is the port I wish to open.

    sudo iptables -A INPUT -p tcp --dport 1029 -j ACCEPT


Now that everything is done, test that the port is open by a ping. You can use telnet for example to check for that.

telnet <ip> <port>


And it Is now safe to restart the SSH service

sudo systemctl restart ssh.service


Afterwards just login with the following command

ssh -p <port> <user>@<ip>

Use SSH Keys for Login  

I personally dislike to use SSH keys as my needs are different. I need to be able to connect to my servers regardless of where I am, so keeping an SSH key or using an IP-Filtered firewall for login in is not for me. But this might be for you, if you want to give up flexibility for security. Which is one of the mayor trade offs in this case.

Typically when you log into your server, you authenticate with a password. Unfortunately, passwords have several drawbacks:

(1) Many people choose weak passwords. There are plenty of hackers who will systematically try hundreds or thousands of passwords and if you've chosen a password such as "password", "123456", or "monkey", your account will be swiftly compromised.

(2) People tend to reuse passwords, which means that if your account is hacked in one place it may quickly be hacked in many places.

(3) Passwords are only a "single factor". They are "something you know" and best practice for security are to use additional factors, such as "something you have". That way if someone learns your password (by hacking, carelessness on your part, shoulder surfing, etc.) it will not be useful to them because they will only have one factor and not both factors.

SSH keys neatly solve all of these problems and greatly improves security. In order for someone to compromise your server, they would have to have your specific key file and the passphrase to unlock it. SSH keys are slightly more work to use, but if required and used routinely, they can greatly enhance the security of your server. Let's look at creating, requiring, and using them.


Creating SSH Keys
  1. With SSH keys, you create a keypair - a public key and a private key. The public key can truly be public. You could post it on the Internet and the security is not compromised in any way. The private key, however, must be kept private and not shared with anyone. To create a SSH keypair, log into your server and type: 

    ssh-keygen
  2. When prompted, enter a complex passphrase:

    $ ssh-keygen
    Generating public/private rsa key pair.
    Enter file in which to save the key (/home/raindog308/.ssh/id_rsa): 
    Enter passphrase (empty for no passphrase): 
    Enter same passphrase again: 
    Your identification has been saved in /home/raindog308/.ssh/id_rsa.
    Your public key has been saved in /home/raindog308/.ssh/id_rsa.pub.
    The key fingerprint is:
    SHA256:uyElJIXomjx3a2DdwRXzXq/IrFmj2f63uU7+3ZE7v+Y raindog308@myserver.example.com
    The key's randomart image is:
    +---[RSA 3072]----+
    |   . ..  o.      |
    |  . ..   .o      |
    | .  . o .  . .   |
    |  .  o o  . . .  |
    |.o  . o S  .   . |
    |oo + o + .o . . .|
    |  + o o o  * . + |
    |     o . oB . o+.|
    |    .   .=.o..=E%|
    +----[SHA256]-----+
    $ 
  3. Your public key is now in your home directory's .ssh directory and is called `id_rsa.pub`. Your private key is `id_rsa`. Copy both of these files to your home PC. Personally, I remove the private key file (`id_rsa`) from my server because it's not needed there.
Preparing to use SSH Keys

Your public key is now in your home directory's .ssh directory and is called `id_rsa.pub`. Your private key is `id_rsa`. Copy both of these files to your home PC. Personally, I remove the private key file (`id_rsa`) from my server because it's not needed there.


chown $USER:$USER $HOME/.ssh.authorized_keys
chmod 600 $USER:$USER $HOME/.ssh/authorized_keys
chown $USER:$USER $HOME/.ssh
chmod 700 $USER:$USER $HOME/.ssh

Using SSH Keys

To login using your SSH key, use the following command. If you're using Linux or macOS, this will work as-is. If you're using Windows, consult the documentation for GUI SSH software client you're using (such as PuTTY) about how to import the key.

ssh -i <your private key file> user@myserver.example.com


For Example:

$ ssh -i ~/.ssh/id_rsa raindog308@myserver.example.com

Enter passphrase for key '/home/raindog308/.ssh/id_rsa': 
$ 

Note: It's a common mistake to accidentally reference the public key file in your ssh command. Be sure to reference your *private* key file.

Forcing SSH Keys to be used for login:

Once you've made sure that your SSH key authentication works, you can setup your system to require SSH keys.

Edit the `/etc/ssh/sshd_config` file and change the following lines:

PubkeyAuthentication yes
PasswordAuthentication no

Then restart sshd:

systemctl restart sshd (CentOS)
systemctl restart ssh (Debian)


Now if you try to login without using a key, you'll get this error:


$ ssh raindog308@myserver.example.com
 Permission denied (publickey,gssapi-keyex,gssapi-with-mic). 


Write a comment…