We've built something new for you. A free Linux CTF game, and I've had more fun testing it than I'd like to admit.

A CTF (capture the flag) teaches you Linux by making you work for it. You get a locked-down system, a riddle, and a hidden flag (a string), and you have to use real commands to dig it out.

These challenges force you to think, employ your reasoning and logical skill along with your Linux command line skills.

While the entire CTF is played locally on your own system, your progress can be shown on a public leaderboard.

🚩 Command Conqueror: our free Linux CTF

It starts with hidden files and ends with a full SUID privilege escalation. Each level drops you into a small Linux system ruled by Lord Tuxi, who leaves you a riddle and hides a flag somewhere. You find it, submit it, and climb the leaderboard.

It's free, and you don't need an account to play. If you do link your Linux Handbook account, your progress saves across machines.

You need Docker and Python 3.7+ (WSL 2 on Windows), then:

curl -fsSLO https://ctf.linuxhandbook.com/play.py
python3 play.py

You don't need to know Docker or Python. The CTF runs with those two.

Pick a handle, choose Command Conqueror, and type play to start. The early levels are gentle if you've spent time in a terminal.

Play it here. There is a demo here that shows how to play the CTF.

Command Conqueror: Free Linux CTF Challenge

Ten Linux command line puzzles, from hidden files to SUID privilege escalation. Free, no account needed, runs in Docker on your computer.

Linux HandbookYash Kiran Patil

🎓 See who can do what

Level 10 of the CTF ends with privilege escalation, which sounds scarier than it is. Most of it comes down to one question: on this system, what can I actually do, and what can I do that I'm not supposed to?

A few commands answer that fast. ls -l shows the permission bits, and an s where you'd expect an x (like -rwsr-xr-x) is the SUID bit, meaning the file runs with its owner's privileges instead of yours. That's the first thing a CTF player, or an attacker, goes looking for.

To find every SUID binary on a box:

find / -perm -4000 -type f 2>/dev/null

From there, sudo -l lists exactly what your user is allowed to run as root, id shows the groups you're in, and getcap -r / 2>/dev/null shows binaries with special capabilities that ls won't show you.

It's the same audit you'd run on your own server to check nothing has more power than it should. If you want details, our guide on SUID, SGID and the sticky bit breaks down what those permission bits really mean.

💡 Quick terminal tip

Bash and zsh let you feed one command's output to another as if it were a file, using <(...). No temp files, no cleanup.

It's great for comparing two states. Say you want to see what differs between two directories, or two command outputs:

diff <(ls dir1) <(ls dir2)

This is called process substitution, and is pretty handy in bash scripts.

📦 Self-hosting: CyberChef

If the CTF throws a wall of base64 at you (level 5 will), this is what you want open in another tab. CyberChef is a browser-based, drag-and-drop toolkit for encoding, decoding, encryption, hashing and data parsing.

GitHub - gchq/CyberChef: The Cyber Swiss Army Knife - a web app for encryption, encoding, compression and data analysis

The Cyber Swiss Army Knife - a web app for encryption, encoding, compression and data analysis - gchq/CyberChef

GitHubgchq

🛠️ Tool discovery: gopass

gopass is a command-line password manager built for teams. It stores everything in GPG or age-encrypted files with git-backed version history, so your credentials live in a repo you control instead of someone else's cloud.

It works fully offline, which makes it a good fit for shared credentials across a distributed team or a CI/CD pipeline.

GitHub - gopasspw/gopass: The slightly more awesome standard unix password manager for teams

The slightly more awesome standard unix password manager for teams - gopasspw/gopass

GitHubgopasspw

📰 Linux news that matters

• A newly public exploit for a Linux kernel bug (CVE-2026-80521) lets attackers escape an Ubuntu container and get root on the host, and Ubuntu still hasn't shipped the patch.
• Canonical is merging its split kernel update tracks into a single 2-week SRU cycle that overlaps weekly, so Ubuntu kernel fixes ship faster, largely because AI-assisted vulnerability hunting is finding kernel bugs faster than the old process could keep up with.
• Portainer's Community Edition is being frozen on the 2.x line, while all new Kubernetes-first development goes exclusively into the closed-source Portainer 3.0.
• A Google engineer has posted a 46-patch RFC series for "Orphaned VMs," an early-stage Linux kernel mechanism that uses the Live Update Orchestrator to keep virtual machines executing on preserved physical CPUs while the host kernel reboots or applies updates.
• AWS has open-sourced Strands Harness, an agent runtime that bundles tools, context management, memory, and session handling on top of its Strands SDK. While it defaults to Amazon Bedrock, it works with Anthropic, OpenAI, Google, or local Ollama models, and AWS claiming 45% lower cost than Claude Code and Codex on benchmark tasks.
• Starting October 19, GitLab will enforce new tiered API rate limits by subscription plan, driven by surging traffic from AI coding agents, so teams running automated tools should authenticate their requests and watch for rate-limit warnings to avoid getting throttled.

😂 Geek humor

💌 Keep on loving Linux Handbook

This CTF is free and there will be more. It's the kind of thing our Pro members make possible. Pro gets you that plus every other course, all our eBooks, and every tutorial we've published.

Become a Pro member · Browse courses · eBooks

Missed the previous editions? You can access the newsletter archives.

I like reading your messages, so just hit reply and tell me how far you got in the CTF 😄

Command Conqueror is a capture-the-flag game with 10 levels of Linux command line puzzles. It starts with hidden files and ends with a privilege escalation.

Each level drops you into a small Linux system ruled by Lord Tuxi, who leaves you a riddle and hides a flag. Use real commands to find the flag, submit it and climb the leaderboard.

It's free, and you don't need an account to play. Although, you can link it with your Linux Handbook member account and have your progress saved across time and systems.

Quick start

You need Linux or macOS with Docker running, and Python 3.7 or newer. On Windows, use WSL 2.

Download the game and run it:

curl -fsSLO https://ctf.linuxhandbook.com/play.py
python3 play.py

Pick a handle, then choose Command Conqueror from the menu. Type play to enter the first level and start with:

cat hint.txt

When you find a flag (it looks like LHB{...}), copy it, type exit and submit it:

submit LHB{...}

If Docker complains about permissions, run sudo python3 play.py instead. For the full setup, the commands and the FAQ, see the main CTF page.

The levels

Here's what each level tests, without giving anything away.

That's 3,300 points in total. You solve the levels in order, and each one gives its points once.

The first few are friendly if you've used a terminal before. By level 8, you'll be chaining grep, awk and friends together. Level 10 starts you as an ordinary user and asks you to think like an attacker.

Leaderboard

The leaderboard updates live. Players with the same score are ranked by who got there first. A ✓ next to a handle means it's linked to a Linux Handbook account.

Tips

Read the hint more than once. Lord Tuxi likes wordplay, so read the verses closely, not just the words.

Look beyond the folder you start in. Many flags are elsewhere on the system, or held by something that's running.

If you break a level, type restart to get a fresh copy. It doesn't cost you anything.

Brush up on the skills

Stuck on a level? Rather than looking for a walkthrough, read up on the skill it tests. These tutorials cover everything you need.

• hidden files and ls -a
• find command
• quoting and special characters in file names
• tar and unzip
• cron jobs, base64
• ps, netstat/ss, curl with headers
• /proc and process environment
• grep, awk, tr
• hard links and inodes
• SUID permissions

Play fair

The flags are inside the Docker images on your computer, so you could dig them out instead of solving the puzzles. Please don't. You'd skip exactly the part that teaches you something.

And please don't post flags or full solutions. Share how you approached a level instead.

Think you know your way around the Linux command line? Prove it.

A capture-the-flag game, or CTF, hides a secret string somewhere in a system and challenges you to find it. It's a long-standing tradition in the security world.

Here, the idea is simpler: each game is a set of small Linux puzzles, and you solve them with the same commands you use every day.

There's no browser-based hand-holding and no multiple choice. You get a shell, a hint and a hidden flag. Find the flag, submit it and move on to the next level.

The games are free, and you don't need an account to play.

The games

Pick one and start. Each game page has its own quick start, so you can jump straight in.

How it works

Every level is a small Linux system that runs in a Docker container on your own computer. You get a real shell to poke around in, and it stays fast no matter how many people are playing.

A small program, play.py, handles everything else. It downloads one level at a time, starts it, opens a shell for you and sends your flags to the Linux Handbook server. The only things that leave your computer are your handle and the flags you submit.

What you need

You need Linux or macOS with Docker installed and running. On Windows, play inside WSL 2.

If you don't have Docker yet, follow the official install guide.

sudo apt install docker.io

You also need Python 3.7 or newer. It's already there on most Linux distributions, and the game needs nothing beyond Python's standard library.

Get the game

Download play.py :

curl -fsSLO https://ctf.linuxhandbook.com/play.py

And then run it:

python3 play.py

On the first run, you pick a handle. That's the name shown on the leaderboards. Then choose a game from the menu.

If Docker needs root on your system, use sudo python3 play.py. Or add yourself to the docker group so you don't need sudo:

sudo usermod -aG docker $USER

Log out and back in for the group change to apply.

How to play

Every game works the same way. Choose it from the menu, then type play to enter the level. Your first command inside should be:

cat hint.txt

The hint is a riddle. Every word in it matters. Flags look like LHB{...}. When you find one, copy it, type exit to leave the level and submit it:

submit LHB{...}

These are the commands you can use at the game prompt:

You play the levels in order, and each one gives its points once. Quit whenever you like. Run python3 play.py again later and you continue from the same level.

Your handle

There's no sign-up. The first time you play, play.py creates a random key for your computer and saves it in ~/.ctf_user. The server ties your handle to that key, so nobody else can play as you.

The catch is that your handle lives on that one computer. Lose the file or switch machines, and the handle stays behind. If you have a free Linux Handbook account, link your handle to it and you can play from anywhere.

Play fair

The levels run on your computer, and the flags are inside them. So yes, you could dig the flags out of the Docker images instead of solving anything.

I can't stop you, but you'd only be cheating yourself. The point is to learn something, and the fun is in that moment when the flag finally shows up in your terminal.

Please don't share flags or full solutions publicly. Talking about approaches is fine.

FAQs

Enjoy capturing the flags 🎏

There is a new addition to the Digest from this edition. There's a dedicated self-hosting section. Actually, it's a re-entry, as there used to be such a section earlier. Self-hosting is gaining even more popularity.

Docker compose has made things easier and then the privacy concern has made people aware. And thus the dedicated self-host section is back. Even if you do not self-host, at least you can discover some cool new tool.

Know your file before you open it

Everything is a file in Linux and you'd be surprised how much a file will tell you before you even open it. The trick is knowing which command to ask.

Start with the file command. It ignores the extension entirely and reads the actual contents to tell you what something really is. That download with no extension, or the .txt that's secretly a JPEG? Just run file on it:

file mysterious-file

Once you know what it is, stat fills in everything else: exact size, owner, permissions, and three separate timestamps for when the file was last read, when its contents changed, and when its metadata was last touched. Think of it as ls -l but for a specific file and with more details.

Then there's realpath, for when you're not even sure where the file is located. That's why the name "real path". It resolves every symlink and those .. in the path and gives you the real location of the file. Handy when you're inside a symlinked directory and a script keeps writing to the "wrong" place.

And if a file won't budge with a "resource busy" error, lsof shows you exactly which process is holding it open, so you know what to stop before trying again.

💡Quick terminal tip

The namei command breaks down a file path component by component to display the permissions of every ancestor directory.

namei -l </home/linuxhandbook/Projects/scripts.sh>

The above command will show the permission of each item in the path in a compact list.

This is especially useful when resolving unexplained "Permission Denied" errors where a file is readable, but a parent directory lacks execute (+x) access.

🎓 Make your Linux skills official

Either you are an expert or you are learning. But a certification is how you prove your skill to someone who's hiring.

Linux Foundation, the official organization behind the Linux project, offers numerous certification and training exams that hold value in the job market.

Their back-to-school sale is running until September 22. The LFCS, their Certified System Administrator exam, is the obvious pick if Linux is your day job. Bundle it with the LFS207 course and the price drops from $645 to $387.

Going for the more lucrative Kubernetes and DevOps instead? The CKA course-and-exam bundle is also $645 down to $387, and the full CKA + CKAD + CKS exam bundle goes from $1245 to $747.

There are two codes depending on what you pick. SEPT26BTS35 takes 35% off individual courses and certifications, and SEPT26BTS40 takes 40% off bundles and instructor-led courses.

If a cert has been sitting on your list for months (or years), take advantage of the discount. It closes on September 22.

📦 Self-hosting

Jotty is a self-hosted, file-based workspace for personal notes, checklists, and project tasks. There's no external database to run, it just reads and writes plain files, which makes backups and syncing easier. A good fit if Notion feels like overkill and you'd rather own the data.

GitHub - fccview/jotty at linuxhandbook.com

Lightweight but powerful alternative for managing your personal, file based, notes and checklists. - fccview/jotty

GitHubfccview

🛠️ Tool discovery

Lerd is an open-source local PHP dev environment inspired by Laravel Herd. It gives you a rootless, zero-Docker workflow on Linux, macOS, and WSL2. If you've been spinning up containers just to run a PHP project locally, try this lighter alternative.

GitHub - lerd-env/lerd: Open-source, Herd-like local PHP development environment for Linux and macOS. Automatic .test domains, per-project PHP/Node isolation, one-command TLS. Podman-native, rootless.

Open-source, Herd-like local PHP development environment for Linux and macOS. Automatic .test domains, per-project PHP/Node isolation, one-command TLS. Podman-native, rootless. - lerd-env/lerd

GitHublerd-env

📰 Linux news that matters

• An Italian logistics company in Bergamo successfully migrated its office operations from Windows to Kubuntu LTS, Nextcloud, and Mattermost, cutting recurring licensing fees and eliminating daily workstation slowdowns without disrupting freight operations.
• Vercel’s two-week, $1 million sandbox bug bounty challenge against its Firecracker microVMs received 1,285 submissions that breached no customer data, but exposed two upstream Linux kernel networking defects causing deterministic host crashes and host memory leaks.
• Canonical developers are proposing a dedicated linux-firmware-hwe package for Ubuntu LTS releases to decouple newer hardware enablement firmware from General Availability kernels, preventing driver regressions for users staying on older kernel baselines.
• The Open Secure AI Alliance has joined the Linux Foundation to establish neutral governance for open-source AI defense tools, opening an RFC on its SAFE initiative to standardize incident reporting.
• Sidero Labs has launched Talos Enterprise Linux, introducing a commercial tier with FIPS 140-3 builds, SBOMs, and regulatory compliance artifacts while keeping the core operating system fully open source under MPL-2.0.

😂 Geek humor

Actually, I do both ;)

💌 Keep on loving Linux Handbook

The GitOps course is nearly ready and lands next week, built on the Git basics course. Get your Pro membership now and you'll have it the moment it drops, plus unlimited access to our eBooks, courses, and every tutorial we've published.

Missed the previous editions? You can access the newsletter archives.

I like reading your messages, so just hit the reply button and share your thoughts 😄

Last week, we revealed the Free Tmux course. I am also working on creating roadmaps so that members can follow a dedicated learning path with all the resources we have created in the last 8 years.

Next week, we should have the GitOps course, focusing on ArgoCD. This will build upon the foundation of the Git basics course.

Essential Linux concept: diff

All that Git talk actually rests on a very old, very simple Linux idea. You compare two versions of something, and then you act on the difference.

That's exactly what the diff command does. You give it two files, and it tells you what you'd need to change in one to make it match the other. It's the same mental model your version control uses under the hood.

The output looks cryptic the first time you meet it, with things like 2c2, 3a4 and 5d5. Once you learn to read it, it makes complete sense. We explain the output line by line in this guide.

Here's the part most of us forget: diff isn't limited to single files. With diff -r you can compare two entire directories and spot exactly how two config folders drifted apart. And if you find yourself creating temporary files just to compare two command outputs, process substitution lets you do it in one line: diff <(command1) <(command2).

💡Quick terminal tip

Using history expansions like !$ (last argument) or !! (entire previous command) can feel like a gamble when running destructive operations. You only see what it resolved to after you have pressed the Enter key.

Bind Readline's magic-space to expand history references instantly as soon as you press the Spacebar:

Open the ~/.inputrc file and add the following line at the end.

Space: magic-space

Restart the terminal session.

When you type sudo !! or rm -rf !$ and hit Space, the shell immediately replaces the tokens with the full command string right in front of your eyes. You can review, edit, or back out before executing, eliminating both keystrokes and blind execution risk.

🛠️ Tool discovery

Let's see if you find your next favorite tool.

Monoscope: Open-Source Observability and Trace Aggregator for Distributed Microservices

Monoscope is an open-source observability engine tailored for developers needing unified log, metric, and distributed trace visibility across local containers and multi-service staging environments.

GitHub - monoscope-tech/monoscope: Monoscope lets you ingest and explore your logs, traces and metrics. We store these in S3 compatible buckets. Query in natural language via LLMs.

Monoscope lets you ingest and explore your logs, traces and metrics. We store these in S3 compatible buckets. Query in natural language via LLMs. - monoscope-tech/monoscope

GitHubmonoscope-tech

Colanode: Open-Source, Local-First Collaboration Workspace

Colanode is an open-source, local-first collaboration platform designed to unify documents, structured databases, real-time chat, and file management under a self-hosted architecture.

GitHub - colanode/colanode: Open-source and local-first Slack and Notion alternative that puts you in control of your data

Open-source and local-first Slack and Notion alternative that puts you in control of your data - colanode/colanode

GitHubcolanode

📣 Event alert

AGNTCon + MCPCon Europe is happening in Amsterdam on 17–18 September, and if you're building anything in the agentic AI or MCP space, this is the event to attend.

The event is full of open source maintainers, enterprise engineers, infra and tooling folks, and researchers.

You'll bump into the people building MCP itself, alongside teams from AWS, Google, Hugging Face, Microsoft, Anthropic, Solo.io, and a long list of startups exploring Agentic AI.

You can knock off your ticket prices with code ITSFOSS_50.

🗓 17–18 September
📍 RAI Amsterdam

📰 Linux news that matters

• Broadcom has quietly removed all public download pages for the VMware Virtual Disk Development Kit (VDDK), restricting future access exclusively to authorized Technology Alliance partners.
• Threat actors are actively breaching F5 BIG-IP APM appliances to deploy "PoisonedRefresh," a stealthy Linux rootkit that persists across firmware upgrades and modifies SELinux policies.
• CERN is migrating over 2,200 accelerator control computers to Debian 13 to bypass restrictive enterprise CPU requirements and modernize hardware lifecycle management. In a parallel push toward digital sovereignty, the Swiss government has launched a CHF 9 million pilot deploying openDesk to replace Microsoft 365 across 3,000 federal workstations.
• Intel's Dynamic PAMT support has been queued in the x86/tdx tree for Linux 7.4, reducing the ~0.4% baseline memory overhead required by Trust Domain Extensions by allocating the Physical Address Metadata Table dynamically rather than upfront.
• Google has open-sourced Mantis under Apache 2.0, providing a modular framework of slash-command skills that enables AI coding agents to manage end-to-end vulnerability triage.

😂 Geek humor

💌 Keep on loving Linux Handbook

GitOps course is nearly ready. It should arrive next week.

Perfect time to become a Pro member and enjoy unlimited access to our eBooks, courses and in-depth tutorials.

Missed the previous editions? You can access the newsletter archives.

You may also contribute to Linux Handbook and share your experience and expertise with the community.

I like reading your messages, so just hit the reply button and share your thoughts 😄

We have a new course, Tmux Fundamentals. As evident from the name itself, the course teaches you the fundamentals of Tmux.

A terminal multiplexer like Tmux is a lifesaver if you connect to remote servers via SSH. No more session drops because your laptop went in sleep mode or if you forgot to stay connected in the terminal.

Tmux has a little learning curve, and that's the reason we created this new course. It is available to everyone for free. Enjoy 😄

Tmux Fundamentals: Free Course on Terminal Multiplexing

Never lose a terminal session again! Learn tmux sessions, panes, and windows in this free, beginner-friendly course. No signup required.

Linux HandbookYash Kiran Patil

Essential Linux concept: Named pipe redirection

Most linux users are familiar with the concept of redirection. One of the redirections is pipe. The vertical line | in the commands gives Linux an incredible power for combining commands.

But did you know that there is also named pipes that exist like a file in the system. Well, everything is file in Linux so that's not surprising. Named pipes can store output in memory buffer. It's an interesting concept that most of us Linux users don't come across every day.

Pipe redirection in Linux: Named and Unnamed Pipes

There are two kinds of pipes in Linux: named and unnamed. Here’s a detailed look at pipe redirection.

Linux HandbookDebdut Chakraborty

Interested in Linux kernel developments?

Linux Foundation's instructor led training program on Linux Kernel Internals and Developments is for you. The course is designed to provide experienced programmers with a solid understanding of the Linux kernel.

It is an instructor-led virtual session that will run from 9 to 5 for 4 days. Which means that it is like attending a training class but live on your computer. The next session runs on 28th September.

If you are working in a company, you can ask your boss or company to pay for this training. Tell them that you are getting a 50% discount with ILTGTRITSFOSS coupon code that saves $1750 on this specialized course.

💡Quick terminal tip

In a pipeline like commandA | commandB | commandC, the shell only records the exit code of the final command (commandC), quietly masking crashes or errors produced upstream.

Bash solves this with the built-in ${PIPESTATUS[@]} array, which captures the discrete exit codes of every stage in your pipeline.

For example, in the below command:

cat app.log | grep "FATAL" | awk '{print $2}'
echo "${PIPESTATUS[@]}"

The ${PIPESTATUS[@]} array preserves the discrete exit code of every process in the pipeline, not just the awk command.

🛠️ Tool discovery

Let's see if you find your next favorite tool.

Listmonk: Self-hosted, newsletter and mailing list manager

Listmonk is an open-source, AGPL-licensed newsletter and mailing list manager packed into a single Go binary backed by a PostgreSQL database. It features a modern web dashboard with multi-threaded SMTP queues, dynamic templating, SQL-based subscriber segmentation, and an HTTP webhook interface for transactional messaging.

GitHub - knadh/listmonk: High performance, self-hosted, newsletter and mailing list manager with a modern dashboard. Single binary app.

High performance, self-hosted, newsletter and mailing list manager with a modern dashboard. Single binary app. - knadh/listmonk

GitHubknadh

Updo: Real-Time Uptime Monitoring Tool

Updo is an open-source Go CLI tool that monitors website uptime, response latency breakdowns (DNS, TCP, TTFB), and SSL certificate expiration in real time via an interactive TUI or plain-text mode.

GitHub - Owloops/updo: Uptime monitoring CLI tool with alerting and advanced settings

Uptime monitoring CLI tool with alerting and advanced settings - Owloops/updo

GitHubOwloops

📰 Linux news that matters

• The Linux kernel is approaching 2,000 fixed CVEs per release as automated LLM analysis floods maintainers with low-priority bug reports and hallucinated fixes across obscure code paths.
• Multikernel Technologies has launched mklinux v7.0-mk2, an open-source kernel fork that allows physical servers to run multiple independent Linux kernels side by side without a hypervisor.
• Automated AI web scrapers are consuming roughly 20% of git.kernel.org's total compute capacity by requesting individual HTML commit views instead of cloning repositories directly.
• Debian has officially voted to allow generative AI tools for development, maintenance, and documentation, placing full legal and technical accountability directly on the human contributor to review and test all submissions.
• California lawmakers have passed Assembly Bill 1856, amending the upcoming Digital Age Assurance Act to formally exempt software and operating systems distributed under permissive licenses allowing copying, modification, and redistribution.

😂 Geek humor

💌 Keep on loving Linux Handbook

GitOps course is nearly ready. It should arrive next week.

Perfect time to become a Pro member and enjoy unlimited access to our eBooks, courses and in-depth tutorials.

Missed the previous editions? You can access the newsletter archives.

You may also contribute to Linux Handbook and share your experience and expertise with the community.

I like reading your messages, so just hit the reply button and share your thoughts 😄

Your SSH connection drops mid-deploy. Your laptop goes to sleep. You accidentally close the wrong tab. And just like that, the build log you were watching, the SSH session you had open on three servers, the half-finished debugging session...all gone.

Tmux fixes this.

Tmux (terminal multiplexer) lets you run multiple terminal sessions inside a single window, keep them alive even after you disconnect, and pick up exactly where you left off, on the same machine or a different one entirely.

It's one of those tools that, once you learn it, you wonder how you worked without it.

Why learn tmux?

• Sessions that survive disconnects: Close your laptop, lose your SSH connection, or walk away entirely. Your session keeps running and you reattach right where you left off.
• Split panes, no extra windows: View logs, edit a file, and run a build, all in one terminal window, side by side.
• Multiple windows, one session: Organize your work like browser tabs, but built into your terminal.
• Works everywhere: No GUI required. If you can SSH into it, you can run tmux on it.
• Build repeatable workflows: Script your entire dev environment to open exactly the way you like it, every time.

If you spend any real time in a terminal like SSHing into servers, running long processes, working across multiple projects at once, tmux isn't optional for you. You will save a lot of frustration and productive hours.

Tmux has a little learning curve, but it pays off in the long run. Ask any senior engineer.

What you'll learn

By the end of this free Tmux course, you'll be able to:

• Keep a terminal session running even after your SSH connection drops or your laptop sleeps
• Split your terminal into multiple panes and jump between them without touching your mouse
• Organize different tasks across windows, all inside a single tmux session
• Scroll back through terminal output and copy text using only the keyboard
• Set up a real, repeatable workflow instead of retyping the same commands every time
• Write your own tmux configuration so it starts up exactly the way you want, every time

No prior tmux experience needed, just basic comfort with a terminal.

Who this course is for

• Developers and sysadmins who SSH into remote servers regularly
• Anyone who's lost work to a dropped connection or an accidentally closed terminal
• Self-hosters and homelab enthusiasts managing multiple long-running processes
• Command-line users who are tired of juggling a dozen terminal windows
• Complete tmux beginners

Why learn tmux with us?

Most tmux guides stop at a keybinding cheat sheet. This course doesn't.

It's built around actually using tmux, not memorizing commands in isolation. It also includes a dedicated chapter on building a real, practical workflow, and another on writing your own tmux configuration so it feels like your terminal, not a default install.

Every chapter is short, hands-on, and something you can follow along with in your own terminal as you read.

And it's completely free. No signup, no paywall, no catch.

Ready to start?

Jump into Chapter 1: Why Tmux? Understanding Terminal Multiplexing and get your first session running in the next few minutes.

Even after all these years, some people still have a strong dislike for systemd. My colleague, Umair, stopped hating systemd after realizing its automation capabilities.

He has created two courses on systemd:

• Systemd playbook: A hands-on, text-based course to turn you into a confident systemd user.
• Systemd automation: Learn to schedule, monitor, sandbox, and optimize automated workflows.

The best way to learn anything on Linux is by getting your hands on the system. That's the approach we take on Linux Handbook.

Other than us, here are several other platforms you can use to learn DevOps with practical, hands-on labs.

Basic but essential Linux concept: <, << and <<<

You'll often see <, << and <<< in various Linux command examples. It is important to know what they mean.

• < : It is known as Input Redirection and is used to take input from a file rather than typing instructions manually.
• <<: It is known as Here Document which is used to provide multiple lines of input directly to the command.
• <<<: It is known as Here String and used to provide a single line of input to the command.

I know it sounds super complex but this article explains it in details.

What do <, << and <<< mean in Linux?

The <, << and <<< look similar to redirection indicators but they have a different purpose. Learn about them.

Linux HandbookSagar Sharma

🎫 Event alert: AGNTCon+MCPCon Japan

Whether you're building AI agents, adopting the Model Context Protocol (MCP), developing MCP servers and clients, or exploring the future of agentic AI, this is the event where the community comes together to share ideas, solve challenges, and shape what's next for the AI ecosystem.

Happening in Tokyo, Japan, on 10-11th September. If you want to attend, use coupon code ITSFOSS30 to get 30% discount on the event ticket pricing.

💡Quick terminal tip

In Bash (and other Readline-based shells), navigating complex directories often means dealing with annoying typos or mixed case sensitivity. You can make Tab auto-complete paths regardless of capitalization while cleanly expanding common file prefixes before cycling through options.

Add these lines to your ~/.inputrc file:

# Ignore uppercase/lowercase differences during Tab completion
set completion-ignore-case on

# Treat hyphens (-) and underscores (_) as equivalent
set completion-map-case on

# Complete shared prefixes before cycling through individual choices
set menu-complete-display-prefix on

Now, if you have files named Project-Alpha.txt and Project-Beta.txt, typing cd pro and pressing Tab will first safely expand your prompt to the longest shared prefix (cd Project-). Pressing Tab a second time begins stepping smoothly through each matching file, completely ignoring letter case.

🛠️ Tool discovery

Check out these hidden gems.

tuicr: Terminal Native Code Review

tuicr is an open-source Rust TUI utility designed to streamline code review workflows across multiple version control systems using modal, Vim-style navigation. The application aggregates multi-file diffs into a unified stream, allowing users to leave granular, line-level comments and submit them directly as live reviews to major code hosting platforms.

• ⚡ Terminal-native, Vim-centric diffs with seamless modal navigation
• 🔄 Multi-VCS compatibility for unified reviews across git, jj, and hg
• 💬 Inline line-level commenting submitted directly to GitHub, GitLab, and Bitbucket
• 🤖 Structured markdown export to clipboard/stdout tailored for AI agent workflows
• 🦀 Ultra-fast Rust binary delivering zero-dependency CLI execution

GitHub - agavra/tuicr: a code review TUI with vim keybindings

a code review TUI with vim keybindings. Contribute to agavra/tuicr development by creating an account on GitHub.

GitHubagavra

forgit: Interactive Git usage with fzf

Forgit is a shell utility that leverages fzf to provide interactive, terminal-native interfaces for routine version control operations. The tool integrates directly with CLI syntax highlighters while remaining lightweight and shell-agnostic across common terminal environments.

• ⚡ Fuzzy-search Git selectors with interactive diff and log previews
• 🌿 Interactive branch and worktree management for seamless switching
• 🛠️ Automated .gitignore generator to fetch templates straight from your terminal
• ⏪ Interactive rebase and fixup tools to easily squash and reorder commits
• 🎨 Extensible preview integration using external tools like delta for diffs and bat for syntax highlighting

GitHub - wfxr/forgit: :zzz: A utility tool powered by fzf for using git interactively.

:zzz: A utility tool powered by fzf for using git interactively. - wfxr/forgit

GitHubwfxr

📰 Linux news that matters

• Qualcomm has started a Linux kernel discussion about upstreaming Synx, a vendor-agnostic global synchronization framework for coordinating fences across different processors, firmware, and Linux-hosted clients.
• Linux wireless maintainer Johannes Berg has announced that AI/LLM-generated patches will generally be ignored unless a quick review makes the fix “obviously right,” following a similar move in the kernel staging area.
• Cloudflare has open-sourced Cloudflare OS (VibeSDK), an internal platform enabling non-technical personnel to build and deploy applications via natural language prompts.
• Microsoft has open-sourced code-testing-generator, an MIT-licensed polyglot unit test creation agent hosted within the dotnet/skills repository.
• Senior Linux kernel maintainer Greg Kroah-Hartman has established a explicit policy rejecting LLM-generated patch submissions targeting the drivers/staging tree.
• Sonatype researchers have identified an automated supply-chain campaign dubbed "Flooding Dropper" that has published nearly 850 malicious npm packages distributed across hundreds of disposable accounts.
• Modular has released the complete source code for the Mojo language compiler, runtime, and development tooling under the Apache 2.0 license with LLVM exceptions following its 1.0 release.

😂 Geek humor

💌 Keep on loving Linux Handbook

GitOps course is nearly ready. It should arrive next week.

Perfect time to become a Pro member and enjoy unlimited access to our eBooks, courses and in-depth tutorials.

Missed the previous editions? You can access the newsletter archives.

You may also contribute to Linux Handbook and share your experience and expertise with the community.

I like reading your messages, so just hit the reply button and share your thoughts 😄

Watching DevOps tutorials is easy. Actually knowing what to do when a server is broken at in production is not.

The gap between the two is hands-on practice and if you have been searching for structured, interactive DevOps labs, you have probably run into the same problem: most good platforms cost money, and the free ones are scattered across a dozen different sites with no clear path connecting them.

I went through the platforms the DevOps community actually recommends on Reddit, in Discord servers, in job prep threads and pulled together the 12 best ones where you can practice for free. These are not passive reading resources. Every platform here puts you in front of a terminal and makes you figure something out.

This list is not for you if you are looking for video courses or reading material that is a different category. This guide is about interactive labs, broken-server challenges, browser-based environments, and hands-on projects where you learn by doing.

Short on time? Jump to the comparison table below, or use the headers to find platforms that match your current skill level.

At a Glance: All 12 Platforms Compared

SadServers - The LeetCode of DevOps Troubleshooting

SadServers is the closest thing DevOps has to LeetCode. You are given a broken Linux or DevOps environment, a problem statement, and a timer. Your job is to fix it. No hints, no hand-holding, just a terminal and a server that is doing something wrong.

Who it's best for: Anyone who wants to practice the skill that actually matters most in DevOps: diagnosing and fixing production problems under pressure. Especially useful if you are preparing for DevOps interviews, where live troubleshooting scenarios are increasingly common.

The scenarios cover real DevOps situations: a web server that refuses to start, a disk that is mysteriously full, a process that keeps dying, a misconfigured database. Each one is an actual production-style failure.

Verdict: The single best platform for practicing the skill that defines a working DevOps engineer, fixing things that are broken. Bookmark this and do one scenario a week.

OverTheWire - Bandit: Learn Linux by Breaking In

OverTheWire Bandit is a wargame where you SSH into a live server and solve challenges to discover the password for the next level. Level 0 to Level 34, each one teaching a specific Linux skill through a concrete puzzle rather than a lecture.

Who it's best for: Complete beginners who need real Linux terminal practice and people who are comfortable with commands but want to understand file permissions, process management, and shell scripting by actually using them under pressure.

The early levels cover navigation, file reading, and hidden files. By the time you reach the middle levels, you are working with SSH keys, port forwarding, shell scripting, and basic cryptography. Every concept sticks because you needed it to progress.

Verdict: The best free tool to build Linux command-line confidence from scratch. There is a reason DevOps engineers still recommend it to juniors in 2026; it works.

Learn Git Branching - Master Git Visually

Learn Git Branching is a browser-based, interactive Git tutorial that teaches branching, rebasing, merging, and cherry-picking through visual puzzles. You type real Git commands and watch the commit graph update in real time.

Who it's best for: Anyone who uses Git daily but secretly does not understand what rebase, cherry-pick, or HEAD~2 actually does, which is most engineers at some point.

The platform covers two tracks: Main (local Git operations) and Remote (push, pull, fetch, tracking branches). Each level sets a goal state for the commit graph and you have to figure out which commands produce it.

Verdict: The fastest way to actually understand what your Git commands are doing. Run through both tracks once and Git will never feel mysterious again.

Killercoda - The DevOps Lab That Is Always Open

Killercoda gives you a real Linux environment in your browser, no install, no account required for the free tier. Choose a scenario, and within seconds, you have a terminal connected to a real server. The scenario library covers Linux, Docker, Kubernetes, Ansible, ArgoCD, Terraform, and more.

Who it's best for: Anyone who wants a quick, no-friction DevOps practice, especially useful for learning a new tool without setting up a local environment first, or for keeping skills sharp between projects.

The free library includes hundreds of official and community-created scenarios. Many are contributed by tool vendors themselves, Grafana, Cilium and others publish their official getting-started tutorials directly on Killercoda.

Verdict: The best free option for hands-on practice with any specific DevOps tool right now. Anytime you encounter something new, ArgoCD, Cilium, Flux, check if there is a Killercoda scenario before setting up a local environment.

Play with Docker - A Real Docker Daemon in Your Browser

Play with Docker gives you a free, 4-hour Linux instance with a real Docker daemon running, directly in your browser. Run containers, build images, write Compose files, and experiment with Docker networking without touching your local machine.

Who it's best for: Beginners who want to learn Docker without installing it locally, and people who need a quick sandbox to test a Docker command or Compose configuration without affecting their machine.

You can create multiple instances and connect them, useful for practicing Docker Swarm or multi-container networking scenarios. The official Docker documentation uses Play with Docker for many of its interactive examples.

Verdict: The zero-friction way to start with Docker. No installation, no configuration, just a terminal and a Docker daemon. Use this before committing to a local Docker Desktop setup.

Play with Kubernetes - A Multi-Node Cluster in Minutes

Play with Kubernetes provides a free, browser-based Kubernetes playground where you can bootstrap a real multi-node cluster and run workloads, without any local Kubernetes installation or cloud account.

Who it's best for: People learning Kubernetes fundamentals who want to practice kubectlcommands, deploy real workloads, and understand cluster architecture without the complexity of setting up minikube or a cloud cluster.

Sessions give you a 4-hour window with enough compute to bootstrap a control plane and add worker nodes. Every standard kubectl operation works: deployments, services, configmaps, namespaces and RBAC.

Verdict: The most accessible way to get a real Kubernetes cluster for practice without a cloud bill. Pair it with Kubernetes The Hard Way for a deeper understanding of what that bootstrap process is actually doing.

pwn.college - Deep Linux Internals Through Structured Challenges

pwn.college is a university-backed (Arizona State University) platform that teaches Linux internals through a structured series of challenges. Unlike typical beginner Linux tutorials, it covers how the shell works, process interactions, file descriptors, environment variables, and privilege escalation, concepts that are foundational to DevOps but rarely taught explicitly.

Who it's best for: Engineers who use Linux daily but want to deeply understand what is actually happening beneath the commands, process spawning, shell internals and permissions at the kernel level. Especially valuable if you work with Docker, because containers are Linux primitives underneath.

The platform is organized into modules (Linux Luminarium is the entry point for DevOps practitioners) and every challenge is a real binary running on a real Linux system that you interact with directly.

Verdict: The best free resource for understanding why Linux behaves the way it does, not just memorizing commands. If you use containers daily and want to understand what namespaces and cgroups actually are, start here.

Grafana Play - Live Observability Practice With Zero Setup

Grafana Play is a fully functional, live Grafana instance that anyone can open in a browser right now, pre-loaded with dashboards, Loki log data, Prometheus metrics, alerting rules, and Tempo traces. No installation, no Docker Compose stack, no Prometheus setup.

Who it's best for: Engineers who want to get comfortable with Grafana dashboards, PromQL queries, Loki log queries, and alert configuration before setting up a full observability stack locally or in production.

Verdict: If your Linux skills feel shaky and you want to fix that with a structured, real-world approach, the Linux Upskill Challenge is the most complete free answer. Twenty focused days produce a genuine foundation.

Linux Upskill Challenge - 20 Days to Real Linux Sysadmin Skills

The Linux Upskill Challenge is a free, community-run 20-day course where you rent a cheap VPS (or use a free cloud trial) and learn to manage it as a real system administrator would. Each day introduces new concepts with clear instructions, exercises, and a community forum for questions.

Who it's best for: Beginners who want a structured, day-by-day Linux learning path that produces a real skill foundation, not just knowledge of commands, but actual comfort managing a remote server. The VPS-based approach means everything you do is real.

The course covers everything a working sysadmin needs: SSH key management, file permissions, package management, process management, system services with systemd, firewalls, cron jobs, log analysis, and basic security hardening.

Verdict: If your Linux skills feel shaky and you want to fix that with a structured, real-world approach, the Linux Upskill Challenge is the most complete free answer. Twenty focused days produces a genuine foundation.

Kubernetes The Hard Way - Build a Cluster From Scratch

Kubernetes The Hard Way, created by Kelsey Hightower (Google), guides you through bootstrapping a Kubernetes cluster manually, without kubeadm, without any helper scripts, every component configured by hand. It is not the easiest way to get a cluster, which is exactly the point.

Who it's best for: Engineers who already use Kubernetes daily but feel like they are operating it without truly understanding it. Going through this once answers questions that years of kubectl apply never will.

Verdict: Not something you do every day, but something every serious Kubernetes practitioner should do at least once. The understanding it provides changes how you operate clusters permanently.

iximiuz Labs - Investigate How Containers and K8s Actually Work

iximiuz Labs takes a deliberately different approach to DevOps learning: instead of guided tutorials, it puts you in an environment and asks you to investigate how something works. Labs cover container networking, Linux namespaces, Kubernetes control plane behavior, and distributed systems concepts through exploration rather than instruction.

Who it's best for: Intermediate to advanced practitioners who want to understand why containers and Kubernetes behave the way they do, the Linux primitives underneath Docker, why pod networking works the way it does and what the scheduler actually considers.

The free tier includes a solid selection of foundational labs on container runtimes, networking, and Kubernetes basics. The platform is built by Ivan Velichko, widely respected in the cloud-native community for the depth of his writing on container internals.

Verdict: The best platform for going from "I can use Kubernetes" to "I understand Kubernetes." If you have been using containers for a year and still feel uncertain about the internals, this fills that gap.

Terraform Tutorials - Official Interactive IaC Practice

HashiCorp's official Terraform tutorials on the Developer portal are interactive, browser-based labs that teach Infrastructure as Code without requiring a cloud account for most foundational content. They cover AWS, Azure, GCP, and local Terraform workflows with a consistent, practical structure.

Who it's best for: Engineers who know containers and Kubernetes but have not yet learned Infrastructure as Code and anyone preparing for the Terraform Associate certification who wants practice alongside the theory.

The tutorials build progressively: start with a local Docker provider (no cloud account needed), move to cloud providers once you understand the workflow. Each tutorial includes working code, an explanation of what each block does, and a real-world step.

Verdict: The most reliable starting point for Terraform. If IaC is the gap in your DevOps skillset and for many practitioners it is, start here before looking anywhere else.

How to Use These Platforms Together

These platforms are not competing alternatives; they cover different skills and different learning modes. A practical sequence:

• Start with Linux fundamentals : Linux Upskill Challenge (structured) + OverTheWire Bandit (challenges)
• Add Git mastery early : Learn Git Branching (spend one afternoon, do both tracks)
• Learn containers hands-on : Play with Docker, then Killercoda Docker scenarios
• Move to Kubernetes : Play with Kubernetes for basics → Killercoda K8s scenarios → Kubernetes The Hard Way for deep understanding → iximiuz Labs for internals
• Add IaC : Terraform Tutorials (start with local Docker provider, no cloud account needed)
• Add observability : Grafana Play (explore before setting up your own stack)
• Keep troubleshooting sharp : SadServers (one scenario per week) + pwn.college Linux modules

None of these require paid subscriptions to start; all have free tiers that cover the core learning value.

FAQ

Do I need a powerful computer to use these platforms?
No. Every platform on this list is either browser-based or requires only a basic setup. Your local machine is just a browser or SSH client.

Which platform should a complete beginner start with?
Start with Linux Upskill Challenge for structured foundations, then add OverTheWire Bandit for command-line confidence, then Learn Git Branching for Git. After those three, Killercoda opens up most of the rest of the DevOps toolchain at a reasonable pace.

Are these platforms useful for certification preparation (CKA, CKAD, Terraform Associate)?
Yes. Play with Kubernetes and Killercoda are both consistently recommended for CKA/CKAD practice. Terraform Tutorials covers the Terraform Associate curriculum directly. SadServers builds the troubleshooting speed that the CKA exam requires.

Is Kubernetes The Hard Way still relevant with modern tools like k3s and minikube?
Yes, and for the same reason, reading a car manual is still useful even if you use a GPS. K3s and minikube are better for daily use. The Hard Way is for understanding what they are abstracting. Do it once, then use the convenient tools with actual understanding.

Conclusion

The best DevOps skill is not knowing which tool to use; it is knowing what to do when something breaks. Every platform on this list gets you closer to that, whether you are starting from zero with the Linux Upskill Challenge, building Git intuition with Learn Git Branching, diagnosing broken servers on SadServers, or finally understanding what Kubernetes is actually doing under the hood with Kubernetes The Hard Way and iximiuz Labs.

You do not need to work through all twelve at once; pick the one that matches your current gap, spend a few hours a week, and let the practice compound. The engineers who stand out in DevOps are the ones who have broken things, fixed things, and done it enough times that the instinct becomes automatic. These platforms give you the reps. If you know of such a platform, do drop it in the comments!

Don't we learn something new everyday? Something that might be obvious to others but feels like discovery to you?

I had that feeling when I learned about the concept of compose override in Docker. In my self-hosted Ghost CMS deployment, I made modifications in the compose file to introduce log rotation. But now the compose file was modified and any upstream change would complain about modified file. Git stash comes to rescue, but it's an additional pain.

And that pain went away with the override compose file. It's an excellent way of separating local and upstream changes, local and production compose files. I wrote about it here.

Git Pull Kept Failing on My Ghost Server. Docker Compose Override Fixed It

Modifying your docker-compose.yml directly and now git pull throws a “local changes would be overwritten” error? Use a compose.override.yml file to keep your changes separate from the file Ghost’s repo manages.

Linux HandbookAbhishek Prakash

Claude (or other mainstream AI tools) can be an excellent help in troubleshooting your infrastructure issues. But if you just ask it "find me for this error message", you'll get generic answers. Yash who has recently started working as a DevOps engineer shares some of the Claude skills he uses. You can take inspiration and modify these skills as needed or use them as it is.

8 Claude Skills I Use Everyday as a DevOps Engineer

Sharing the skills I use for troubleshooting and other purposes as a devops engineer. They are primarily for Claude but should work with other AI tools, too.

Linux HandbookYash Kiran Patil

💡Quick terminal tip

In bash (and other readline-based shells), press Alt+Shift+3 (or Alt+#) while typing a command. It prefixes the line with #, submits it, and since # starts a comment, the command won't execute.

It stays in your shell history for later. Handy for jotting down a command you're not ready to run yet.

Now that you know this one, here are a few more shortcuts worth adding to your muscle memory.

🛠️ Tool discovery

Let's find your next favorite software in this section.

Buzz: Self-Hostable Workspace for Humans and AI Agents

Buzz is an open-source collaboration platform from Block that brings team chat, Git repositories, and AI agents into a single workspace. Built on the Nostr protocol, it lets organizations self-host their collaboration platform while allowing AI agents to participate as authenticated team members with their own identities and permissions.

• 💬 Integrated Team Collaboration – Channels, threads, DMs, media sharing, and search in one workspace (voice huddles in progress).
• 🤖 AI Agents as Teammates – Agents hold cryptographic identities and can review code, submit patches, and collaborate alongside humans.
• 🌐 Self-Hostable & Open Source – Apache 2.0 licensed; deploy on your own infrastructure with full data control.
• 🛠️ Built-in Git Collaboration – Host repos, submit patches, and manage code review without external Git hosting.
• 🔐 Nostr-Based Architecture – Every event is signed via Nostr, giving verifiable identity and a full audit trail.

GitHub - block/buzz: A hive mind communication platform

A hive mind communication platform. Contribute to block/buzz development by creating an account on GitHub.

GitHubblock

Solidtime: Modern Open-Source Time Tracking for Teams

Solidtime is an open-source time tracking platform built for freelancers, agencies, and teams that need an easy way to track work, manage projects, and generate invoices. It offers a polished web and desktop experience, supports self-hosting, and keeps activity tracking privacy-friendly by processing desktop activity locally before converting it into time entries.

• ⏱️ Time Tracking – Simple, modern interface to track work time.
• 📁 Projects & Tasks – Create projects and tasks, and assign them to team members.
• 👥 Clients – Manage clients and link them to projects.
• 💰 Billable Rates – Set rates per project, member, or organization.
• 🏢 Multiple Organizations – Manage several organizations from one account.
• 🔑 Roles & Permissions – Control access within organizations.
• 📥 Data Import – Import from Toggl, Clockify, or CSV.

GitHub - solidtime-io/solidtime: Modern open-source time-tracking app

Modern open-source time-tracking app. Contribute to solidtime-io/solidtime development by creating an account on GitHub.

GitHubsolidtime-io

📰 Linux news that matters

• The Linux kernel CVE team published 432 CVEs over just two days, prompting concerns from security engineers about the practicality of reviewing and prioritizing individual kernel vulnerabilities. The surge reflects the kernel project's policy of assigning CVEs to virtually every qualifying security-related bug fix in stable releases, with AI-assisted bug discovery also contributing to the growing number of reports reaching maintainers.
• NetworkManager 1.58 adds support for IPv6-only deployments through RFC 8925 IPv6-only-preferred signaling and 464XLAT (CLAT), enabling legacy IPv4 applications to continue working on IPv6-only networks. The release also introduces GENEVE tunnel management for virtualized environments, 6 GHz Wi-Fi enhancements, persistent managed state across reboots for automation, and fixes multiple DHCP-related security issues, including CVE-2026-10805.
• Cisco has released Antares-350M and Antares-1B, two open-weight small language models purpose-built to locate known vulnerabilities within large source code repositories. Unlike general-purpose coding models, Antares focuses on repository-level vulnerability localization. Can run locally without uploading proprietary code to the cloud, and Cisco claims it achieves comparable accuracy at up to 172× lower cost than leading frontier AI models while also releasing a benchmark to measure this task.
• The Model Context Protocol (MCP) is preparing its 2026-07-28 specification, replacing its stateful architecture with a stateless protocol core by removing session IDs and the initialization handshake while introducing a new extensions framework and stronger authorization mechanisms. The redesign allows MCP servers to run behind standard HTTP load balancers without sticky sessions or shared session stores, making large-scale deployments significantly easier, although existing implementations will require migration because of breaking protocol changes.
• GitHub has made its redesigned Pull Requests Dashboard generally available, introducing an Inbox that surfaces review requests, CI failures, merge-ready pull requests, saved views, advanced search, and support for identifying AI agent-created pull requests. The update reflects a broader industry shift where AI coding assistants generate code faster than humans can review it, prompting GitHub to focus on review triage rather than code generation alone.

😂 Geek humor

💌 Keep on loving Linux Handbook

GitOps course is nearly ready. It should arrive next week.

Perfect time to become a Pro member and enjoy unlimited access to our eBooks, courses and in-depth tutorials.

Missed the previous editions? You can access the newsletter archives.

You may also contribute to Linux Handbook and share your experience and expertise with the community.

I like reading your messages, so just hit the reply button and share your thoughts 😄

I was skeptical about AI tools in a DevOps workflow for a long time. Every demo I saw showed someone asking AI Agent to write a Hello World Dockerfile. That's not a DevOps use case, that's a simple chat.

What changed my mind was using Claude for things that actually slow me down at work. Not boilerplate code generation, but the genuinely tedious parts of the job: interpreting a cryptic error from a stack trace buried inside a Kubernetes pod, converting a Bash script someone wrote in 2017 into something readable, or asking "what does this flag do again" without having to leave the terminal context I'm already in.

But here's the thing: generic Claude and skilled Claude are two very different tools.

Out of the box, Claude gives you general-purpose answers. When you add a SKILL.md, a structured instruction file that tells Claude exactly how to approach a specific task, you get a focused, deterministic workflow instead of a guess. The difference matters in DevOps, where a half-correct answer about a Kubernetes misconfiguration or a Terraform plan can cause real problems.

This article covers both sides: the skills themselves, and the concrete difference between using Claude with and without them. I'm running this on VS Code with Claude Sonnet 4.6.

What Are Claude Skills?

Claude Code supports a feature called skills: markdown files named SKILL.md that live inside a .claude/skills/ directory in your project. When you ask Claude something that matches a skill's trigger phrases, it automatically uses the structured workflow defined in that file instead of its default behavior.

Think of it like the difference between asking a new colleague a question and asking someone who's already written the runbook for it. Same knowledge, completely different depth and reliability.

I've written 8 of my own, one for each workflow I find myself using regularly.

Why Skills Actually Matter

Let me show the difference concretely before going through each skill.

I'll use the error-decoder skill as the example, with a Docker container that keeps exiting. This is something you can reproduce on any machine with Docker installed.

The prompt: "My Docker container keeps exiting immediately. Here's the output." (with docker logs and docker inspect output pasted in)

Here's what I actually pasted in:

$ docker run --name my-app myrepo/my-app:2.1.0
Error: DATABASE_URL environment variable is not set.
Exiting.

$ docker inspect my-app --format='{{.State.ExitCode}} {{.State.OOMKilled}}'
1 false

$ docker ps -a | grep my-app
my-app   myrepo/my-app:2.1.0   Exited (1) 3 seconds ago

The response is accurate but completely generic. It lists common causes without engaging with the actual output that was pasted. The real answer is sitting right there in the logs (DATABASE_URL environment variable is not set) but Claude, without the skill, doesn't structure its analysis to find it.

The response now follows the skill's output format. It pulls the specific root cause directly from the logs, gives the exact fix command, tells you what a successful run looks like, and gives the next diagnostic step if it still fails.

The skill didn't add knowledge Claude didn't have. It added structure and focus, it forces Claude to identify the root cause separately from the proximate cause, and to give a verification step instead of stopping at "here's the fix."

The 8 Claude Skills in My Toolbox

Below are the 8 skills you will have in your project, which will give you a focused and structured workflow for your projects. I will also show you the results I get after the prompt I give to the agent with the skills enforced. You are free to download them and modify them as per your requirements.

The skills folder structure will look like this:

.claude/
└── skills/
├── error-decoder/
│ └── SKILL.md ← Diagnose Kubernetes, Terraform, Helm errors
├── bash-auditor/
│ └── SKILL.md ← Write and audit Bash scripts
├── k8s-manifest-reviewer/
│ └── SKILL.md ← Explain and audit Kubernetes YAML
├── format-converter/
│ └── SKILL.md ← Convert between DevOps formats and tools
├── runbook-drafter/
│ └── SKILL.md ← Draft runbooks, postmortems, SOPs
├── terraform-explainer/
│ └── SKILL.md ← Explain and audit Terraform code and plans
├── api-tester/
│ └── SKILL.md ← Generate cURL and API test commands
└── cicd-auditor/
└── SKILL.md ← Audit GitHub Actions, GitLab CI, Jenkins

error-decoder - Diagnosing Cryptic Errors

This is the one I use most often. DevOps tools are notoriously bad at error messages. Docker exits a container with code 137 and you're left guessing whether it's OOM or a signal. Terraform throws a provider error with a reference ID you have to track down. Helm fails on a templating issue with a line number that doesn't match your file. Kubernetes gives you a pod in CrashLoopBackOff with no explanation of why. In all of these cases, the raw error is pointing at a symptom, not at the cause.

My workflow: paste the full error, not a summary, the full thing and add two sentences of context:

Here is the error from my Kubernetes pod. This pod was working yesterday.
The only change was updating the image tag from 1.3.2 to 1.4.0.

[full kubectl describe pod output]

The single biggest thing that improved my results: treating Claude like a knowledgeable colleague who needs to be briefed, not a search engine. The skill enforces this by requiring full context before proceeding.

bash-auditor - Writing and Reviewing Bash Scripts

Bash is the lingua franca of DevOps and also one of the most footgun-prone languages in existence. A script that looks fine will silently fail because someone forgot set -e. A loop will do something destructive because the variable expansion wasn't quoted. A condition will always evaluate to true because of the way [[ ]] handles empty strings.

I use this skill for three things: Writing scripts from a plain-English description, reviewing scripts I didn't write, explaining what a script does, etc.

# My Prompt

Review this Bash script as if you're performing a production code review.

Identify:
- Bugs
- Security issues
- Reliability problems
- Quoting mistakes
- Error handling issues
- Race conditions
- Portability concerns
- Performance improvements

Explain why each issue matters and then provide a corrected production-ready version with comments.

A note on trust: I always read through generated Bash before running it, especially anything that touches the filesystem or makes external requests. The skill produces a first draft with proper structure, not production-certified code.

k8s-manifest-reviewer - Understanding Kubernetes YAML

Kubernetes YAML is verbose by design. A single Deployment manifest can be 80 lines long and most of it is boilerplate. The meaningful parts, resource limits, liveness probes, affinity rules and security contexts are buried in the middle.

I use this skill in two ways:

Explaining what a manifest does: Paste in a Deployment or StatefulSet YAML I haven't seen before and the skill walks through it section by section, calling out anything non-obvious. Particularly useful when you inherit infrastructure and need to quickly understand what's running and why.

Spotting misconfigurations: The skill audits against a production-readiness checklist

# My prompt
Review this Kubernetes Deployment as if you're the platform engineer responsible for approving it for production.

Please:
1. Explain what each section of the manifest does.
2. Point out any security, reliability, scalability, or performance issues.
3. Identify Kubernetes best-practice violations.
4. Rank the issues by severity (Critical, High, Medium, Low).
5. Explain why each issue matters.
6. Suggest concrete fixes.
7. Provide a corrected production-ready manifest.

Context:
- This is running in a production EKS cluster.
- It was migrated from a development environment.
- Traffic is expected to reach 800-1000 requests per second.
- High availability is required.
- Zero-downtime deployments are expected.

Here's the manifest provided:

Things the skill catches that are easy to miss: Memory limit lower than memory request, missing readinessProbe, hostNetwork: true left in from a debugging session, :latest image tag in a production manifest, no podAntiAffinity rules, etc.

format-converter - Converting Between DevOps Formats

DevOps involves a lot of format conversion work that nobody talks about because it's unglamorous. Docker Compose files that need to become Helm charts. Bash scripts that need to become Ansible playbooks. cURL commands from API docs that need to become Python scripts. JSON that needs to become YAML.

All of this is mechanical but error-prone when you do it by hand.

The skill enforces that constraints are explicit before generating output. The more specific your constraints, the less cleanup you do afterwards.

runbook-drafter - Writing Operational Documentation

A runbook is only useful if it's actually written. Most teams have "runbooks" that are either a Confluence page last updated in 2021 or just "the person who knows how to restart the thing."

My process: do the thing first, then write a quick stream-of-consciousness description of what I did and why:

# My prompt

I just fixed a production database connectivity issue. Here's what happened:
the app pods were getting connection refused on port 5432, which turned out to
be a NetworkPolicy that was blocking traffic from the app namespace to the db
namespace after a recent namespace label change. I fixed it by updating the
namespaceSelector in the NetworkPolicy. Write a runbook section for this.

The skill turns that stream-of-consciousness into a structured runbook section in about 30 seconds. I edit it, add the actual commands I ran, and it becomes something a teammate could actually follow at 2am.

The same approach works for postmortems. Dump the timeline, dump the actions, ask the skill to organize it into a postmortem structure. You still write the "lessons learned" section yourself; that's the part that requires judgment.

terraform-explainer - Understanding Infrastructure as Code

Terraform's HCL is readable enough on its own, but complex module structures - especially third-party modules with 40 variables, can be hard to parse quickly. I use this skill to understand infrastructure I didn't write.

Reading a module:

Explain what this Terraform module does. I specifically want to understand:
- What resources it creates
- What the required vs. optional variables are
- Whether anything here creates a public-facing resource
- Anything that might be surprising in a production AWS account

Provider APIs go stale. Terraform and cloud provider APIs evolve constantly. For anything version-sensitive, verify against the official registry before trusting the output.

api-tester - Generating cURL and API Test Commands

Every time I'm integrating a new service or debugging a webhook, I end up constructing cURL commands from API documentation. JWT auth headers, JSON body formatting, the right Content-Type; this is tedious and the skill is fast at it.

The prompt I put:

Give me a cURL command to call the GitHub REST API to list all open pull
requests for the repo "myorg/myrepo", authenticated with a personal access
token stored in $GITHUB_TOKEN, with output formatted as JSON and piped to jq
to show only the PR title and number.

The skill knows the auth patterns for common APIs (GitHub, Slack, Prometheus, Alertmanager, PagerDuty) without needing to be told. It also enforces that credentials are always environment variables and generated commands never contain a literal token.

I use this for any API I haven't touched before: Prometheus remote write, Alertmanager webhooks, AWS API Gateway, Slack, PagerDuty, wherever I need a quick working example to start from.

cicd-auditor - Reviewing CI/CD Pipeline Configs

CI/CD pipelines written in YAML accumulate complexity over time. Stages that nobody remembers the purpose of. Jobs that run sequentially because nobody added needs: correctly. Secrets being printed to logs somewhere. Docker layers not being cached.

My review prompt:

Review this GitHub Actions workflow for common issues:
- Steps that could be parallelized but aren't
- Secrets being exposed in logs
- Missing caching for dependencies or Docker layers
- Jobs that will always run even when they should be conditional
- Third-party actions not pinned to a SHA

The skill specifically checks for something that most miss: third-party GitHub Actions pinned to mutable tags. uses: some-action/tool@v3 looks fine, but it can be hijacked; the tag can be moved to point at different code. The safe version is pinning to a commit SHA.

Wrapping Up

The value I get from Claude in a DevOps context is concentrated in specific places: decoding errors faster, auditing configs I didn't write, handling format conversion that's mechanical but annoying, and getting documentation drafted while the context is fresh. You can refer the official documentation for Claude skills.

The skills are what make this reliable instead of hit-or-miss. Without them, Claude gives you general advice. With them, it follows a deterministic workflow - asks for the right inputs, applies a consistent checklist, and formats the output in a way you can actually act on.

If you have more such skill.md that you use, share them in the comments and tell how these skills enhance your workflow!

Have you ever deployed an app to Kubernetes and later realized you don't really know what changed, who changed it, or how to roll it back safely? Maybe dev looked fine, staging looked stable, and production still broke at midnight, right when nobody wanted to touch it.

This is exactly the problem GitOps exists to solve.

GitOps isn't just another DevOps trend. It's a deployment model where Git becomes the single source of truth for your infrastructure and applications. Your cluster continuously pulls the desired state from Git, so every change is auditable, reversible, and predictable.

Tools like ArgoCD make this possible on Kubernetes, and that's exactly what this course teaches you, starting from the core concepts and working all the way to real production deployments.

What you'll learn

This course is split into four modules, taking you from concepts to implementation to production-grade, safe deployments.

Module 1: GitOps Foundations

• What GitOps really is, and how it compares to traditional DevOps
• Why GitOps is not just CI/CD, and why it's trending right now
• Push vs pull deployments, explained with real-world examples

Module 2: Getting Started with ArgoCD

• Installing ArgoCD and understanding its architecture
• Deploying your first application the GitOps way
• Setting up RBAC and managing user access

Module 3: Working with ArgoCD

• Secret management in GitOps
• Helm vs Kustomize deployments
• Multi-environment GitOps strategy across dev, staging, and production

Module 4: Progressive Delivery with Argo Rollouts

• Blue-green and canary deployments
• Automated rollbacks
• Metrics based decision and safe production releases

Who this course is for

This course is for you if you deploy applications to Kubernetes and want a safer, more predictable way to do it. It works well whether you're a DevOps engineer tired of manual deployments, a platform engineer building GitOps workflows for your team, or a developer and student who just wants to understand what ArgoCD and Argo Rollouts are actually doing under the hood.

You don't need any prior experience with ArgoCD to start. A basic understanding of Kubernetes will help you get more out of the course, but the first module builds up the concepts from scratch anyway.

Start the course

Start with Module 1 and go through the four modules in order. Each one builds on the last, so you move from GitOps concepts, to your first ArgoCD deployment, to running progressive, production-grade rollouts by the end.

By the time you finish the final project in Module 5, you'll have hands-on experience with the same GitOps setup used to run real production systems.

If editing your docker-compose.yml directly is breaking git pull from upstream, here's the fix: move your customizations into a separate compose.override.yml file instead of editing the original.

The fix: use a compose override file

Create a compose.override.yml in the same folder as your compose.yml, and use the exact service names from your original file (ghost and caddy, in my case).

services:
  ghost:
    logging:
      driver: json-file
      options:
        max-size: "100m"
        max-file: "5"
  caddy:
    logging:
      driver: json-file
      options:
        max-size: "100m"
        max-file: "5"

Docker Compose picks up compose.override.yml automatically and merges it into compose.yml at runtime, so you don't need to pass any extra flags.

So, when you run:

docker compose up

It is equivalent to running:

docker compose -f compose.yml -f compose.override.yml up

Your original compose.yml never gets touched, so there's nothing left for git pull to conflict with and so no complaints from git.

How I ran into this

I run my Ghost sites using Ghost's official Docker Compose self-hosting method. Eventually, I noticed that Ghost's default setup generates a lot of log output, so I added log rotate option in the docker compose file for the ghost and caddy services directly inside compose.yml.

This solved the logs eating up disk space problem, but updating the Ghost version became inconvenient.

Updating to a newer Ghost version after that is meant to be a simple three-step routine:

• git pull
• docker compose pull
• docker compose up -d.

That routine broke because I modified compose.yml. Every git pull started failing with the same error:

root@ghost-learnubuntu:/opt/ghost# git pull
remote: Enumerating objects: 89, done.
remote: Counting objects: 100% (68/68), done.
remote: Compressing objects: 100% (46/46), done.
remote: Total 89 (delta 52), reused 29 (delta 20), pack-reused 21 (from 2)
Unpacking objects: 100% (89/89), 31.28 KiB | 485.00 KiB/s, done.
From https://github.com/TryGhost/ghost-docker
   14cc722..d3204b2  main                                   -> origin/main
Updating 14cc722..d3204b2
error: Your local changes to the following files would be overwritten by merge:
        compose.yml
Please commit your changes or stash them before you merge.
Aborting

For a while, my workaround was keeping a backup of the untouched compose.yml, or running git stash before every pull. It worked, but it meant remembering an extra step every single time I wanted to update Ghost.

And one day, I came across the concept of compose override file.

What is a compose override file

A compose override file is just a second compose file that sits next to your main one. Anything you define inside it gets layered on top of compose.yml automatically, without you having to pass any extra flags to docker compose.

Since it's a separate file, it's not the one git is tracking against upstream, so pulling new changes from Ghost's repo doesn't touch anything you've customized.

Here's the compose.override.yml file for my Ghost.

This solved the problem for me completely. My compose.yml now stays exactly as it comes from upstream, and git pull, docker compose pull, docker compose up -d goes back to being a clean three-step routine.

Using override files to separate test and production

The same mechanism works for more than just logging. Since an override file just layers extra configuration on top of the base file, you can use a similar setup to separate test and production: keep one compose.override.yml for local tweaks like lighter resource limits or different ports, and a separate file, say compose.prod.yml, for anything specific to production. You pick which one applies at deploy time with the -f flag.

Other ways to use override files

Let's see various ways you can use the overrride compose file.

Run without override

If you ever need to deploy without applying the override, point docker compose at only the base file explicitly:

docker compose -f compose.yml up -d

Passing -f like this skips the automatic override merge entirely.

Use multiple override files

You're also not limited to one override file. Layer as many as you need by repeating -f in order, with later files taking priority over earlier ones:

docker compose -f compose.yml -f compose.override.yml -f compose.prod.yml up -d

See what the final compose file looks like

Whenever you want to double check what's actually being applied after all that layering, run:

docker compose config 

It prints the fully merged result.

💡Add override to gitignore

I have added my compose.override.yml to the .gitignore. It's local to my setup, not something upstream needs to know about, and keeping it out of git means I'll never run into a merge conflict over it either. You can do the same if it fits your scenario.

I'm sure there's more you can do with override files depending on your setup, but this fixed the problem I had: keeping my logging tweaks out of the file Ghost's repo manages.

If you're running Ghost, or anything else, through docker compose and editing the compose file directly, it's worth switching to an override file before you reach for git stash every time.

Short one this week my friend, energy's a bit low on my end, but two kernel vulnerabilities landed that are too important to skip, so let's get into it.

Two old, nasty kernel bugs got public exploits this week. If you're running KVM or any kind of multi-tenant containers, this is a "patch today, not this weekend" situation.

GhostLock (CVE-2026-43499) is a 15-year-old use-after-free bug in the Linux kernel's futex/rtmutex subsystem. It lets an unprivileged local user grab root and escape containers on unpatched systems. This one's been sitting quietly since 2011, affects pretty much every major distro, and researchers have already shown a reliable exploit that gets root in about five seconds. It also breaks container isolation, so if you're self-hosting anything multi-tenant, take this seriously.

Januscape (CVE-2026-53359) is a 16-year-old use-after-free in KVM's shadow MMU implementation. It can let an attacker escape a guest VM and run code on the host, on both Intel and AMD systems. Cloud providers and anyone running untrusted workloads in virtualized environments are the biggest targets, but if you run KVM at home, it's worth checking your patch status too.

Two decade-plus-old bugs surfacing with working exploits in the same week is a good reminder that "old and stable" doesn't mean "safe to ignore."

📚 Worth reading from Linux Handbook

A Postgres instance on a remote server, port 5432 not exposed to the internet (rightly so). How to access it? The fix is SSH tunneling, and this tutorial walks through all three flavors with the actual commands and real use cases behind them.

• Local forwarding (-L) to reach a remote service, like that Postgres box, as if it were running on your own machine
• Remote forwarding (-R) to expose something local, like a webhook receiver on your dev machine, to the outside world through a VPS
• Dynamic forwarding (-D) to turn your SSH connection into a SOCKS proxy for encrypting your traffic on untrusted WiFi

If you've ever wanted to skip standing up a VPN just to reach one service, this is worth ten minutes of your time. Read the full guide.

Also recent, in case you missed them:

• I Like This Fuzzy Search Finder Better Than Find Command in Linux, a quick case for swapping find for fzf in your daily workflow
• These 11 Open Source Tools Completely Improved My Docker Workflow, a practical roundup if you're managing more than a couple of containers

💡Quick terminal tip

Most Linux users know how to extract archives, but tar includes several lesser-known options that can make working with archives safer and more efficient.

Before extracting an archive, inspect its contents:

tar -tf archive.tar.gz

This lists every file and directory inside the archive without extracting anything.

To avoid cluttering your current directory, extract the archive into its own automatically created folder:

tar -xf archive.tar.gz --one-top-level

If you prefer a custom directory name instead, specify it explicitly:

tar -xf archive.tar.gz --one-top-level=archive

Finally, you don't have to extract the entire archive. To restore only specific files or directories, list them after the archive name:

tar -xf archive.tar.gz path/to/file.txt docs/

This is particularly useful when working with large source archives or backups where you only need a handful of files.

🛠️ Tool discovery

Let's find your next favorite software in this section.

DarkMoon: AI-Powered Autonomous Penetration Testing Platform

DarkMoon is an open-source platform that runs full penetration tests using AI agents that plan, execute, and validate real exploits against a target, across web apps, Active Directory, and Kubernetes.

Why use it? Well, manual pentesting takes weeks and a proper consultant costs thousands a day, and Dark-Moon automates that entire loop, from recon to a structured, evidence-backed report, using 50+ integrated tools like Nuclei, sqlmap, and BloodHound under the hood.

It also runs a local privacy gateway that keeps your real IPs, hosts, and credentials from ever reaching the LLM provider. Good fit for DevSecOps pipelines, bug bounty workflows, or just testing your own homelab exposure before someone else does.

You can self-host it or purchase a plan from their website.

GitHub - ASCIT31/Dark-Moon: Autonomous AI pentesting engine, continuous offensive security across web, cloud, AD & Kubernetes. Agentic reasoning + real exploit execution deliver proof-based vulnerabilities. Privacy gateway: the LLM never sees your real IPs, hosts, creds or paths (deterministic placeholders rehydrated locally), nothing leaves your perimeter.

Autonomous AI pentesting engine, continuous offensive security across web, cloud, AD &amp; Kubernetes. Agentic reasoning + real exploit execution deliver proof-based vulnerabilities. Privacy gatewa…

GitHubASCIT31

Dashy: Self-Hosted Dashboard for Homelab and Infrastructure Services

Dashy is an open-source, self-hosted dashboard that provides a unified homepage for accessing infrastructure services, applications, and development tools. It combines link management with service health monitoring, widgets, authentication, and extensive customization, making it a practical landing page for homelabs, self-hosted environments, and DevOps teams managing numerous services.

• 🚦 Service Health Monitoring: Displays real-time availability and status checks for configured applications and services.
• 📊 Rich Widget Ecosystem: Integrates dynamic widgets for self-hosted services, system information, and external APIs to create an operational dashboard.
• 🎨 Highly Customizable UI: Supports multiple themes, icon packs, custom CSS, configurable layouts, and a built-in visual configuration editor.
• 🔍 Fast Navigation: Includes instant search, keyboard shortcuts, multiple pages, and flexible launch options for quickly accessing services.
• 🐳 Easy Deployment: Runs via Docker, Docker Compose, or directly from source, with support for multi-architecture container images.

GitHub - lissy93/dashy: 🚀 A self-hostable personal dashboard built for you. Includes status-checking, widgets, themes, icon packs, a UI editor and tons more!

🚀 A self-hostable personal dashboard built for you. Includes status-checking, widgets, themes, icon packs, a UI editor and tons more! - lissy93/dashy

GitHublissy93

📰 Linux news that matters

• Apple has released version 1.0 of its open-source Container project, a Swift-based tool that runs OCI-compatible Linux containers inside lightweight virtual machines on Apple silicon Macs. The stable release introduces persistent Linux environments through the new container machine command, adopts TOML-based configuration, and adds capabilities such as host-to-container file copying while establishing a stable baseline for future development.
• The German state of Mecklenburg-Vorpommern is expanding its open-source strategy by rolling out a self-hosted Nextcloud platform across state and municipal administration, with a long-term target of more than 50,000 public-sector employees. The initiative replaces Microsoft SharePoint for collaboration, is operated on state-controlled infrastructure, and forms part of a broader digital sovereignty strategy that also includes OpenProject and a locally controlled AI assistant based on OpenWebUI while emphasizing open standards and European technologies.
• AWS has expanded its DevOps Agent with release management capabilities that automatically review code changes, validate dependency impacts and access controls, and execute functional verification in managed environments before software is deployed. The enhancement moves the agent beyond troubleshooting and operations into pre-production quality assurance, positioning it as an AI-assisted release engineer integrated into the software delivery lifecycle.
• Researchers at Noma Security disclosed GitLost, a prompt-injection technique that tricks GitHub Agentic Workflows into reading data from private repositories and publishing it in a public repository comment. The attack requires only a crafted GitHub Issue in a public repository when the organization's AI workflow has read access to private repositories, illustrating how natural-language instructions embedded in untrusted content can override the agent's intended behavior.

😂 Geek humor

💌 Keep on loving Linux Handbook

GitOps course is nearly ready. It should arrive next week.

Perfect time to become a Pro member and enjoy unlimited access to our eBooks, courses and in-depth tutorials.

Missed the previous editions? You can access the newsletter archives.

You may also contribute to Linux Handbook and share your experience and expertise with the community.

I like reading your messages, so just hit the reply button and share your thoughts 😄

There's a moment every Linux user eventually hits, you need to access something on a remote machine, but it's not exposed to the internet. Maybe it's a database running on port 5432, a local web app on port 3000, or a service hidden behind a firewall. The "obvious" solution is to punch a hole in the firewall and expose it. The *right* solution is SSH tunneling.

I started using SSH tunnels out of necessity. I had a PostgreSQL database running on a remote server, and the sysadmin (correctly) refused to open port 5432 to the internet. Someone in the team mentioned that I could just "tunnel through SSH" to access it. I had no idea what that meant. Twenty minutes of reading later, I had it working and I've been using SSH tunnels regularly ever since for everything from accessing remote services to getting around restrictive networks.

I'll walk through what SSH tunneling actually is, how each type works, how I set them up, and importantly, what the risks are and how to stay on the right side of them.

What is SSH Tunneling?

SSH (Secure Shell) is usually thought of as a way to get a remote terminal. But SSH also has the ability to forward ports; it can take network traffic on one port and route it through the encrypted SSH connection to emerge somewhere else entirely.

That's SSH tunneling in a sentence: using an SSH connection as a secure pipe to route other traffic.

The traffic inside that pipe is encrypted by SSH, which means it gets the same protection as your terminal session. A service that has no encryption of its own, an old database, a plain HTTP admin panel, a Redis instance, suddenly gets full TLS-grade protection just because you're reaching it through SSH.

There are three types of SSH tunnels. Understanding which one solves your problem is most of the battle:

Local forwarding: -L tunnel forwards a port on your machine to somewhere the remote server can reach.
Remote forwarding: -R tunnel forwards a port on the remote server to something on your machine.
Dynamic forwarding: SOCKS proxy, -D tunnel turns the SSH connection into a proxy that routes any traffic through the remote.

Let's go through each one the way I actually use them.

Local Port Forwarding: Accessing Remote Services Locally

This is the one I use most. Local forwarding lets me open a port on my laptop and have traffic on that port come out on the remote server, as if I'm connecting from the server itself.

My exact use case: I needed to connect my local database client (DBeaver) to a PostgreSQL instance running on a remote server. Port 5432 was not open to the internet. SSH port 22 was.

ssh -L 5433:localhost:5432 username@remote-server.example.com

Breaking this down: -L tells SSH we're doing local forwarding, 5433 is the port I'm opening on my machine, localhost:5432 is where the traffic should go from the remote server's perspective, lhb@remote-server.example.com is the SSH server I'm tunneling through.

After running this, I opened DBeaver, pointed it at localhost:5433, and it connected to the PostgreSQL instance on the remote server, over an encrypted channel, as if the database were running locally.

The tunnel is active for as long as the SSH session stays open. When you exit, the tunnel closes. If you don't need an interactive shell, just the tunnel - add -N to suppress it:

ssh -N -L 5433:localhost:5432 username@remote-server.example.com

And if you want it to run in the background:

ssh -N -f -L 5433:localhost:5432 username@remote-server.example.com

-f sends the process to the background after authenticating. The tunnel stays open without occupying your terminal.

Here, I have used a Docker PostgreSQL container to show the SSH connection to the remote server.

Remote Port Forwarding: Exposing Your Local Machine to the World

Remote forwarding is local forwarding in reverse. Instead of bringing a remote service to me, I'm pushing something on my machine out to a remote server.

My use case for this: I was developing a webhook receiver locally. The service I needed to receive webhooks from (a payment processor) needed a public URL to send to. My development machine is behind NAT, with no public IP. I had a cheap VPS with a public IP. Remote forwarding solved it.

ssh -R 8080:localhost:3000 username@my-vps.example.com

Here, -R for remote forwarding, 8080 is the port that opens on the remote server, localhost:3000 is where traffic on that remote port gets forwarded, back to my machine, port 3000.

After running this, anyone hitting my-vps.example.com:8080 would have their request tunneled back to port 3000 on my laptop. My local dev server was now reachable from the internet, through an encrypted SSH connection. For the example I have setup the container for the vps as:

The VPS container is running for reverse tunneling for the requests that are coming.

curl from inside the container simulates the external request to the vps:8080 endpoint.

Python server verifying and logging the connected request from the internet that comes to the VPS and then to the localhost:3000

When to use this: Remote forwarding is incredibly useful for quick webhook testing, sharing a local demo with a client, or giving someone remote access to something on your internal network without setting up a VPN.

Dynamic Port Forwarding: SSH as a SOCKS Proxy

Dynamic forwarding is the most flexible of the three. Instead of forwarding a specific port to a specific destination, it creates a SOCKS proxy on your machine. Any application that supports SOCKS proxies can route all its traffic through your SSH connection and it will appear as if that traffic is coming from the remote server.

Command that can be used:

ssh -D 1080 -N yash@remote-server.example.com

This opens a SOCKS5 proxy on localhost:1080 on my machine. Any traffic I route through that proxy goes through the SSH tunnel and exits from remote-server.example.com.

I have used it as:

ssh -f -D 1080 -N \
  -i ~/ITSFOSS/REVIEW/SSH\ Tunneling/docker-demo/demo_key \
  -p 2223 -o StrictHostKeyChecking=no \
  vpsuser@localhost
ss -tlnp | grep 1080

Then I can setup the network proxy through the network settings as:

Then, you need to set up the SOCKS proxy through the network settings.

When to use this: When you are in a coffee shop with WiFi and want to encrypt all your browsing, you need to access something that's only reachable from a specific server (e.g., an internal admin panel that only allows connections from the VPS's IP), or you want to test how your website looks from the perspective of another geographic location.

Making Tunnels Persistent

Running long ssh -L ... commands every time is annoying. I put my common tunnels in ~/.ssh/config so I can activate them with a short alias:

Host db-tunnel
    HostName remote-server.example.com
    User yash
    LocalForward 5433 localhost:5432
    ServerAliveInterval 60
    ServerAliveCountMax 3

Host socks-proxy
    HostName my-vps.example.com
    User yash
    DynamicForward 1080
    ServerAliveInterval 60
    ServerAliveCountMax 3

Now activating the database tunnel is just:

ssh -N db-tunnel

And the SOCKS proxy:

ssh -N socks-proxy

The Risks And How to Handle Them

SSH tunneling is powerful, and like most powerful tools, it can cause problems if misused or misconfigured. This is the part most tutorials skip.

Risk 1: Unauthorized Tunnel Creation

The flip side of remote forwarding (-R) is that if someone has SSH access to your server, they can open tunnels out of it, potentially bypassing your network security controls. An attacker with a compromised SSH key could use your server as a relay to reach systems inside your network.

Mitigation: Restrict what SSH users can do. In /etc/ssh/sshd_config:

# Disable port forwarding for all users by default
AllowTcpForwarding no
GatewayPorts no

# Then allow it only for specific trusted users:
Match User deploy-user
    AllowTcpForwarding local

Use SSH keys (not passwords), enforce key-based auth only, and audit your ~/.ssh/authorized_keys files regularly.

Risk 2: Tunnel Misuse on Corporate/Managed Networks

Dynamic SSH tunneling (-D) is a common technique for bypassing network monitoring and content filters. On a corporate or university network, using a SOCKS proxy to route traffic through an external server may violate acceptable use policies, even if you have a legitimate reason.

I use it when I'm on untrusted public WiFi to protect my own traffic, which is reasonable. Using it to bypass your employer's security controls on company equipment is a different matter; read your acceptable use policy, and don't be surprised if your IT team can see that you're making an encrypted SSH connection to an external server even if they can't see inside it.

Risk 3: Exposing Tunnels Beyond Localhost

When you run -L 5433:localhost:5432, by default the tunnel binds to 127.0.0.1 on your machine, only you can use it. But if you bind it to 0.0.0.0, anyone on your local network (or beyond) can use that forwarded port to reach the remote service.

# DANGEROUS — binds to all interfaces
ssh -L 0.0.0.0:5433:localhost:5432 user@remote-server.example.com

Unless you specifically need to share a tunnel with other people on your network, always let the tunnel bind to 127.0.0.1 (the default). You can explicitly enforce this:

# Safe — explicitly binds to loopback only
ssh -L 127.0.0.1:5433:localhost:5432 user@remote-server.example.com

Risk 4: Keeping SSH Keys Secure

All of this relies on the security of your SSH keys. If your private key is stolen, your tunnels and everything behind them are compromised.

My key hygiene: Use ssh-keygen -t ed25519 for new keys, as Ed25519 keys are smaller, faster, and considered stronger than RSA-4096 for most use cases, always set a passphrase on private keys, use ssh-agent to avoid retyping the passphrase constantly while keeping the key protected at rest, never share private keys or put them in version control.

# Generate a new Ed25519 key with a passphrase
ssh-keygen -t ed25519 -C "yash@workstation" -f ~/.ssh/id_ed25519_tunnel

# Add it to ssh-agent so you don't retype the passphrase every session
ssh-add ~/.ssh/id_ed25519_tunnel
```

A Quick Reference: When to Use Which Tunnel

Wrapping Up

What I like about SSH tunneling is that it solves real problems without adding infrastructure. No VPN server to configure, no WireGuard keypairs to exchange, no nginx proxy rules to write. The SSH connection you already use for server access can also carry your database traffic, your webhook traffic, or your browsing traffic, all encrypted, all without opening extra firewall ports.

Local forwarding (-L) is the one I reach for most often, any time I need to access a service on a remote machine from a local client. Remote forwarding (-R) is what I use when I need to do the reverse: expose something local to the internet temporarily. Dynamic forwarding (-D) is the occasional privacy tool for when I'm not on a network I trust.

The risks are real but manageable: keep port forwarding locked down on your SSH servers, bind tunnels to localhost unless you have a specific reason not to, and treat your SSH keys with the same care you'd give a password.

The setup is one command. The maintenance is minimal. The usefulness compounds the more remote infrastructure you work with.