Skip to content


Folders and files

Last commit message
Last commit date

Latest commit


Repository files navigation

How To Secure A Linux Server

An evolving how-to guide for securing a Linux server that, hopefully, also teaches you a little about security and why it matters.


Table of Contents

(TOC made with nGitHubTOC)


Guide Objective

This guides purpose is to teach you how to secure a Linux server.

There are a lot of things you can do to secure a Linux server and this guide will attempt to cover as many of them as possible. More topics/material will be added as I learn, or as folks contribute.

Ansible playbooks of this guide are available at How To Secure A Linux Server With Ansible by moltenbit.

(Table of Contents)

Why Secure Your Server

I assume you're using this guide because you, hopefully, already understand why good security is important. That is a heavy topic onto itself and breaking it down is out-of-scope for this guide. If you don't know the answer to that question, I advise you research it first.

At a high level, the second a device, like a server, is in the public domain -- i.e. visible to the outside world -- it becomes a target for bad-actors. An unsecured device is a playground for bad-actors who want access to your data, or to use your server as another node for their large-scale DDOS attacks.

What's worse is, without good security, you may never know if your server has been compromised. A bad-actor may have gained unauthorized access to your server and copied your data without changing anything, so you'd never know. Or your server may have been part of a DDOS attack, and you wouldn't know. Look at many of the large scale data breaches in the news -- the companies often did not discover the data leak or intrusion until long after the bad-actors were gone.

Contrary to popular belief, bad-actors don't always want to change something or lock you out of your data for money. Sometimes they just want the data on your server for their data warehouses (there is big money in big data) or to covertly use your server for their nefarious purposes.

(Table of Contents)

Why Yet Another Guide

This guide may appear duplicative/unnecessary because there are countless articles online that tell you how to secure Linux, but the information is spread across different articles, that cover different things, and in different ways. Who has time to scour through hundreds of articles?

As I was going through research for my Debian build, I kept notes. At the end I realized that, along with what I already knew, and what I was learning, I had the makings of a how-to guide. I figured I'd put it online to hopefully help others learn, and save time.

I've never found one guide that covers everything -- this guide is my attempt.

Many of the things covered in this guide may be rather basic/trivial, but most of us do not install Linux every day, and it is easy to forget those basic things.

(Table of Contents)

Other Guides

There are many guides provided by experts, industry leaders, and the distributions themselves. It is not practical, and sometimes against copyright, to include everything from those guides. I recommend you check them out before starting with this guide.

(Table of Contents)

To Do / To Add

(Table of Contents)

Guide Overview

About This Guide

This guide...

  • a work in progress.
  • focused on at-home Linux servers. All of the concepts/recommendations here apply to larger/professional environments but those use-cases call for more advanced and specialized configurations that are out-of-scope for this guide.
  • ...does not teach you about Linux, how to install Linux, or how to use it. Check if you're new to Linux.
  • meant to be Linux distribution agnostic.
  • ...does not teach you everything you need to know about security nor does it get into all aspects of system/server security. For example, physical security is out of scope for this guide.
  • ...does not talk about how programs/tools work, nor does it delve into their nook and crannies. Most of the programs/tools this guide references are very powerful and highly configurable. The goal is to cover the bare necessities -- enough to whet your appetite and make you hungry enough to want to go and learn more.
  • ...aims to make it easy by providing code you can copy-and-paste. You might need to modify the commands before you paste so keep your favorite text editor handy.
  • organized in an order that makes logical sense to me -- i.e. securing SSH before installing a firewall. As such, this guide is intended to be followed in the order it is presented, but it is not necessary to do so. Just be careful if you do things in a different order -- some sections require previous sections to be completed.

(Table of Contents)

My Use-Case

There are many types of servers and different use-cases. While I want this guide to be as generic as possible, there will be some things that may not apply to all/other use-cases. Use your best judgement when going through this guide.

To help put context to many of the topics covered in this guide, my use-case/configuration is:

  • A desktop class computer...
  • With a single NIC...
  • Connected to a consumer grade router...
  • Getting a dynamic WAN IP provided by the ISP...
  • With WAN+LAN on IPV4...
  • And LAN using NAT...
  • That I want to be able to SSH to remotely from unknown computers and unknown locations (i.e. a friend's house).

(Table of Contents)

Editing Configuration Files - For The Lazy

I am very lazy and do not like to edit files by hand if I don't need to. I also assume everyone else is just like me. :)

So, when and where possible, I have provided code snippets to quickly do what is needed, like add or change a line in a configuration file.

The code snippets use basic commands like echo, cat, sed, awk, and grep. How the code snippets work, like what each command/part does, is out of scope for this guide -- the man pages are your friend.

Note: The code snippets do not validate/verify the change went through -- i.e. the line was actually added or changed. I'll leave the verifying part in your capable hands. The steps in this guide do include taking backups of all files that will be changed.

Not all changes can be automated with code snippets. Those changes need good, old-fashioned, manual editing. For example, you can't just append a line to an INI type file. Use your favorite Linux text editor.

(Table of Contents)


I wanted to put this guide on GitHub to make it easy to collaborate. The more folks that contribute, the better and more complete this guide will become.

To contribute you can fork and submit a pull request or submit a new issue.

(Table of Contents)

Before You Start

Identify Your Principles

Before you start you will want to identify what your Principles are. What is your threat model? Some things to think about:

  • Why do you want to secure your server?
  • How much security do you want or not want?
  • How much convenience are you willing to compromise for security and vice-versa?
  • What are the threats you want to protect against? What are the specifics to your situation? For example:
    • Is physical access to your server/network a possible attack vector?
    • Will you be opening ports on your router so you can access your server from outside your home?
    • Will you be hosting a file share on your server that will be mounted on a desktop class machine? What is the possibility of the desktop machine getting infected and, in turn, infecting the server?
  • Do you have a means of recovering if your security implementation locks you out of your own server? For example, you disabled root login or password protected GRUB.

These are just a few things to think about. Before you start securing your server you will want to understand what you're trying to protect against and why so you know what you need to do.

(Table of Contents)

Picking A Linux Distribution

This guide is intended to be distribution agnostic so users can use any distribution they want. With that said, there are a few things to keep in mind:

You want a distribution that...

  • stable. Unless you like debugging issues at 2 AM, you don't want an unattended upgrade, or a manual package/system update, to render your server inoperable. But this also means you're okay with not running the latest, greatest, bleeding edge software.
  • ...stays up-to-date with security patches. You can secure everything on your server, but if the core OS or applications you're running have known vulnerabilities, you'll never be safe.
  •'re familiar with. If you don't know Linux, I would advise you play around with one before you try to secure it. You should be comfortable with it and know your way around, like how to install software, where configuration files are, etc...
  • well-supported. Even the most seasoned admin needs help every now and then. Having a place to go for help will save your sanity.

(Table of Contents)

Installing Linux

Installing Linux is out-of-scope for this guide because each distribution does it differently and the installation instructions are usually well documented. If you need help, start with your distribution's documentation. Regardless of the distribution, the high-level process usually goes like so:

  1. download the ISO
  2. burn/copy/transfer it to your install medium (e.g. a CD or USB stick)
  3. boot your server from your install medium
  4. follow the prompts to install

Where applicable, use the expert install option so you have tighter control of what is running on your server. Only install what you absolutely need. I, personally, do not install anything other than SSH. Also, tick the Disk Encryption option.

(Table of Contents)

Pre/Post Installation Requirements

  • If you're opening ports on your router so you can access your server from the outside, disable the port forwarding until your system is up and secured.
  • Unless you're doing everything physically connected to your server, you'll need remote access so be sure SSH works.
  • Keep your system up-to-date (i.e. sudo apt update && sudo apt upgrade on Debian based systems).
  • Make sure you perform any tasks specific to your setup like:
    • Configuring network
    • Configuring mount points in /etc/fstab
    • Creating the initial user accounts
    • Installing core software you'll want like man
    • Etc...
  • Your server will need to be able to send e-mails so you can get important security alerts. If you're not setting up a mail server check Gmail and Exim4 As MTA With Implicit TLS.
  • I would also recommend you read through the CIS Benchmarks before you start with this guide just to digest/understand what they have to say. My recommendation is to go through this guide (the one you're reading here) first and THEN CIS's guide. That way their recommendations will trump anything in this guide.

(Table of Contents)

Other Important Notes

  • This guide is being written and tested on Debian. Most things below should work on other distributions. If you find something that does not, please contact me. The main thing that separates each distribution will be its package management system. Since I use Debian, I will provide the appropriate apt commands that should work on all Debian based distributions. If someone is willing to provide the respective commands for other distributions, I will add them.
  • File paths and settings also may differ slightly -- check with your distribution's documentation if you have issues.
  • Read the whole guide before you start. Your use-case and/or principals may call for not doing something or for changing the order.
  • Do not blindly copy-and-paste without understanding what you're pasting. Some commands will need to be modified for your needs before they'll work -- usernames for example.

(Table of Contents)

Using Ansible playbooks to secure your Linux Server

Ansible playbooks of this guide are available at How To Secure A Linux Server With Ansible.

Make sure to edit the variables according to your needs and read all tasks beforehand to confirm it does not break your system. After running the playbooks ensure that all settings are configured to your needs!

  1. Install Ansible
  2. git clone How To Secure A Linux Server With Ansible
  3. Create SSH-Public/Private-Keys
ssh-keygen -t ed25519
  1. Change all variables in group_vars/variables.yml according to your needs.
  2. Enable SSH root access before running the playbooks:
nano /etc/ssh/sshd_config
PermitRootLogin yes
  1. Recommended: configure static IP address on your system.
  2. Add your systems IP address to hosts.yml.


Run the requirements playbook using the root password you specified while installing the server:

ansible-playbook --inventory hosts.yml --ask-pass requirements-playbook.yml


Run the main playbook with the new users password you specified in the variables.yml file:

ansible-playbook --inventory hosts.yml --ask-pass main-playbook.yml


If you need to run the playbooks multiple times remember to use the SSH key and the new SSH port:

ansible-playbook --inventory hosts.yml -e ansible_ssh_port=SSH_PORT --key-file /PATH/TO/SSH/KEY main-playbook.yml

(Table of Contents)

The SSH Server

Important Note Before You Make SSH Changes

It is highly advised you keep a 2nd terminal open to your server before you make and apply SSH configuration changes. This way if you lock yourself out of your 1st terminal session, you still have one session connected so you can fix it.

Thank you to Sonnenbrand for this idea.

SSH Public/Private Keys


Using SSH public/private keys is more secure than using a password. It also makes it easier and faster, to connect to our server because you don't have to enter a password.

How It Works

Check the references below for more details but, at a high level, public/private keys work by using a pair of keys to verify identity.

  1. One key, the public key, can only encrypt data, not decrypt it
  2. The other key, the private key, can decrypt the data

For SSH, a public and private key is created on the client. You want to keep both keys secure, especially the private key. Even though the public key is meant to be public, it is wise to make sure neither keys fall in the wrong hands.

When you connect to an SSH server, SSH will look for a public key that matches the client you're connecting from in the file ~/.ssh/authorized_keys on the server you're connecting to. Notice the file is in the home folder of the ID you're trying to connect to. So, after creating the public key, you need to append it to ~/.ssh/authorized_keys. One approach is to copy it to a USB stick and physically transfer it to the server. Another approach is to use ssh-copy-id to transfer and append the public key.

After the keys have been created and the public key has been appended to ~/.ssh/authorized_keys on the host, SSH uses the public and private keys to verify identity and then establish a secure connection. How identity is verified is a complicated process but Digital Ocean has a very nice write-up of how it works. At a high level, identity is verified by the server encrypting a challenge message with the public key, then sending it to the client. If the client cannot decrypt the challenge message with the private key, the identity can't be verified and a connection will not be established.

They are considered more secure because you need the private key to establish an SSH connection. If you set PasswordAuthentication no in /etc/ssh/sshd_config, then SSH won't let you connect without the private key.

You can also set a pass-phrase for the keys which would require you to enter the key pass-phrase when connecting using public/private keys. Keep in mind doing this means you can't use the key for automation because you'll have no way to send the passphrase in your scripts. ssh-agent is a program that is shipped in many Linux distros (and usually already running) that will allow you to hold your unencrypted private key in memory for a configurable duration. Simply run ssh-add and it will prompt you for your passphrase. You will not be prompted for your passphrase again until the configurable duration has passed.

We will be using Ed25519 keys which, according to

It is using an elliptic curve signature scheme, which offers better security than ECDSA and DSA. At the same time, it also has good performance.


  • Ed25519 public/private SSH keys:
    • private key on your client
    • public key on your server


  • You'll need to do this step for every computer and account you'll be connecting to your server from/as.



  1. From the computer you're going to use to connect to your server, the client, not the server itself, create an Ed25519 key with ssh-keygen:

    ssh-keygen -t ed25519
    Generating public/private ed25519 key pair.
    Enter file in which to save the key (/home/user/.ssh/id_ed25519):
    Created directory '/home/user/.ssh'.
    Enter passphrase (empty for no passphrase):
    Enter same passphrase again:
    Your identification has been saved in /home/user/.ssh/id_ed25519.
    Your public key has been saved in /home/user/.ssh/
    The key fingerprint is:
    SHA256:F44D4dr2zoHqgj0i2iVIHQ32uk/Lx4P+raayEAQjlcs user@client
    The key's randomart image is:
    +--[ED25519 256]--+
    |xxxx  x          |
    |o.o +. .         |
    | o o oo   .      |
    |. E oo . o .     |
    | o o. o S o      |
    |... .. o o       |
    |.+....+ o        |
    |+.=++o.B..       |
    |+..=**=o=.       |

    Note: If you set a passphrase, you'll need to enter it every time you connect to your server using this key, unless you're using ssh-agent.

  2. Now you need to append the public key ~/.ssh/ from your client to the ~/.ssh/authorized_keys file on your server. Since we're presumable still at home on the LAN, we're probably safe from MIM attacks, so we will use ssh-copy-id to transfer and append the public key:

    ssh-copy-id user@server
    /usr/bin/ssh-copy-id: INFO: Source of key(s) to be installed: "/home/user/.ssh/"
    The authenticity of host 'host (' can't be established.
    ECDSA key fingerprint is SHA256:QaDQb/X0XyVlogh87sDXE7MR8YIK7ko4wS5hXjRySJE.
    Are you sure you want to continue connecting (yes/no)? yes
    /usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed
    /usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are prompted now it is to install the new keys
    user@host's password:
    Number of key(s) added: 1
    Now try logging into the machine, with:   "ssh 'user@host'"
    and check to make sure that only the key(s) you wanted were added.

Now would be a good time to perform any tasks specific to your setup.

(Table of Contents)

Create SSH Group For AllowGroups


To make it easy to control who can SSH to the server. By using a group, we can quickly add/remove accounts to the group to quickly allow or not allow SSH access to the server.

How It Works

We will use the AllowGroups option in SSH's configuration file /etc/ssh/sshd_config to tell the SSH server to only allow users to SSH in if they are a member of a certain UNIX group. Anyone not in the group will not be able to SSH in.




  • man groupadd
  • man usermod


  1. Create a group:

    sudo groupadd sshusers
  2. Add account(s) to the group:

    sudo usermod -a -G sshusers user1
    sudo usermod -a -G sshusers user2
    sudo usermod -a -G sshusers ...

    You'll need to do this for every account on your server that needs SSH access.

(Table of Contents)

Secure /etc/ssh/sshd_config


SSH is a door into your server. This is especially true if you are opening ports on your router so you can SSH to your server from outside your home network. If it is not secured properly, a bad-actor could use it to gain unauthorized access to your system.

How It Works

/etc/ssh/sshd_config is the default configuration file that the SSH server uses. We will use this file to tell what options the SSH server should use.


  • a secure SSH configuration




  1. Make a backup of OpenSSH server's configuration file /etc/ssh/sshd_config and remove comments to make it easier to read:

    sudo cp --archive /etc/ssh/sshd_config /etc/ssh/sshd_config-COPY-$(date +"%Y%m%d%H%M%S")
    sudo sed -i -r -e '/^#|^$/ d' /etc/ssh/sshd_config
  2. Edit /etc/ssh/sshd_config then find and edit or add these settings that should be applied regardless of your configuration/setup:

    Note: SSH does not like duplicate contradicting settings. For example, if you have ChallengeResponseAuthentication no and then ChallengeResponseAuthentication yes, SSH will respect the first one and ignore the second. Your /etc/ssh/sshd_config file may already have some of the settings/lines below. To avoid issues you will need to manually go through your /etc/ssh/sshd_config file and address any duplicate contradicting settings.

    # start settings from as of 2019-01-01
    # Supported HostKey algorithms by order of preference.
    HostKey /etc/ssh/ssh_host_ed25519_key
    HostKey /etc/ssh/ssh_host_rsa_key
    HostKey /etc/ssh/ssh_host_ecdsa_key
    # LogLevel VERBOSE logs user's key fingerprint on login. Needed to have a clear audit track of which key was using to log in.
    LogLevel VERBOSE
    # Use kernel sandbox mechanisms where possible in unprivileged processes
    # Systrace on OpenBSD, Seccomp on Linux, seatbelt on MacOSX/Darwin, rlimit elsewhere.
    # Note: This setting is deprecated in OpenSSH 7.5 (
    # UsePrivilegeSeparation sandbox
    # end settings from as of 2019-01-01
    # don't let users set environment variables
    PermitUserEnvironment no
    # Log sftp level file access (read/write/etc.) that would not be easily logged otherwise.
    Subsystem sftp  internal-sftp -f AUTHPRIV -l INFO
    # only use the newer, more secure protocol
    Protocol 2
    # disable X11 forwarding as X11 is very insecure
    # you really shouldn't be running X on a server anyway
    X11Forwarding no
    # disable port forwarding
    AllowTcpForwarding no
    AllowStreamLocalForwarding no
    GatewayPorts no
    PermitTunnel no
    # don't allow login if the account has an empty password
    PermitEmptyPasswords no
    # ignore .rhosts and .shosts
    IgnoreRhosts yes
    # verify hostname matches IP
    UseDNS yes
    Compression no
    TCPKeepAlive no
    AllowAgentForwarding no
    PermitRootLogin no
    # don't allow .rhosts or /etc/hosts.equiv
    HostbasedAuthentication no
    HashKnownHosts yes
  3. Then find and edit or add these settings, and set values as per your requirements:

    Setting Valid Values Example Description Notes
    AllowGroups local UNIX group name AllowGroups sshusers group to allow SSH access to
    ClientAliveCountMax number ClientAliveCountMax 0 maximum number of client alive messages sent without response
    ClientAliveInterval number of seconds ClientAliveInterval 300 timeout in seconds before a response request
    ListenAddress space separated list of local addresses
    • ListenAddress
    • ListenAddress
    local addresses sshd should listen on See Issue #1 for important details.
    LoginGraceTime number of seconds LoginGraceTime 30 time in seconds before login times-out
    MaxAuthTries number MaxAuthTries 2 maximum allowed attempts to login
    MaxSessions number MaxSessions 2 maximum number of open sessions
    MaxStartups number MaxStartups 2 maximum number of login sessions
    PasswordAuthentication yes or no PasswordAuthentication no if login with a password is allowed
    Port any open/available port number Port 22 port that sshd should listen on

    Check man sshd_config for more details what these settings mean.

  4. Make sure there are no duplicate settings that contradict each other. The below command should not have any output.

    awk 'NF && $1!~/^(#|HostKey)/{print $1}' /etc/ssh/sshd_config | sort | uniq -c | grep -v ' 1 '
  5. Restart ssh:

    sudo service sshd restart
  6. You can check verify the configurations worked with sshd -T and verify the output:

    sudo sshd -T
    port 22
    addressfamily any
    listenaddress [::]:22
    usepam yes
    logingracetime 30
    x11displayoffset 10
    maxauthtries 2
    maxsessions 2
    clientaliveinterval 300
    clientalivecountmax 0
    streamlocalbindmask 0177
    permitrootlogin no
    ignorerhosts yes
    ignoreuserknownhosts no
    hostbasedauthentication no
    subsystem sftp internal-sftp -f AUTHPRIV -l INFO
    maxstartups 2:30:2
    permittunnel no
    ipqos lowdelay throughput
    rekeylimit 0 0
    permitopen any

(Table of Contents)

Remove Short Diffie-Hellman Keys


Per Mozilla's OpenSSH guidelines for OpenSSH 6.7+, "all Diffie-Hellman moduli in use should be at least 3072-bit-long".

The Diffie-Hellman algorithm is used by SSH to establish a secure connection. The larger the moduli (key size) the stronger the encryption.


  • remove all Diffie-Hellman keys that are less than 3072 bits long



  1. Make a backup of SSH's moduli file /etc/ssh/moduli:

    sudo cp --archive /etc/ssh/moduli /etc/ssh/moduli-COPY-$(date +"%Y%m%d%H%M%S")
  2. Remove short moduli:

    sudo awk '$5 >= 3071' /etc/ssh/moduli | sudo tee /etc/ssh/moduli.tmp
    sudo mv /etc/ssh/moduli.tmp /etc/ssh/moduli

(Table of Contents)



Even though SSH is a pretty good security guard for your doors and windows, it is still a visible door that bad-actors can see and try to brute-force in. Fail2ban will monitor for these brute-force attempts but there is no such thing as being too secure. Requiring two factors adds an extra layer of security.

Using Two-Factor Authentication (2FA) / Multi-Factor Authentication (MFA) requires anyone entering to have two keys to enter which makes it harder for bad actors. The two keys are:

  1. Their password
  2. A 6 digit token that changes every 30 seconds

Without both keys, they won't be able to get in.

Why Not

Many folks might find the experience cumbersome or annoying. And, access to your system is dependent on the accompanying authenticator app that generates the code.

How It Works

On Linux, PAM is responsible for authentication. There are four tasks to PAM that you can read about at This section talks about the authentication task.

When you log into a server, be it directly from the console or via SSH, the door you came through will send the request to the authentication task of PAM and PAM will ask for and verify your password. You can customize the rules each doors use. For example, you could have one set of rules when logging in directly from the console and another set of rules for when logging in via SSH.

This section will alter the authentication rules for when logging in via SSH to require both a password and a 6 digit code.

We will use Google's libpam-google-authenticator PAM module to create and verify a TOTP key. and have very good writeups of how TOTP works.

What we will do is tell the server's SSH PAM configuration to ask the user for their password and then their numeric token. PAM will then verify the user's password and, if it is correct, then it will route the authentication request to libpam-google-authenticator which will ask for and verify your 6 digit token. If, and only if, everything is good will the authentication succeed and user be allowed to log in.


  • 2FA/MFA enabled for all SSH connections


  • Before you do this, you should have an idea of how 2FA/MFA works and you'll need an authenticator app on your phone to continue.
  • We'll use google-authenticator-libpam.
  • With the below configuration, a user will only need to enter their 2FA/MFA code if they are logging on with their password but not if they are using SSH public/private keys. Check the documentation on how to change this behavior to suite your requirements.



  1. Install it libpam-google-authenticator.

    On Debian based systems:

    sudo apt install libpam-google-authenticator
  2. Make sure you're logged in as the ID you want to enable 2FA/MFA for and execute google-authenticator to create the necessary token data:

    Do you want authentication tokens to be time-based (y/n) y|0&cht=qr&chl=otpauth://totp/user@host%3Fsecret%3DR4ZWX34FQKZROVX7AGLJ64684Y%26issuer%3Dhost
    Your new secret key is: R3NVX3FFQKZROVX7AGLJUGGESY
    Your verification code is 751419
    Your emergency scratch codes are:
    Do you want me to update your "/home/user/.google_authenticator" file (y/n) y
    Do you want to disallow multiple uses of the same authentication
    token? This restricts you to one login about every 30s, but it increases
    your chances to notice or even prevent man-in-the-middle attacks (y/n) Do you want to disallow multiple uses of the same authentication
    token? This restricts you to one login about every 30s, but it increases
    your chances to notice or even prevent man-in-the-middle attacks (y/n) y
    By default, tokens are good for 30 seconds. In order to compensate for
    possible time-skew between the client and the server, we allow an extra
    token before and after the current time. If you experience problems with
    poor time synchronization, you can increase the window from its default
    size of +-1min (window size of 3) to about +-4min (window size of
    17 acceptable tokens).
    Do you want to do so? (y/n) y
    If the computer that you are logging into isn't hardened against brute-force
    login attempts, you can enable rate-limiting for the authentication module.
    By default, this limits attackers to no more than 3 login attempts every 30s.
    Do you want to enable rate-limiting (y/n) y

    Notice this is not run as root.

    Select default option (y in most cases) for all the questions it asks and remember to save the emergency scratch codes.

  3. Make a backup of PAM's SSH configuration file /etc/pam.d/sshd:

    sudo cp --archive /etc/pam.d/sshd /etc/pam.d/sshd-COPY-$(date +"%Y%m%d%H%M%S")
  4. Now we need to enable it as an authentication method for SSH by adding this line to /etc/pam.d/sshd:

    auth       required nullok

    Note: Check here for what nullok means.

    For the lazy:

    echo -e "\nauth       required nullok         # added by $(whoami) on $(date +"%Y-%m-%d @ %H:%M:%S")" | sudo tee -a /etc/pam.d/sshd
  5. Tell SSH to leverage it by adding or editing this line in /etc/ssh/sshd_config:

    ChallengeResponseAuthentication yes

    For the lazy:

    sudo sed -i -r -e "s/^(challengeresponseauthentication .*)$/# \1         # commented by $(whoami) on $(date +"%Y-%m-%d @ %H:%M:%S")/I" /etc/ssh/sshd_config
    echo -e "\nChallengeResponseAuthentication yes         # added by $(whoami) on $(date +"%Y-%m-%d @ %H:%M:%S")" | sudo tee -a /etc/ssh/sshd_config
  6. Restart ssh:

    sudo service sshd restart

(Table of Contents)

The Basics

Limit Who Can Use sudo


sudo lets accounts run commands as other accounts, including root. We want to make sure that only the accounts we want can use sudo.


  • sudo privileges limited to those who are in a group we specify


  • Your installation may have already done this, or may already have a special group intended for this purpose so check first.
    • Debian creates the sudo group. To view users that are part of this group (thus have sudo privileges):

      cat /etc/group | grep "sudo"
    • RedHat creates the wheel group

  • See #39 for a note on some distributions making it so sudo does not require a password. Thanks to sbrl for sharing.


  1. Create a group:

    sudo groupadd sudousers
  2. Add account(s) to the group:

    sudo usermod -a -G sudousers user1
    sudo usermod -a -G sudousers user2
    sudo usermod -a -G sudousers  ...

    You'll need to do this for every account on your server that needs sudo privileges.

  3. Make a backup of the sudo's configuration file /etc/sudoers:

    sudo cp --archive /etc/sudoers /etc/sudoers-COPY-$(date +"%Y%m%d%H%M%S")
  4. Edit sudo's configuration file /etc/sudoers:

    sudo visudo
  5. Tell sudo to only allow users in the sudousers group to use sudo by adding this line if it is not already there:

    %sudousers   ALL=(ALL:ALL) ALL

(Table of Contents)

Limit Who Can Use su


su also lets accounts run commands as other accounts, including root. We want to make sure that only the accounts we want can use su.


  • su privileges limited to those who are in a group we specify



  1. Create a group:

    sudo groupadd suusers
  2. Add account(s) to the group:

    sudo usermod -a -G suusers user1
    sudo usermod -a -G suusers user2
    sudo usermod -a -G suusers  ...

    You'll need to do this for every account on your server that needs sudo privileges.

  3. Make it so only users in this group can execute /bin/su:

    sudo dpkg-statoverride --update --add root suusers 4750 /bin/su

(Table of Contents)

Run applications in a sandbox with FireJail


It's absolutely better, for many applications, to run in a sandbox.

Browsers (even more the Closed Source ones) and eMail Clients are highly suggested.


  • confine applications in a jail (few safe directories) and block access to the rest of the system



  1. Install the software:

    sudo apt install firejail firejail-profiles

    Note: for Debian 10 Stable, official Backport is suggested:

    sudo apt install -t buster-backports firejail firejail-profiles
  2. Allow an application (installed in /usr/bin or /bin) to run only in a sandbox (see few examples below here):

    sudo ln -s /usr/bin/firejail /usr/local/bin/google-chrome-stable
    sudo ln -s /usr/bin/firejail /usr/local/bin/firefox
    sudo ln -s /usr/bin/firejail /usr/local/bin/chromium
    sudo ln -s /usr/bin/firejail /usr/local/bin/evolution
    sudo ln -s /usr/bin/firejail /usr/local/bin/thunderbird
  3. Run the application as usual (via terminal or launcher) and check if it's running in a jail:

    firejail --list
  4. Allow a sandboxed app to run again as it was before (example: firefox)

    sudo rm /usr/local/bin/firefox

(Table of Contents)

NTP Client


Many security protocols leverage the time. If your system time is incorrect, it could have negative impacts to your server. An NTP client can solve that problem by keeping your system time in-sync with global NTP servers

How It Works

NTP stands for Network Time Protocol. In the context of this guide, an NTP client on the server is used to update the server time with the official time pulled from official servers. Check for all of the public NTP servers.


  • NTP client installed and keeping server time in-sync



  1. Install ntp.

    On Debian based systems:

    sudo apt install ntp
  2. Make a backup of the NTP client's configuration file /etc/ntp.conf:

    sudo cp --archive /etc/ntpsec/ntp.conf /etc/ntpsec/ntp.conf-COPY-$(date +"%Y%m%d%H%M%S")
  3. The default configuration, at least on Debian, is already pretty secure. The only thing we'll want to make sure is we're the pool directive and not any server directives. The pool directive allows the NTP client to stop using a server if it is unresponsive or serving bad time. Do this by commenting out all server directives and adding the below to /etc/ntp.conf.

    pool iburst

    For the lazy:

    sudo sed -i -r -e "s/^((server|pool).*)/# \1         # commented by $(whoami) on $(date +"%Y-%m-%d @ %H:%M:%S")/" /etc/ntp.conf
    echo -e "\npool iburst         # added by $(whoami) on $(date +"%Y-%m-%d @ %H:%M:%S")" | sudo tee -a /etc/ntp.conf

    Example /etc/ntp.conf:

    driftfile /var/lib/ntp/ntp.drift
    statistics loopstats peerstats clockstats
    filegen loopstats file loopstats type day enable
    filegen peerstats file peerstats type day enable
    filegen clockstats file clockstats type day enable
    restrict -4 default kod notrap nomodify nopeer noquery limited
    restrict -6 default kod notrap nomodify nopeer noquery limited
    restrict ::1
    restrict source notrap nomodify noquery
    pool iburst         # added by user on 2019-03-09 @ 10:23:35
  4. Restart ntp:

    sudo service ntp restart
  5. Check the status of the ntp service:

    sudo systemctl status ntp
    ● ntp.service - LSB: Start NTP daemon
       Loaded: loaded (/etc/init.d/ntp; generated; vendor preset: enabled)
       Active: active (running) since Sat 2019-03-09 15:19:46 EST; 4s ago
         Docs: man:systemd-sysv-generator(8)
      Process: 1016 ExecStop=/etc/init.d/ntp stop (code=exited, status=0/SUCCESS)
      Process: 1028 ExecStart=/etc/init.d/ntp start (code=exited, status=0/SUCCESS)
        Tasks: 2 (limit: 4915)
       CGroup: /system.slice/ntp.service
               └─1038 /usr/sbin/ntpd -p /var/run/ -g -u 108:113
    Mar 09 15:19:46 host ntpd[1038]: Listen and drop on 0 v6wildcard [::]:123
    Mar 09 15:19:46 host ntpd[1038]: Listen and drop on 1 v4wildcard
    Mar 09 15:19:46 host ntpd[1038]: Listen normally on 2 lo
    Mar 09 15:19:46 host ntpd[1038]: Listen normally on 3 enp0s3
    Mar 09 15:19:46 host ntpd[1038]: Listen normally on 4 lo [::1]:123
    Mar 09 15:19:46 host ntpd[1038]: Listen normally on 5 enp0s3 [fe80::a00:27ff:feb6:ed8e%2]:123
    Mar 09 15:19:46 host ntpd[1038]: Listening on routing socket on fd #22 for interface updates
    Mar 09 15:19:47 host ntpd[1038]: Soliciting pool server
    Mar 09 15:19:48 host ntpd[1038]: Soliciting pool server
    Mar 09 15:19:49 host ntpd[1038]: Soliciting pool server
  6. Check ntp's status:

    sudo ntpq -p
         remote           refid      st t when poll reach   delay   offset  jitter
    ==============================================================================    .POOL.          16 p    -   64    0    0.000    0.000   0.000
    *lithium.constan      2 u    -   64    1   19.900    4.894   3.951    2 u    2   64    1   48.061   -0.431   0.104

(Table of Contents)

Securing /proc


To quote

When looking in /proc you will discover a lot of files and directories. Many of them are just numbers, which represent the information about a particular process ID (PID). By default, Linux systems are deployed to allow all local users to see this all information. This includes process information from other users. This could include sensitive details that you may not want to share with other users. By applying some filesystem configuration tweaks, we can change this behavior and improve the security of the system.

Note: This may break on some systemd systems. Please see #37 for more information. Thanks to nlgranger for sharing.


  • /proc mounted with hidepid=2 so users can only see information about their processes