Before I step away for a while, I spent one last day checking my home lab and my travel plans. It turned into a lesson I keep relearning: “done” is not the same as “verified.”
1. The config I edited wasn’t the config that was running
I set out to turn off password logins for SSH on my Debian desktop. I created a small hardening file in the drop-in folder, checked the syntax, reloaded the service… and SSH still said passwords were allowed.
The reason: a year ago I had replaced the whole main config with a custom “hardened” one, and it didn’t include the line that tells SSH to read the drop-in folder. My new file was being politely ignored.
The fix was easy once I found it. What found it was asking SSH for its live settings (sshd -T) instead of trusting the file I had just written.
Lesson: after any change, check what the system is actually doing, not what you told it to do.
2. A baseline is only useful if you know what’s in it
I also built a fresh AIDE file-integrity baseline, so I can tell what changed on the desktop while I’m gone. The first attempt ran for over nine hours, because it was fingerprinting every build file in my home folder. I stopped it, added exclusions, and ran it again. Then I tested my test: one search showed the home folder was excluded, and another search showed the search itself actually worked.
Lesson: if a check comes back “zero,” make sure zero isn’t just a broken search.
3. “He fixed it” — except he didn’t
The real-world version of this came from my airline booking. My date of birth had been wrong for weeks. I finally called. The agent said he’d corrected it and the website would update in fifteen minutes.
An hour later it still showed the wrong date. I called back with that evidence, and the second agent found the problem: the first agent had added the correct date but never removed the wrong one. She deleted everything and entered it fresh.
Lesson: a confident “it’s fixed” is a claim. The system’s own display is the evidence.
4. Even the phone number can be an attack
When I searched online for the airline’s phone number, almost every result was a fake “customer service” PDF planted on government and university websites. It’s a known trick called SEO poisoning: attackers hide scam numbers on trusted domains so they rank well. The real number came from the airline’s own help page, reached from inside my booking.
Lesson: get contact information from the source, never from a search result.
5. Patch day happens when it happens
That same morning, Tails released an emergency update for compromised certificates, the kind of flaw that matters most on hotel and café Wi-Fi. My USB stick was a month out of date. One slow download over Tor later, it was current.
Lesson: update before you travel, not on the road.
6. Test the way you’ll actually use it
Finally, I tested remote access the way I’ll really need it: laptop → phone hotspot → private network → home desktop. It failed until I found the cause. My iPhone’s Wi-Fi switch was off, so the hotspot only worked for my own Apple devices. One switch later, the whole chain worked.
Lesson: a test that doesn’t match real conditions is a demo, not a test.
The common thread
None of these were hard problems. Each one looked finished until I checked. That’s most of security: not clever exploits, just patient verification.
That’s one for the road. See you when I’m back.
— Dennis