Linux Server Configuration and Hardening

Why Server Hardening Matters

When you provision a fresh VPS, it arrives with reasonable defaults—but not secure ones. The root account is usually enabled for SSH, all ports may be reachable, and automatic security patching is often off. Attackers run automated scanners around the clock looking for exactly these conditions. Hardening is the process of reducing a system's attack surface by removing or restricting anything that is not required. This lesson walks you through three baseline steps every Linux administrator performs before a server is considered production-ready.

Securing SSH with sshd_config

SSH (Secure Shell) is the primary remote-access protocol for Linux servers. Its behavior is controlled by `/etc/ssh/sshd_config`. Two settings must be changed immediately on any new server.

PermitRootLogin no — The root account has unrestricted system access. Allowing direct root login over SSH gives an attacker a known username to target. Setting this to `no` forces all users to log in as a named, limited account and escalate privilege with `sudo` only when needed. This creates an audit trail and limits blast radius if credentials are stolen.

PasswordAuthentication no — Passwords can be guessed or brute-forced. Key-based authentication uses a cryptographic key pair: you keep the private key, the server holds the public key. Without the private key file, a password guess is useless. Disabling password authentication entirely eliminates brute-force as an attack vector. Important: confirm your SSH key is installed and working before you disable password auth, or you will lock yourself out of the server.

After editing the file, restart the SSH service with `sudo systemctl restart ssh` (Ubuntu uses the service name `ssh`). Verify the settings loaded by running `sudo sshd -T | grep -E 'permitrootlogin|passwordauthentication'`. The `-T` flag prints the effective configuration after parsing.

Configuring UFW (Uncomplicated Firewall)

UFW is a front-end for iptables included in Ubuntu. It lets you manage firewall rules in plain English rather than raw iptables syntax. A properly configured firewall is the single most effective control for reducing network exposure.

The correct approach is default deny inbound, allow only what is needed. For a typical web server you need three ports:

• 22/tcp — SSH remote management
• 80/tcp — HTTP web traffic
• 443/tcp — HTTPS web traffic

All other inbound connections should be dropped silently. UFW also maintains a default allow-outbound rule so your server can reach package repositories and external APIs without extra configuration.

Always add the SSH rule before enabling the firewall. Enabling UFW with default-deny and no SSH rule will immediately cut your remote session.

After enabling UFW, run `sudo ufw status verbose`. This displays each rule, the policy for incoming and outgoing traffic, and whether the firewall is active. Read this output carefully and compare it to your intended rule set before moving on.

Enabling Automatic Security Updates

Even a perfectly hardened server becomes vulnerable the moment a known CVE (Common Vulnerability and Exposure) is published for installed software. The `unattended-upgrades` package applies security patches automatically on a schedule, closing that window without requiring manual intervention every day.

On Ubuntu, install and configure it with `sudo apt install unattended-upgrades` and then `sudo dpkg-reconfigure -plow unattended-upgrades`. The main configuration file is `/etc/apt/apt.conf.d/50unattended-upgrades`. Open it and review the `Allowed-Origins` section: it controls which package repositories are eligible for automatic updates. The default includes the Ubuntu security pocket (`${distro_id}:${distro_codename}-security`), which is exactly what you want. Leave the full distribution upgrade lines commented out to avoid unexpected major changes.

You can trigger a dry run with `sudo unattended-upgrades --dry-run --debug` to confirm the service is configured correctly without actually installing anything.

Documenting Your Work

The lab log is not busywork. In a real environment, a change log is a legal and operational requirement. Record every command you ran, the before-and-after state of each configuration file, and the output of verification commands. Your instructor will review the log alongside a live port scan to confirm the technical controls are in place.

Safety and Professional Considerations

While this is software work with no electrical hazard, there are operational safety rules:

• Never test hardening steps on a production system without a maintenance window and a rollback plan.
• Keep a console or out-of-band access method (such as your VPS provider's web console) available any time you edit SSH or firewall settings. If you lock yourself out over SSH, console access lets you recover without destroying the server.
• Do not share private keys. Treat them like passwords: never commit them to a public repository or paste them into a chat.
• Document before you change. Copy the original config file with `sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak` before editing.

Following these practices is what separates a careful professional from someone who causes an outage.