Will hardening break my applications?

It can if you remove something they need. Change one thing at a time, test after each change, and keep console access and snapshots so you can recover.

Is changing the SSH port worth it?

It reduces log noise but is not real security, because scanners find any port. Key authentication, patching, and a firewall provide the actual protection.

Linux Server Hardening Essentials

Introduction

Hardening means removing what is not needed and tightening what remains. A new server exposed to the internet is probed within minutes, so the basics matter. This lesson uses Ubuntu or Debian commands on a server you own, and practicing on a lab VM first is a good idea because a mistake can lock you out.

Prerequisites

Basic Linux command line
A Linux VM or server you control, with console access as a safety net

Step-by-Step Guide

Step 1: Keep the system patched

Most successful attacks use known vulnerabilities with available fixes. Update regularly and enable automatic security updates so critical patches are not forgotten. Remove software you do not use, because every package is more attack surface.

sudo apt update && sudo apt upgrade -y
sudo apt install -y unattended-upgrades
sudo dpkg-reconfigure --priority=low unattended-upgrades

Step 2: Use accounts and sudo properly

Create a named administrative user, use sudo for privileged commands, and avoid logging in as root. Give each person their own account so actions are traceable. Remove or lock accounts that are no longer needed, and follow least privilege for service accounts, which should run with no login shell and only the permissions they need.

sudo adduser deploy
sudo usermod -aG sudo deploy

Step 3: Switch SSH to keys and disable root login

Create an SSH key pair on your own machine, copy the public key to the server, and confirm that key login works in a second terminal before changing anything. Then disable password and root logins. Always validate the configuration before restarting, and keep your existing session open until the new login is confirmed.

# on your own machine
ssh-keygen -t ed25519
ssh-copy-id deploy@your-server

# on the server: edit /etc/ssh/sshd_config
PasswordAuthentication no
PermitRootLogin no
PubkeyAuthentication yes

sudo sshd -t && sudo systemctl restart ssh

Step 4: Enable a host firewall

Default to denying inbound traffic and open only the ports the server must expose. Allow SSH before enabling the firewall, or you will lock yourself out. Check the rules afterward.

sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow 22/tcp
sudo ufw allow 443/tcp
sudo ufw enable
sudo ufw status verbose

Step 5: Slow down brute-force attempts

Fail2ban watches log files and temporarily bans addresses that repeatedly fail authentication. With key-only SSH, brute force cannot succeed, but fail2ban still cuts log noise and protects other services. Put your settings in a local override file, not the packaged default file, so updates do not overwrite them.

sudo apt install -y fail2ban
# /etc/fail2ban/jail.local
[sshd]
enabled = true
maxretry = 5
bantime = 1h

sudo systemctl enable --now fail2ban
sudo fail2ban-client status sshd

Step 6: Audit and keep checking

Lynis is an open-source security auditing tool that scans a Linux system and reports warnings and suggestions with a hardening index. Treat the suggestions as input and not orders, because some do not fit your use. Repeat the audit after changes, log to a central place, and review which ports are listening.

sudo apt install -y lynis
sudo lynis audit system
sudo ss -tulpn          # what is listening, and which process owns it

FAQs

Will hardening break my applications?: It can if you remove something they need. Change one thing at a time, test after each change, and keep console access and snapshots so you can recover.
Is changing the SSH port worth it?: It reduces log noise but is not real security, because scanners find any port. Key authentication, patching, and a firewall provide the actual protection.

Summary

Patch automatically, use named users with sudo, require SSH keys and disable root login, run a deny-by-default firewall, add fail2ban, and audit with Lynis. Test each change so you do not lock yourself out.