# I left a Linux security guide half-finished for months — Copilot helped me wrap it up

> Source: <https://dev.to/mmvonnseek/i-left-a-linux-security-guide-half-finished-for-months-copilot-helped-me-wrap-it-up-13hh>
> Published: 2026-05-28 23:27:04+00:00

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](https://github.com/MMVonnSeek/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.

Three fronts:

**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](https://github.com/MMVonnSeek/linux-security-guide)

Created and maintained by Professor Max — SENAI Taguatinga, Brazil.