I left a Linux security guide half-finished for months — Copilot helped me wrap it up (and taught me something I didn't expect)

The project that sat there collecting dust

What I added with Copilot

The moment I didn't expect

What I had to fix

What changed in the project

Repository GitHub “Finish-Up-A-Thon” Challenge Submission I'm a teacher at SENAI in Taguatinga, Brazil. I teach Systems Development and Fullstack. A few months ago I created the linux-security-guide — a practical Linux guide focused on security, born directly from my classroom. The reason I started it was simple and honest: I was tired of 2-hour YouTube videos teaching things wrong, and course materials that just make students memorize commands. I had about 15 students fail job interviews because they couldn't answer "how do you secure a Linux server in practice?" — and that made me angry. So I put together everything I teach in class and use day-to-day so nobody would go through the same frustration I went through when I started. The project grew well. Fundamentals, networking, hardening, practical labs. But at some point it stopped. It just sat there with a nice structure, half-finished modules, and labs that didn't show students what they should actually see in the terminal. This challenge was the push I needed. 1. Lab 04 — Suspicious process detection This lab didn't exist. I knew what I wanted: something practical, with real commands (ps, top, lsof, netstat, /proc), defensive focus, and expected output for each step. I gave Copilot the context and it put together a solid structure I wouldn't have written that quickly on my own. I still had to review every block — the technical content was correct, but some sections needed the adjustment of someone who's actually worked with this in a classroom. 2. Automated hardening script Module 03 of the guide teaches secure SSH, auditd, suspicious crontab. But there was no script to automate all of that. Copilot generated a hardening.sh with dependency checking, automatic backup of files it modifies, logging everything to /var/log/hardening.log, and decent error handling. Good enough to show students as a production script example. 3. Expected output in existing labs The three existing labs had the commands but didn't show what students should see after running them. That sounds like a detail, but it isn't — beginner students get stuck exactly because they don't know if what appeared in the terminal is right or wrong. I used Copilot to review each lab and add those output examples. Repetitive work I always kept putting off. While working on the suspicious crontab module (03-hardening/crontab-suspeito.md), I was listing the basic commands to check scheduled tasks. Standard stuff. Copilot suggested creating a lab where the student finds a cron job running a hidden script at /var/tmp/.cache/.systemd-fix.sh and has to trace where it came from. I laughed out loud. Because that's exactly the kind of dirty trick an attacker would use in the real world. A name that looks legitimate, a hidden directory inside /var/tmp, a path that slips past a quick listing. I wouldn't have thought of that level of "dirty detail" on my own — at least not at that moment. It was smart because it helped me turn a boring "look at the crontab" lesson into a treasure hunt that students loved. Copilot is useful, but stubborn like a student who thinks they know everything. In the SSH hardening lab (lab-03-ssh-hardening.md), it generated a correct command to disable password authentication — it put PasswordAuthentication no just fine. But it forgot to mention ChallengeResponseAuthentication. If a student followed only that, the server would still accept some older authentication methods. A guaranteed vulnerability. I had to add three more configuration lines and an explicit warning in the text. Copilot helps, but it doesn't replace someone who's already been burned trying to fix a server at 3am. Before: organized structure, incomplete content, labs with no visual feedback for whoever runs them. After: new lab on process detection, functional hardening script, and existing labs with expected output at each step. The guide still isn't perfect. But now it's in a state where I can recommend it to a student without having to apologize for any unfinished part. github.com/MMVonnSeek/linux-security-guide Created and maintained by Professor Max — SENAI Taguatinga, Brazil. Templates let you quickly answer FAQs or store snippets for re-use. Are you sure you want to ? It will become hidden in your post, but will still be visible via the comment's permalink. as well , this person and/or