How to Harden Linux Servers: Disable Root, Use Private Users, and Secure SSH

No Absolute Security

In the previous article we covered common SSH hardening and performance tweaks. SSH is the main entry point to a server; attackers may "break windows" by exploiting 0‑day or third‑party software vulnerabilities, or they may brute‑force passwords.

For brute‑force attacks we already covered mitigation. For vulnerability‑based attacks the simplest defence is to patch promptly, configure firewalls and anti‑virus, and, in large enterprises, add IDS, security gateways, bastion hosts, etc. However, no system can claim absolute security.

Attackers Target Root Privileges

When a vulnerability is disclosed, thousands of servers become exposed. Attackers first gain a foothold, then aim for the highest privilege—root (UID 0). Gaining root on Linux also compromises Android devices, which share the same kernel.

Defence Techniques

1. Disable root login

Root login can be disabled in two places: the SSH daemon configuration and the su command. For SSH, edit /etc/ssh/sshd_config to set PermitRootLogin no. For su, either prohibit its use or restrict it to local console.

Two practical approaches are:

Completely disable root login and use sudo for privileged tasks.

Allow su locally but forbid remote root logins.

Using sudo lets ordinary users execute commands with root privileges after being listed in /etc/sudoers:

Typical sudoers entry format:

This grants specific users the ability to run selected commands as root, reducing the attack surface.

2. Edit /etc/shadow to lock root

Prepend !! to the second field of the root entry in /etc/shadow to disable the account:

The /etc/shadow file stores password hashes and aging information; each field is colon‑separated (password, last change, min/max days, warnings, etc.).

3. Create private service users

Assign each service (e.g., nginx, apache, mariadb) its own low‑privilege user and group. Use UID 100‑999 for service users, matching GID to UID. Create the group first:

Then create the user with

useradd -g <gid> -u <uid> -d <home> -s /sbin/nologin <username>

:

4. Set directory permissions for private users

Restrict access to service directories so that only the dedicated user can read/write. Example for nginx:

Ensure parent directories are owned by root and have 700 permissions.

Set /srv/nginx, /data/config/nginx_config, and /data/var/nginx to appropriate ownership and 750 / 700 modes.

To allow nginx to bind to port 80 (a privileged port), either grant the binary the capability CAP_NET_BIND_SERVICE or use sudoers to allow the nginx user to run the binary as root.

5. Remove unused users and groups

Unused accounts are potential privilege‑escalation vectors. Delete them with userdel and groupdel after ensuring no processes rely on them. Common candidates include: adm, lp, sync, shutdown, halt, news, uucp, operator, games, gopher, and their corresponding groups.

By carefully configuring root restrictions, sudo policies, private service users, directory permissions, and by cleaning up obsolete accounts, a Linux server can achieve a much higher security posture, even though absolute security remains unattainable.