Close the remote access door on your own VM

short · 35 min · Objective 2.3

Task

Take the SSH service on your Linux guest -- the remote access route the lab already has -- and apply the lesson's controls to it: no password-guessing route, no direct root sign-in, reachable only from the lab subnet, and an alert when somebody signs in at an hour nobody works. Then prove each one from the outside as well as from the configuration.

Steps

  1. Record the starting point in /tmp/ssh-before.txt: the output of sudo sshd -T | grep -Ei '^(passwordauthentication|permitrootlogin|maxauthtries) ' and of sudo ss -ltnp | grep ':22 '.
  2. From the Windows guest, create a key pair with ssh-keygen and add the public key to ~/.ssh/authorized_keys for your account on the Linux guest. Confirm you can sign in with the key BEFORE changing anything else -- that ordering is what keeps you from locking yourself out.
  3. Create /etc/ssh/sshd_config.d/01-lab-hardening.conf containing PasswordAuthentication no, KbdInteractiveAuthentication no, PermitRootLogin no and MaxAuthTries 3. The 01- prefix matters: sshd keeps the FIRST value it reads, and some images ship a 50-cloud-init.conf that turns passwords back on. Check the syntax with sudo sshd -t, then sudo systemctl restart ssh.
  4. Restrict by source: allow TCP 22 only from the lab subnet with sudo ufw allow from 10.99.0.0/24 to any port 22 proto tcp, remove any broader rule for 22, and sudo ufw enable.
  5. Write /tmp/odd-hours.sh: read /var/log/auth.log and print every Accepted sign-in whose hour falls outside 07:00-19:00, with its source address, ending with a line odd-hour logins: N. Make the working hours a variable at the top, and narrow them briefly so your own sign-in from the Windows guest fires the alert once.
  6. Write /tmp/remote-access.md: one line per control naming the attack from the lesson it closes -- guessed passwords, reuse of a stolen password, exposure to every scanner, use nobody noticed -- and what you would add in production, where MFA belongs on the gateway or VPN in front.

Verify

sudo sshd -T | grep -Ei '^(passwordauthentication|permitrootlogin|maxauthtries) '
ssh -o BatchMode=yes -o StrictHostKeyChecking=accept-new -o PubkeyAuthentication=no localhost true 2>&1 | grep -cF "Permission denied (publickey)."
python3 - <<'PY'
import subprocess
out = subprocess.run(['sudo', 'ufw', 'status'], capture_output=True, text=True).stdout
rules = [l for l in out.splitlines() if l.startswith(('22', 'OpenSSH', 'Anywhere'))]
print('\n'.join(rules))
assert 'Status: active' in out, 'the host firewall is not enabled'
assert rules, 'no rule mentions port 22'
assert all('10.99.0.0/24' in l for l in rules), 'port 22 is allowed from somewhere other than the lab subnet'
print('ssh reachable from the lab subnet only')
PY
bash /tmp/odd-hours.sh | tail -1

The first must show passwordauthentication no, permitrootlogin no and maxauthtries 3 -- the values sshd will actually use, not the lines in a file. The second must print 1: when password authentication is still on, the refusal lists publickey,password, so this line only matches once the password route is genuinely gone. The assertion requires the firewall to be active with every rule that could admit SSH -- by port, by the OpenSSH app profile, or an allow-everything line -- limited to the lab subnet. The last line must report at least one odd-hour login from your test.

Notes

Remote desktop and VNC follow the same pattern, with one addition: never expose them directly at all, and put them behind a gateway or VPN. The odd-hours alert is the cheapest detection in this course and catches the attacker who already holds a working key -- which no configuration line in this lab can stop.

This is an independent study companion for CompTIA Security+ SY0-801 and is not produced by or endorsed by CompTIA.