Securing Your First Linux Server: A Guide to Root Accounts and Encrypted Data

Failed password for root from 116.31.116.50 port 38914 ssh2

I still remember staring at /var/log/auth.log as that exact line repeated hundreds of times a minute. It was 2012, and I was working at a small agency in the Netherlands. I had just exposed my very first bare-metal server to the internet with PermitRootLogin yes enabled. Looking back, I obviously should have actually read the sshd documentation. Instead, I blindly ran bash scripts I found on StackOverflow—you know exactly how it goes when you’re starting out.

Fast forward 14 years, and setting up a secure foundation is mostly muscle memory. Though honestly? I still second-guess myself sometimes. Right now, I’m testing out the RHEL 10 beta. If you’re curious about practicing with RHEL 10 yourself, I’ve written about How to Build a Zero-Cost RHEL 10 Practice Lab Using VirtualBox separately. I have to say, the Anaconda installer makes baseline security so much easier than the old days when you had to manually wrestle with every single configuration file.

When you hit the Installation Summary page, the virtual disk shows up as sda. Scroll down to Encryption, and there’s a dead-simple “Encrypt my data” checkbox. This relates to something I covered in Automatic vs. Manual Partitioning in Linux: Which Should You Choose?—the installer handles partitioning choices seamlessly here too. And I mean simple. I vividly remember my first time trying full disk encryption on a production server. I was absolutely terrified it would completely break my automated provisioning. It sounds silly in hindsight, but the anxiety was completely real. Now, the encryption just works seamlessly across all partitions—like having a security blanket that actually does its job. You enter your passphrase, and the bootloader automatically handles the decryption at startup.

There is one catch, though: this setup won’t work for unattended remote reboots. For that, I rely on Clevis and Tang. I usually configure them post-install using Ansible 2.15. It definitely takes some extra legwork to get right, but it’s totally worth the effort.

Next up is the root account setup. The installer throws a warning that root has full, unrestricted system access. Anaconda happily lets you set the root password, but the smart play here? Only use it for local admin tasks. Lock down and disable remote access right out of the gate. None of this is rocket science, but it’s literally the difference between a server that gets inevitably compromised and one that actually stays secure.

I know this might veer off-topic a bit, but since we’re talking about server hardening… honestly, I think SELinux is massively overrated. I spent years of my life chasing down obscure avc: denied errors. Eventually, I just realized it’s often entirely unnecessary. Even in some pretty high-security environments, I’ve found that having tight container and network policies is more than enough. The reality is that I wasted so much time tweaking SELinux policies that didn’t actually move the needle on our real-world security.

That perspective really solidified for me when I spent an entire month in 2017 just trying to wrap my head around Kubernetes. Managing pod security in that ecosystem showed me something key: strict RBAC and proper network isolation usually outperform traditional host-level controls anyway. That was a massive shift in how I approach security architecture today.

At the end of the day, basic disk encryption and locking down root stop about 90% of our sloppiest mistakes. I’m still not totally sure if RHEL 10 handles custom LVM layouts differently with encryption enabled, though. I guess I’ll find out for sure when I inevitably break my test cluster tomorrow…

🎓 Ready to go deeper?

This article only scratches the surface. If you want the complete, hands-on path — from fundamentals to production-ready skills — enroll in RHCSA Bootcamp (RHEL 10) - Arabic and get structured lessons, labs, and real-world projects.

👉 Enroll now →