Securing SSH/VPS/Linux Server - 27 Tips with Example

☰ In this chapter, you will learn

When setting up your VPS Server, it's crucial to strengthen the security of your SSH server to prevent unauthorized access. This is a top priority that requires careful attention.

In this guide, we'll outline 27 configurations to secure your server like professionals do.

How to edit sshd_config file

Most of the configuration takes place in the /etc/ssh/sshd_config file. Here are the steps to open and edit this file.

Open sshd_config file in your favourite text editor like vi, vim, nano etc.

nano text editor

sudo nano /etc/ssh/sshd_config
  GNU nano 6.2     /etc/ssh/sshd_config

# This is the sshd server system-wide configuration
# sshd_config(5) for more information.

# This sshd was compiled with PATH=/usr/local/sbin:/

# The strategy used for options in the default sshd_config
# OpenSSH is to specify options with their default 
# possible, but leave them commented.  Uncommented o># default value.

Include /etc/ssh/sshd_config.d/*.conf

Protocol 2

^G Get Help  
^O Write Out 
^W Where Is  
^K Cut Text

^X Exit      
^R Read File 
^\ Replace   
^U Paste Text    

vi text editor

sudo vi /etc/ssh/sshd_config

# This is the sshd server system-wide configuration file.  See
# sshd_config(5) for more information.

# This sshd was compiled with PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games

# The strategy used for options in the default sshd_config shipped with
# OpenSSH is to specify options with their default value where
# possible, but leave them commented.  Uncommented options override the
# default value.

Test the SSH server for errors before restarting.

You should test the sshd_config file for errors before restarting it. If any issues arise and you proceed to restart the SSH server, there's a risk of being disconnected from your server or even causing it to crash.

Therefore, it's crucial to consistently test your SSH configuration prior to restarting the server.

Execute the following command. If no output appears, it indicates everything is in order, and you can proceed with the restart.

sudo sshd -t

Restart the SSH server

Ubuntu/Debian:

Executes only one commands

sudo service ssh restart
$sudo systemctl restart ssh
$sudo /etc/init.d/ssh restart
$sudo systemctl restart ssh.service

CentOS/RHEL

sudo service sshd restart

1 First, make a backup of Configuration file.

It's crucial to create a backup of the configuration file. If something goes wrong with your server, having a backup allows you to return it to its original state.

sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config_backup

sudo ls -l /etc/ssh/
total 548
-rw-r--r-- 1 root root 505426 Jan  2 22:24 moduli
-rw-r--r-- 1 root root   1650 Jan  2 22:24 ssh_config
drwxr-xr-x 2 root root   4096 Feb 26  2020 ssh_config.d
-rw-r--r-- 1 root root   3647 Mar  8 15:58 sshd_config
drwxr-xr-x 2 root root   4096 Feb 26  2020 sshd_config.d
-rw-r--r-- 1 root root   3307 Feb 22 16:48 sshd_config.ucf-old
-rw-r--r-- 1 root root   3647 Mar  8 15:58 sshd_config_backup

2 Create sudo user and disable root login.

The root account can modify any files on your Linux server and has full control over your operating system (OS). To enhance the security of your SSH server, it's important to create a sudo user and then restrict root access to your server.

Create a New User Account and Disable Root Account on Linux VPS

3 Change Default SSH Port (22).

The default SSH port is 22 and leaving it unchanged might make your server vulnerable as attackers often target this port. To enhance security, you should change the SSH port in the /etc/ssh/sshd_config file.

How do I change SSH port on Ubuntu/Centos/Linux

4 Disallow Empty Password Login

The PermitEmptyPasswords setting in the /etc/ssh/sshd_config file ensures that users need to create strong passwords and can't log in without a password when it's turned on. If you disable this setting, users without passwords can access your server, which is a security risk.

sudo nano /etc/ssh/sshd_config
# To disable tunneled clear text passwords, change to no here!
# PasswordAuthentication no
PermitEmptyPasswords no

# Change to yes to enable challenge-response passwords (beware issues with
# some PAM modules and threads)

5Set Limit on Failed Login Attempts

To enhance security and protect against brute-force attacks, you should enable the MaxAuthTries settings in the /etc/ssh/sshd_config file. This setting limits the number of login attempts, and if the allowed number of failed attempts is exceeded, it terminates the SSH connection.

sudo nano /etc/ssh/sshd_config
# Authentication:

#LoginGraceTime 2m
#PermitRootLogin prohibit-password
#StrictModes yes
MaxAuthTries 3
#MaxSessions 10

6 Enable SSH Version 2

SSH version 1 has been found to be vulnerable, so a second version has been released. To switch to the more secure SSH version 2, you simply need to add the Protocol 2 string in the sshd_config file. Once added, your SSH server will be configured to use SSH version 2.

sudo nano /etc/ssh/sshd_config
# The strategy used for options in the default sshd_config shipped with
# OpenSSH is to specify options with their default value where
# possible, but leave them commented.  Uncommented options override the
# default value.

Include /etc/ssh/sshd_config.d/*.conf

Protocol 2
Port 22
#AddressFamily any
#ListenAddress 0.0.0.0
#ListenAddress ::

7 Disable HostbasedAuthentication

HostbasedAuthentication is a setting in the sshd_config file that relies on the host machine to authenticate the user. It verifies if the connection is coming from the host machine, and if so, it permits access to the server.

If an attacker gains access to your PC, they could potentially access the server as well. You can disable this feature by following these steps:

sudo nano /etc/ssh/sshd_config
#AuthorizedKeysCommand none
#AuthorizedKeysCommandUser nobody

# For this to work you will also need host keys in /etc/ssh/ssh_known_hosts
HostbasedAuthentication no
# Change to yes if you don't trust ~/.ssh/known_hosts for
# HostbasedAuthentication
#IgnoreUserKnownHosts no

8 Disable X11 Forwarding

X11Forwarding lets remote users access graphical applications (GUI) on the server. However, keeping X11 forwarding enabled can pose security risks. If an attacker gains access to a client PC, they could monitor keystrokes or carry out malicious activities.

To disable X11 Forwarding:

sudo nano /etc/ssh/sshd_config
#AllowAgentForwarding yes
#AllowTcpForwarding yes
#GatewayPorts no
X11Forwarding no
#X11DisplayOffset 10
#X11UseLocalhost yes
#PermitTTY yes

9 Disable TCP Port Forwarding

TCP Port Forwarding is helpful for securely accessing network services. However, it also brings potential security risks. Enabling TCP Port Forwarding can create a pathway for attackers to reach internal network services through the SSH tunnel.

To enhance security, you should disable TCP Port Forwarding using the following steps:

sudo nano /etc/ssh/sshd_config
#AllowAgentForwarding yes
AllowTcpForwarding no
#GatewayPorts no
X11Forwarding no
#X11DisplayOffset 10
#X11UseLocalhost yes
#PermitTTY yes

10 Enable Public/Private Key based login to Server

Using key-based login is considered a more secure method for accessing your server compared to password-based login. To set it up, you create an SSH key pair consisting of a public key and a private key. The public key is then stored on the server. When you attempt to access the server, the server verifies the private key stored on your client computer. If the keys match, you're granted access to the server; otherwise, access is denied.

Implement SSH Login: Windows to Ubuntu, CentOS, Linux Server using Public/Private Key

11 Allow/Block IP address for SSH connections

To add extra security to your SSH server, you should set up /etc/hosts.allow and /etc/hosts.deny files. This lets you specify which IP addresses can access the server and which ones should be blocked from accessing it.

The /etc/hosts.allow file serves the purpose of whitelisting users, IP addresses, or domains for accessing the server or its services.

The /etc/hosts.deny file is utilized for blacklisting users, IP addresses, or domains from accessing the server or its services.

sudo vi /etc/hosts.allow
# /etc/hosts.allow: list of hosts that are allowed to access the system.
#                   See the manual pages hosts_access(5) and hosts_options(5).
#
# Example:    ALL: LOCAL @some_netgroup
#             ALL: .foobar.edu EXCEPT terminalserver.foobar.edu
#
# If you're going to protect the portmapper use the name "rpcbind" for the
# daemon name. See rpcbind(8) and rpc.mountd(8) for further information.
#
sshd : 192.168.1.104

sudo vi /etc/hosts.deny
# /etc/hosts.deny: list of hosts that are _not_ allowed to access the system.
#                  See the manual pages hosts_access(5) and hosts_options(5).
#
# Example:    ALL: some.host.name, .some.domain
#             ALL EXCEPT in.fingerd: other.host.name, .other.domain
#
# You may wish to enable this to ensure any programs that don't
# validate looked up hostnames still leave understandable logs. In past
# versions of Debian this has been the default.
# ALL: PARANOID
sshd: ALL

12 Allow/Deny Users & groups to Access Server

By default, all users and groups can access the SSH server. However, you can configure the sshd_config file to specify which users and groups are allowed or blocked to access the server.

When you use the AllowUsers command, it means only the specified users can access the SSH server, and all others are blocked. Therefore, to make your server more secure, you must whitelist only the specified users.

Example

Add single user: AllowUsers Steven

Add multiple users: AllowUsers Steven Jack Smith

Complete Example

sudo vi /etc/ssh/sshd_config
# Example of overriding settings on a per-user basis
#Match User anoncvs
#       X11Forwarding no
#       AllowTcpForwarding no
#       PermitTTY no
#       ForceCommand cvs server

AllowUsers prashant smith

13 Set Timeout Interval for Inactive session.

Leaving your server logged in when you're not active could pose a security risk. It's a good idea to set a timeout interval. This way, if you're inactive for a certain period, the SSH connection will automatically be terminated.

sudo vi /etc/ssh/sshd_config
PrintMotd no
#PrintLastLog yes
#TCPKeepAlive yes
#PermitUserEnvironment no
#Compression delayed
ClientAliveInterval 180
#ClientAliveCountMax 3
#UseDNS no
#PidFile /run/sshd.pid
#MaxStartups 10:30:100
#PermitTunnel no
#ChrootDirectory none
#VersionAddendum none

14 Add a Warning Banner

A banner serves as a warning message to any unauthenticated users attempting to access your server. It's not just a passive security measure; it also plays a psychological role in server security by signaling to unwanted guests that their presence is detected. It communicates that you're aware of their attempts and that any malicious activity will not go unnoticed.

Prepare a text message carefully. You can seek assistance from AI to craft an effective warning message. Adding a banner is only beneficial if you deliver a concise warning message to the user.

Example:

sudo vi /etc/mybanner
WARNING: Unauthorized access to this server is strictly prohibited. You are being monitored. Any attempt to access this system without proper authorization will be logged and may result in legal action. By proceeding, you acknowledge that your actions are being recorded and may be subject to investigation. If you do not have explicit permission to access this server, terminate your connection immediately. Thank you.

sudo vi /etc/ssh/sshd_config
#PidFile /run/sshd.pid
#MaxStartups 10:30:100
#PermitTunnel no
#ChrootDirectory none
#VersionAddendum none

# no default banner path
Banner /etc/mybanner

# Allow client to pass locale environment variables
AcceptEnv LANG LC_*

Now, when you try to login next time, a warning message will be served to you.

15 Setting up Strong MAC Algorithms

MAC stands for Message Authentication Code in SSH. It's a cryptographic algorithm that's crucial for checking and confirming data transfers between the server and client.

To ensure that SSH uses a robust MAC algorithm during data transfer, add the following line to the sshd_config file.

MACs hmac-sha1,hmac-sha2-256,hmac-sha2-512

sudo vi /etc/ssh/sshd_config
# override default of no subsystems
Subsystem       sftp    /usr/lib/openssh/sftp-server

# Example of overriding settings on a per-user basis
#Match User anoncvs
#       X11Forwarding no
#       AllowTcpForwarding no
#       PermitTTY no
#       ForceCommand cvs server

MACs hmac-sha1,hmac-sha2-256,hmac-sha2-512

16 Set LogLevel to Monitor SSH Activity

You can monitor SSH activity at different levels of detail. By default, this feature might be disabled. It's suggested to enable it and set it to the basic LogLevel INFO, which will only log errors, messages, key authentication, login, and logout activities of users.

If you prefer, you can increase the verbosity level to VERBOSE or DEBUG. Here's the line you need to add to your sshd_config file:

sudo vi /etc/ssh/sshd_config

# Ciphers and keying
#RekeyLimit default none

# Logging
#SyslogFacility AUTH
LogLevel INFO

To see the log file navigate to following directory:

Debian/Ubuntu - /var/log/auth.log*
RHEL/CentOS/Fedora - /var/log/secure

17 Don't allow users to Set Environment Variables

If all users can set environment variables, it's possible for them to bypass security checks and execute malicious packages on the server. To prevent this, you should set PermitUserEnvironment no in the /etc/ssh/sshd_config file.

sudo vi /etc/ssh/sshd_config
# This is the sshd server system-wide configuration file.
# See sshd_config(5) for more information.

#X11UseLocalhost yes
#PermitTTY yes
PrintMotd no
#PrintLastLog yes
#TCPKeepAlive yes
PermitUserEnvironment no
#Compression delayed
#ClientAliveInterval 0
#ClientAliveCountMax 3

18 Monitor your server using auditd.

You need to watch for any changes on your server. If someone changes the setup, you should know who did it and what they changed.

Regularly checking your server's configuration helps keep it safe from hacking.

Install either the auditd or ssh-audit tool and perform audits regularly.

Install auditd

Ubuntu

sudo apt-get update
$sudo apt-get install auditd

CentOS

sudo yum update
$sudo yum install auditd

sudo systemctl enable auditd

sudo cat /var/log/audit/audit.log

19 Enforce SSH to Use PAM

PAM, short for Pluggable Authentication Modules, is a system in Linux designed to handle various authentication tasks like password authentication, account management, session management, and beyond.

It must be enabled in /etc/ssh/sshd_config file by using the parameter UsePAM yes.

sudo vi /etc/ssh/sshd_config
# This is the sshd server system-wide configuration file.
# See sshd_config(5) for more information.

# the setting of "PermitRootLogin without-password".
# If you just want the PAM account and session checks to run without
# PAM authentication, then enable this but set PasswordAuthentication
# and KbdInteractiveAuthentication to 'no'.
 UsePAM yes

20 Setting Firewall

Adding a firewall boosts the security of any server. It's important to install either UFW or Firewalld to control the firewall settings on your Linux system.

Settingup UFW Firewall

21 Restrict the Maximum Number of Simultaneous Sessions

If you know how many users will access the SSH server simultaneously, restrict the maximum number of users in the sshd_config file. Doing this safeguard your server from DoS attacks.

If you're the sole administrator of this server, simply set the value to 1. According to CIS recommendations, it's advisable to set the maximum value to 4.

sudo vi /etc/ssh/sshd_config
# This is the sshd server system-wide configuration file.
# See sshd_config(5) for more information.

 MaxStartups 1
#StrictModes yes
#MaxAuthTries 6
MaxAuthTries 3
 MaxSessions 1

22 Limit User Access

If you need someone to access your server, it's important to limit their user access to ensure your server's security. Limiting user access offers several security benefits, such as preventing unauthorized access to the entire server, controlling resource usage, preventing data loss, and protecting against threats.

You can take several steps to restrict user access effectively:

1. Create Specific Users: Consider creating a separate SFTP user and confine them within a designated folder, known as "jailing."
2. Check Sudo Access: Only grant sudo access to users who require it for tasks like installing apps or managing the server. If users don't need this level of access, it's best not to give them sudo privileges.
3. Manage File Permissions: Use file permissions to control access to specific files or directories. The chmod command allows you to set permissions for users, groups, and others, governing read, write, and execute privileges.
4. Utilize User Groups: Group users based on their access needs and assign appropriate permissions to these groups. This allows for easier management of access levels across your system.
5. Configure Firewall Rules: Set up firewall rules using tools like iptables or firewalld to restrict network access for specific users or groups. This adds an extra layer of protection by controlling inbound and outbound traffic.
6. Adjust SSH Configuration: Modify the /etc/ssh/sshd_config file to limit SSH access for specific users or groups. By specifying who can connect via SSH, you can further control access to your server.
7. Configure PAM: Configure Pluggable Authentication Modules (PAM) to enforce access restrictions based on criteria such as time of day, IP address, or user group. This enhances security by adding additional layers of authentication.

By implementing these measures, you can effectively limit user access to your server, enhancing its security and minimizing the risk of unauthorized access or breaches.

23 Install SELinux

SELinux stands for Security-Enhanced Linux. It's a security tool built into Linux to add extra protection. It works by setting rules that control who can access what on the system.

For example, it can decide if a user, a program, or a file is allowed to do something based on labels assigned to them. These labels help SELinux enforce these rules and keep the system secure.

Disable AppArmor before Installing SELinux

It is mandatory to disable AppArmor before installing the SELinux. You can do this as follows:

systemctl status apparmor
apparmor.service - Load AppArmor profiles
Loaded: loaded (/lib/systemd/system/apparmor.service; enabled; vendor preset: enabled)
Active: active

sudo systemctl stop apparmor
$sudo systemctl disable apparmor

Installing SELinux on Ubuntu and CentOS

Ubuntu

Install

sudo apt update && sudo apt upgrade -y
$sudo apt install policycoreutils selinux-basics selinux-utils -y

Enable SELinux

sudo selinux-activate
SELinux is activated. You may need to reboot now.

Check Status

sestatus
SELinux status:                 disabled

Config File

sudo cat /etc/selinux/config
# This file controls the state of SELinux on the system.
# SELINUX= can take one of these three values:
# enforcing - SELinux security policy is enforced.
# permissive - SELinux prints warnings instead of enforcing.
# disabled - No SELinux policy is loaded.
 SELINUX=permissive
# SELINUXTYPE= can take one of these two values:
# default - equivalent to the old strict and targeted policies
# mls     - Multi-Level Security (for military and educational use)
# src     - Custom policy built from source
SELINUXTYPE=default

# SETLOCALDEFS= Check local definition changes
SETLOCALDEFS=0

Reboot to Activate

sudo reboot --f

CentOS

Install

sudo yum update
$sudo yum install policycoreutils policycoreutils-python setools setools-console setroubleshoot

Check Status

sudo sestatus
SELinux status:                 disabled

Config File

sudo cat /etc/selinux/config
# This file controls the state of SELinux on the system.
# SELINUX= can take one of these three values:
#     enforcing - SELinux security policy is enforced.
#     permissive - SELinux prints warnings instead of enforcing.
#     disabled - No SELinux policy is loaded.
SELINUX=enforcing
# SELINUXTYPE= can take one of these three values:
#     targeted - Targeted processes are protected,
#     minimum - Modification of targeted policy. Only selected processes are protected.
#     mls - Multi Level Security protection.
SELINUXTYPE=targeted

Reboot to Activate

sudo reboot --f

Mode

In SELinux, there are two modes: enforcing and permissive. Enforcing mode strictly applies the rules, whereas permissive mode is less strict in its rule application. After configuring SELinux, it's advisable to set it to enforcing mode.

Set Enforcing Mode:

sudo setenforce 1

Set Permissive Mode:

sudo setenforce 0

24 Enable Two-Factor Authentication (2FA)

Google Authenticator is an excellent method for implementing Two-Factor Authentication on your SSH server. It boosts security by adding an extra layer of protection, offering time-based one-time passwords (OTPs) to complete the login process.

Setup Google Authenticator on Ubuntu/CentOS and Enable 2-Factor Authentication/Multi-Factor Authentication

25 Monitor SSH logs

It's a good idea to check SSH logs regularly. They can show you if anything strange is happening on your server, like someone trying to break in or unusual user actions. Plus, you can learn about system performance and resource use.

In short, checking SSH logs is vital for keeping your system safe, running smoothly, and staying on top of cybersecurity.

journalctl -u ssh

sudo grep sshd /var/log/auth.log

lastlog

26 Use Fail2ban

Fail2ban is a security tool that stops unauthorized access to a system. It watches log files for suspicious actions, like lots of failed login attempts, and then blocks the source of that activity.

When Fail2ban spots something fishy, it adds rules to the firewall to block the attacker's IP address. This stops them from trying to log in again, which makes brute force attacks and other sneaky access attempts less likely to succeed.

Install and Configure Fail2Ban on Ubuntu 23.10/CentOS 8/Linux Server

27 Disable Non-admin SSH tunnelling.

Non-admin SSH tunnelling means regular users can create SSH tunnels, which let them send network connections from one port to another on a distant server. This could be risky because it allows users to bypass network security and access things they shouldn't.

Disabling non-admin SSH tunneling is recommended for security reasons because it helps prevent unauthorized access and potential security breaches. By limiting SSH tunneling to administrative users only, you reduce the risk of users exploiting this feature to circumvent network restrictions or gain unauthorized access to sensitive systems or data.

sudo vi /etc/ssh/sshd_config
# This is the sshd server system-wide configuration file.
# See sshd_config(5) for more information.

AllowTcpForwarding no
Match Group root
AllowTcpForwarding yes