A server ready for publication

~60 min

Not running Starting usually ~20 s

Situation

node1 is a new ticket server, helpdesk: nginx on port 80 with the application behind it — the lab-helpdesk service. The server is about to go public, but the security review sent it back with a list of findings:

SSH logins are accepted by password;
root is allowed to log in to the server;
extra ports besides the site are visible from the network;
there is no protection against password brute force;
the application service runs as root with no restrictions at all.

node1 is your terminal. node2 is the administrator's workstation on the same network; logins to node1 happen from there by key. Run commands on node2 over SSH: ssh node2 'command', or enter its shell with ssh node2 and leave with exit. sudo works without a password on both machines. There is no other way into node2: do not lock yourself out of SSH and do not touch its settings.

Task

SSH login to node1 is key-only: the student account logs in from node2 with its key, and the server no longer offers a password.
Root cannot log in to node1 over SSH — not even with a key that worked before — and no password is offered to it.
Only ports 22 and 80 are open on node1 from the network; ports 8000 and 8080 are closed. The rules stay in place after a reboot of node1.
SSH password brute force is caught: fail2ban is running, starts on its own and watches logins — the sshd jail is active and able to ban.
The lab-helpdesk service runs as non-root and is confined with systemd (at least NoNewPrivileges and ProtectSystem), so that systemd-analyze security lab-helpdesk.service scores below 6.0. The site still answers, though: curl http://localhost/ on node1 returns the ticket list.

Constraints

Change node1 only. Do not touch SSH settings, keys or services on node2.
Firewall rules and service settings must survive a reboot: keep them in files (/etc/...): the live state does not survive a reboot.
The administrator's key access from node2 must stay — both for student and after every change.

The lab has no internet — only the network between node1 and node2, and everything you need is installed. Work through the list of findings: which ports services listen on — sudo ss -tlnp; what is visible from node2 — check it right from there. After each change, re-read the state: sudo systemd-analyze security lab-helpdesk.service, sudo fail2ban-client status sshd, sudo nft list ruleset.

Lab goals

0 of 5

From node2 the login to node1 is key-only (student logs in with the key; the server offers no password) — not checked yet
Root cannot log in to node1 over SSH even with a previously working key, and no password is offered — not checked yet
From node2 only ports 22 and 80 are open on node1 while 8000 and 8080 are closed — and the rules survive a reboot — not checked yet
fail2ban is running, starts on its own and watches SSH logins — the sshd jail is active with a ban action — not checked yet
The lab-helpdesk service answers, runs as non-root and is confined (NoNewPrivileges, ProtectSystem); systemd-analyze security is below the threshold — not checked yet

Hints

0 of 3 open · they open one at a time

Hint 1

Show the solution after 3 failed checks

Security · picked for this lab

sshd — the SSH server

Cheat sheet

$_ — insert into the terminal

sudo sshd -t check config syntax
sudo sshd -T | grep -i permitroot the effective value of a parameter
sudo systemctl reload ssh apply without dropping sessions
ss -tlnp | grep :22 is the port listening
journalctl -u ssh -f connection logs in real time

The main config is /etc/ssh/sshd_config (plus snippets in /etc/ssh/sshd_config.d/). A safe baseline:

PermitRootLogin no
PasswordAuthentication no         # keys only
PubkeyAuthentication yes
Port 22

Apply changes safely (without dropping the current session):

bash

sudo sshd -t                      # check the config syntax
sudo sshd -T | grep -i permitroot # show the EFFECTIVE values (important!)
sudo systemctl reload ssh         # apply (the ssh unit)

Important. When editing the SSH config remotely, keep a second session open — that way a mistake won't lock you out of the server. A safety net with an auto-rollback timer: sudo sh -c 'sleep 300 && systemctl restart ssh' &.

Hardening

Parameter	Why
`PermitRootLogin no`	don't allow root to log in directly
`PasswordAuthentication no`	keys only (the main defense against brute force)
`MaxAuthTries 3`	fewer attempts per connection
`AllowUsers alice bob`	a user whitelist
`AllowGroups sshusers`	a group whitelist
`AllowTcpForwarding no`	disable tunnels (if not needed)
`X11Forwarding no`	disable X forwarding
`ClientAliveInterval 300`	disconnect dead sessions

Fine-grained control through Match (by group/address):

Match Group sftponly
    ChrootDirectory %h
    ForceCommand internal-sftp
    AllowTcpForwarding no

Commands

bash

systemctl status ssh              # server state
sshd -t                           # check sshd_config (syntax)
sudo sshd -T                      # effective configuration (all parameters)
ss -tlnp | grep :22               # is the port listening
journalctl -u ssh -f              # connection/rejection logs
journalctl -u ssh | grep -i fail  # failed logins (brute force? see fail2ban)
ssh -v user@host                  # connection debugging from the client

Permission denied (publickey)

Permissions on the server: ~/.ssh=700, authorized_keys=600, owner is the user itself. journalctl -u ssh → often "Authentication refused: bad ownership or modes". See ssh-keys.

Connection refused

The server isn't listening on the port: ss -tlnp | grep :22, systemctl status ssh. Or the port is closed by the firewall — allow 22/tcp (see firewall).

Connection timed out

A network/firewall-level issue (never reached sshd): route, security group, nftables. Check with nc -zv host 22.

Changed the port — can't connect

SELinux/the port isn't allowed, the firewall is still on the old port, or the client is connecting to 22. Open the new port in firewall, check sshd -T | grep -i port.

Locked yourself out with a config change

Get in through the hypervisor console/serial and roll back sshd_config (or sshd -t would have shown the error before reload — always check).

reload/restart apply the new config to every subsequent connection immediately; a mistake in PermitRootLogin, AllowUsers, or PasswordAuthentication can lock out everyone, including you. Edit the config only with a second session open, and check sshd -t before restarting, not after. Disabling PasswordAuthentication without a tested key already installed leaves the server with no working way to log in at all.