Securing your Linux server: the 10 commandments

In short: As of September 5, 2026, secure SSH with keys first, refuse root login, expose only required ports, automate security patches, and test a backup stored away from the server. My recommendation is firm: do not put a service into production until these five controls are verified and an actionable alert is configured.

This detailed checklist is an operational deployment plan for a Debian or Ubuntu server. It complements a general hardening guide by showing the commands, checks, and decisions to adapt before production.

1. How do you secure SSH authentication with keys?

SSH is commonly the remote administration path to your server. One of the first controls is to disable passwords after validating key-based authentication.

# Generate an Ed25519 key pair
ssh-keygen -t ed25519 -C "[email protected]"

# Copy the public key to your server
ssh-copy-id -i ~/.ssh/id_ed25519.pub user@your-server

Then edit /etc/ssh/sshd_config:

PasswordAuthentication no
KbdInteractiveAuthentication no
PubkeyAuthentication yes

The official OpenSSH documentation describes these directives. Before disabling passwords, open a second session and confirm that your key works so you do not lock yourself out.

2. Should you change the default SSH port?

Port 22 often receives automated scans. Moving SSH to a non-standard port can reduce log noise, but it is not a security control on its own.

# /etc/ssh/sshd_config
Port 2222

This measure does not stop an attacker who discovers the new port. Treat it only as a way to reduce automated noise, alongside effective security controls.

3. Why should you disable root login?

The root account has full privileges and a predictable name. Disable direct root login over SSH:

# /etc/ssh/sshd_config
PermitRootLogin no

Use a dedicated user with sudo privileges for administration tasks:

# Create a dedicated user
adduser admin
usermod -aG sudo admin

4. How do you limit exposed ports with UFW?

A host firewall is essential when the server is exposed. On Ubuntu, UFW provides a simple interface for configuring network filtering:

# Default policy: block all incoming
sudo ufw default deny incoming
sudo ufw default allow outgoing

# Allow only necessary ports
sudo ufw allow 2222/tcp
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp

# Enable the firewall
sudo ufw enable
sudo ufw status verbose

The golden rule: only allow what you explicitly need. Everything else should be blocked.

5. How do you block repeated attempts with Fail2Ban?

Fail2Ban monitors connection logs and automatically bans IP addresses that accumulate failed login attempts:

sudo apt install fail2ban -y

Create a local configuration in /etc/fail2ban/jail.local:

[DEFAULT]
bantime = 3600
findtime = 600
maxretry = 3

[sshd]
enabled = true
port = 2222
filter = sshd
logpath = /var/log/auth.log
maxretry = 3

These values are an example, not universal settings. Adapt the port, backend, and log source to your distribution, then test the configuration before relying on bans.

Restart the service and check active bans:

sudo systemctl restart fail2ban
sudo fail2ban-client status sshd

6. How do you keep security patches up to date?

Security updates reduce exposure to vulnerabilities that have already been fixed. On Debian or Ubuntu:

# Manual update
sudo apt update && sudo apt upgrade -y

# Configure automatic security updates
sudo apt install unattended-upgrades -y
sudo dpkg-reconfigure -plow unattended-upgrades

On Debian, check the configuration and logs for unattended-upgrades: the package may be missing or disabled, and some updates can require services or the server to restart.

7. How do you prepare restorable backups?

No security strategy is complete without a restorable backup. Keep several copies on separate storage, including one away from the server and inaccessible with the same credentials.

For a typical web server, an automated backup script might look like:

#!/bin/bash
# backup.sh - Daily backup
BACKUP_DIR="/backup/$(date +%Y-%m-%d)"
mkdir -p "$BACKUP_DIR"

# Back up website files
tar -czf "$BACKUP_DIR/site.tar.gz" /var/www/

# Back up databases
mysqldump --all-databases | gzip > "$BACKUP_DIR/databases.sql.gz"

# Rotation: keep last 30 days
find /backup -type d -mtime +30 -exec rm -rf {} +

# Sync to remote storage
rsync -avz /backup/ user@backup-server:/backups/

Schedule the job, monitor its errors, and regularly test a restoration. An archive whose restoration has never been verified is not a reliable recovery plan.

8. How do you detect an anomaly on the server?

Monitoring helps you detect an outage or unusual behavior quickly. Start with simple checks:

For the system:

# Monitor resources in real-time
htop

# Analyze disk space
df -h

# Check active processes
ps aux --sort=-%mem | head -20

For security logs:

# Recent failed login attempts
sudo grep "Failed password" /var/log/auth.log | tail -20

# Currently logged-in users
who
last

For continuous monitoring, choose a tool that can send alerts to a channel someone actually watches. Prometheus and Grafana suit a self-hosted stack; UptimeRobot or Sentry address different needs. The thresholds, recipients, and response procedures matter more than the product name.

9. How do you apply least privilege to files?

Poor file permissions are an open door for attackers. Apply the principle of least privilege:

# SSH configuration file permissions
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys

# Web file permissions
sudo chown -R www-data:www-data /var/www/
sudo find /var/www/ -type d -exec chmod 755 {} \;
sudo find /var/www/ -type f -exec chmod 644 {} \;

# Restrict access to sensitive files
chmod 600 /etc/shadow
chmod 644 /etc/passwd

10. Which services and ports should you close?

Every active service can add components to maintain or a port to protect. Inventory what is actually running and disable only what your server does not need:

# List active services
systemctl list-units --type=service --state=running

# Disable an unnecessary service
sudo systemctl disable --now bluetooth
sudo systemctl disable --now avahi-daemon

Also check open ports:

sudo ss -tlnp

Conclusion

This checklist focuses on production deployment and daily operations: administrative access, filtering, patches, backups, and alerts. It does not replace an audit of the application, cloud provider, secrets, containers, or regulatory duties.

If nobody can explain who receives an alert, how data is restored, and when patches are applied, the server is not ready. Address these issues before an incident, and seek expert help when the business impact exceeds what you can test alone.

Sources

• Official OpenSSH server configuration manual, accessed September 5, 2026.
• Ubuntu documentation for firewalls and UFW, accessed September 5, 2026.
• Debian documentation for periodic updates, accessed September 5, 2026.
• Debian manual for fail2ban-client, accessed September 5, 2026.
• NIST contingency planning guide, accessed September 5, 2026.
• Official systemctl manual, accessed September 5, 2026.