Networking / Stage 10 of 14 · step 8 of 9

Keep only the authorized SSH access

~25 min

Not running Starting usually ~20 s

Situation

A separate practice SSH server runs on this machine — the lab-sshd.service unit. It listens on 127.0.0.1:2222 and reads its own settings file, /srv/ssh-lab/sshd_config; the system sshd has nothing to do with it. The service account deploy logs in through it with a key: the client is set up in ~/ssh-lab/config, and the login is ssh -F ~/ssh-lab/config training.

A security review found that the server lets in too many: with a password, through server questions and even as root.

Task

The server lets people in with a key alone: neither a password nor server questions get anyone in.
Root does not log in to this server — not even with the key that worked before — and the server offers no password.
The new settings are in force: lab-sshd.service was restarted after the edit.
deploy logs in with a fresh connection: ssh -F ~/ssh-lab/config training id -un prints deploy.
Everything else is untouched: the other settings lines, the keys, the files in ~/ssh-lab and the system SSH.

Constraints

Edit values in /srv/ssh-lab/sshd_config as plain lines, without Include or Match.
Restart only lab-sshd.service; leave the system ssh.service and /etc/ssh alone.

The tools you need are already installed. There's no internet on this machine.

Lab goals

0 of 5

Password, keyboard-interactive and root are denied; key-only access — not checked yet
The fixed configuration runs in a new lab-sshd start — not checked yet
A fresh deploy login with the supplied key succeeds — not checked yet
Root with its previously working key is refused; no password is offered — not checked yet
Other settings, keys and the system SSH are untouched — 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.