Doors that open by themselves

curl -O https://arunnetworkingpro.com/labs/breakroom-mission-05.sh
sudo bash breakroom-mission-05.sh

sudo bash breakroom-mission-05.sh --check

nc -w 3 10.66.6.6 31337

ssh -p 2222 -o PubkeyAuthentication=no caretaker@10.66.6.6

ssh-keygen -t ed25519 -f ~/.ssh/breakroom_ed25519 -N ''
sudo tee -a /home/caretaker/.ssh/authorized_keys < ~/.ssh/breakroom_ed25519.pub
ssh -i ~/.ssh/breakroom_ed25519 -p 2222 caretaker@10.66.6.6 whoami

sudo bash breakroom-mission-05.sh

🧠 The ghost, explained

Verdict: not a ghost. Every open door was a program listening on a port, every "resurrection" was a timer, and every way in was a line in a config file.

An open port is just a program listening. ss -tlnp shows every listener, its address, and the process behind it. Give the PID to systemctl status and it tells you which service owns it. That's how you go from "what is this?" to "who put it there?".

Things that come back from the dead have a reason. disable --now stops a service and stops it starting at boot, but anything can still start it on demand. Here it was a timer. On real servers it's timers, cron jobs, other services, or socket activation. systemctl list-timers is your first suspect. mask is the stake through the heart: nothing can start a masked unit.

Firewalls see the replies too. A rule that drops everything to an address also drops the answers coming back to it. That's why real rulesets start with ct state established,related accept: the firewall remembers conversations, so only the first knock of a new one gets judged.

Drop or reject? Drop is silence: the knocker waits and gives up, and learns nothing. Reject answers "go away" instantly. Drop suits the internet (give attackers nothing); reject is kinder inside your own network, where a fast "no" saves a colleague five confused minutes.

sshd config is where the doors really are. sshd -T prints the settings sshd will actually use, after defaults and includes, which is what you should audit rather than the file you think it reads. sshd -t checks a config before you restart, so a typo can't lock you out. And a restart is needed: a fixed file does nothing until sshd reads it.

authorized_keys is the guest list. Every line is a key that opens the door, no password asked. Old keys from people who left are one of the most common real-world holes. And StrictModes makes sshd ignore the whole list if anyone but the owner could edit it: that's why a 777 folder broke your login too.

Other families. Ubuntu's ufw and Red Hat's firewalld (firewall-cmd) both write nftables rules underneath, so what you learned here is what they do for you. On Red Hat, SELinux also stops sshd from listening on a non-standard port like 2222 until you label it with semanage port. That's a whole other ghost: Case 07.