Basic Security Hardening

In one line

A handful of specific, well-known hardening steps — disabling root SSH login, keeping software updated, and limiting exposed services — close off the most common ways a real server actually gets compromised.

0/5 · 0%

Think of it like this

Locking your front door, not leaving a spare key under the mat, and not propping a window open — none of these individually guarantees safety, but skipping any one of them is a genuinely common, well-known way break-ins actually happen. Server hardening is the same idea: a handful of specific, well-understood steps that close off the most common attack paths.

Key ideas

01
Disabling ROOT SSH LOGIN (PermitRootLogin no in /etc/ssh/sshd_config) is one of the single most impactful hardening steps — attackers relentlessly scan the internet for servers still allowing direct root login, since compromising root grants complete control immediately. Requiring login as a regular user first (then sudo for anything privileged, Phase 1) adds a real, meaningful barrier.
02
Disabling PASSWORD authentication entirely (PasswordAuthentication no, Phase 4.4) in favor of SSH keys only removes an entire, extremely common attack category — automated brute-force password-guessing bots simply have nothing to try against a server that doesn't accept passwords at all. Doing this AFTER confirming key-based login already works is essential, exactly as flagged in Phase 4.
03
Keeping the system UPDATED (sudo apt update && sudo apt upgrade, run regularly — many production setups automate this for SECURITY updates specifically) closes known vulnerabilities that have already been publicly disclosed and patched. A large share of real-world breaches specifically exploit vulnerabilities that already had a fix available; the server just hadn't been updated yet.
04
Running services with the LEAST PRIVILEGE they actually need (Phase 1's dedicated non-root service users, revisited here) means that even if an application is somehow compromised, the damage an attacker can do is limited to whatever that specific, restricted user can access — not the entire system, which is exactly what running everything as root would expose.
05
Minimizing EXPOSED SURFACE (Phase 4.3's firewall default-deny, plus simply not installing or running services you don't actually need) is a genuinely underrated hardening step — every open port and every running service is a potential attack path, and the simplest, most reliable way to secure something is often for it to not be reachable or not exist on the machine at all.

In your stack

→
A Spring Boot service should run as a dedicated springapp user (Phase 1, Phase 3.4's systemd User= directive) rather than root, and its actuator/management endpoints (if enabled) should never be exposed on the same public port as the main application without deliberate, explicit access control — a genuinely common, easy-to-overlook exposure in real Spring Boot deployments.

Code & diagrams

ssh-hardening.shmarkdown

Only apply after confirming key-based SSH login already works, per Phase 4.4.

# Edit the SSH server config
sudo nano /etc/ssh/sshd_config

# Set (or confirm) these two lines:
#   PermitRootLogin no
#   PasswordAuthentication no

# Restart SSH to apply the new config (Phase 3's systemctl)
sudo systemctl restart sshd

# Confirm you can STILL log in with your key from a NEW terminal
# BEFORE closing your current session — this is the critical safety check
ssh myserver

hardening-checklist.shmarkdown

A quick, practical audit sequence combining earlier phases.

# Is the system up to date?
sudo apt update && sudo apt list --upgradable

# Is the firewall active and minimal? (Phase 4.3)
sudo ufw status verbose

# What's actually listening on the network? (Phase 4.2)
ss -tulpn

# Is my app running as a dedicated user, not root? (Phase 1, Phase 3.4)
ps aux | grep myapp

# Is root SSH login disabled?
grep "^PermitRootLogin" /etc/ssh/sshd_config

Explain it without notes

Why is disabling root SSH login considered one of the single highest-impact hardening steps a server admin can take?

Why must you always confirm SSH key login works BEFORE disabling password authentication, and confirm it still works from a new session BEFORE closing your current one when changing SSH config?

Practice

On a genuinely disposable test VM (never a server you depend on), practice the full sequence: confirm key-based login works, disable password authentication, restart SSH, and verify you can still log in from a fresh terminal.

Audit a real server you have access to using the hardening-checklist commands above and note anything that doesn't match the recommended state.

Trade-offs

↔
Hardening steps add real friction (you genuinely can't just SSH in as root anymore, even in a hurry during an emergency) in exchange for meaningfully reduced risk — this trade is well worth making for anything internet-facing or handling real data, though a purely internal, already-isolated test environment might reasonably accept a lighter security posture in exchange for faster iteration, as long as that trade-off is a deliberate choice rather than an oversight.

Done when you can

I understand why disabling root SSH login and password authentication are high-impact hardening steps.
I know to verify SSH changes from a new session before closing my current one.
I can run a basic security audit combining firewall status, listening ports, and process ownership checks.

Command Palette