Mastering Sudo for Linux Privilege Escalation

Day 7/100 – Setting Up Password-less SSH Authentication in Linux It's Day 7 already. 🎉 Today, I was presented with another real world DevOps challenge; To implement password-less SSH access between a jump host and multiple app servers. The goal was to allow a user (thor) on the jump host to connect to other servers using their respective sudo users without being prompted for a password. This is especially important for scripts that run automatically and need uninterrupted access (like the cron job worked on yesterday). The first thing I did was to generate an SSH key pair using "ssh-keygen -t rsa" and distribute the public key to each app server using "ssh-copy-id". Once that was done, I tested the connections and confirmed that access was successful without any password prompts. Password-less access is essential for cron jobs and scripts. Security is about balance: automation vs controlled access and knowing when each is desired. This is one of those behind-the-scenes setups that makes CI/CD pipelines, remote scripts, and large-scale infrastructure actually work. One day at a time till perfection.🚀 #DevOps #CloudEngineering #Linux #SSH #TechLearning #100DaysOfCode # #SystemAdministration #LearningInPublic

Most Linux systems I come across still default to Bash—and for good reason. It’s stable, predictable, and has been doing the job for decades. But the moment you start working across multiple users or environments, a few limitations become hard to ignore: ⚠️ Minimal auto-suggestions ⚠️ Basic tab completion ⚠️ No built-in plugin ecosystem ⚠️ Prompt customization that quickly turns messy and inconsistent It works—but it doesn’t scale well in terms of user experience or maintainability. That’s usually where ZSH (Z-SHELL) comes in. Better completion, inline suggestions, extensibility—it’s a clear upgrade for anyone spending serious time in the terminal. But switching to ZSH alone doesn’t solve the real problem. You still end up with: ⚠️ Different .zshrc files across users ⚠️ Plugin sprawl ⚠️ Inconsistent prompts ⚠️ No rollback if something breaks In other words, you’ve improved the shell… but not the system around it. Then comes the prompt layer. A lot of people use frameworks, but they tend to be heavy and slow things down. That’s where Starship fits in: ⚡ Fast (written in Rust) ⚡ Consistent across environments ⚡ Clean, informative prompt without overhead Now you have a powerful shell and a modern prompt—but again, only if deployed correctly. This is exactly the gap I explored in my recent write-up: 🔗 https://lnkd.in/gZuy7em3 The focus isn’t just on installing ZSH or adding Starship. It’s about approaching shell environments the same way we approach systems: 🧩 Standardized 🔁 Repeatable 🔄 Reversible Because once you’re managing multiple users, the problem is no longer which shell to use—it’s how to manage it properly. For those interested, the implementation is here: 🔗 https://lnkd.in/g9ANMBpw Curious how others are handling shell standardization across environments—especially when consistency and rollback actually matter. #linux #DevOps #SysAdmin #Developer

🚨 Application working but users still facing issues? Check logs like a pro Sometimes everything looks fine from your side… Service is running ✅ Server is up ✅ But users still report issues 😓 This is where logs become your best friend. --- 🔍 1. Start with application logs 👉 Check inside `/var/log` or app-specific folder 👉 Example: `tail -f /var/log/nginx/error.log` --- 📄 2. Look for keywords 👉 error 👉 failed 👉 timeout 👉 denied --- 🧠 3. Check timestamps 👉 Match logs with issue time 👉 Helps find exact event --- ⚡ 4. Check service logs `journalctl -u nginx` 👉 System-level logs for services --- 🌐 5. Correlate with user issue 👉 What user did? 👉 What happened in logs at same time? --- 🔁 6. Reproduce issue 👉 Try same steps 👉 Watch logs in real-time --- 🧠 Real mindset: Don’t guess ❌ Logs never lie ✅ --- #Linux #LinuxAdmin #DevOps #Troubleshooting #CloudComputing #SystemAdministration #LearningInPublic #ITInfrastructure

Just dropped a new RHCSA-focused blog on something that doesn’t get enough attention… Flatpak (Modern Linux Package Management) If you’re deep into RHCSA prep, you’re probably focused on dnf, RPMs, and repositories (as you should be). But in real-world environments—especially on developer systems—Flatpak shows up more than you might expect. In this article, I break it down in a practical, no-fluff way: - What Flatpak actually is (in plain English) - How it’s different from traditional package management - How to install and manage apps step-by-step - Real examples (Firefox, VS Code, Spotify) - A real-world admin scenario you could see on the job I also walk through how tools like Flathub fit into the ecosystem and why this matters beyond just passing the exam. My goal with this one was simple: Make sure you’re not just “exam ready”… but actually job ready. If you're studying for RHCSA or working in Linux environments, this is worth a quick read. #RHCSA #REDHAT #Linux #CloudWhistler #SysAdmin #DevOps #CyberSecurity

Day 9: MariaDB Troubleshooting | #100DaysOfDevOps with KodeKloud Continuing my DevOps journey with a focus on troubleshooting and debugging 🛠️ Today’s topic: MariaDB Troubleshooting This practice helped me understand how to debug real-world issues when a database service fails to start, and how small misconfigurations can impact system behavior—an essential skill in DevOps environments. 📌 I’ve documented the complete step-by-step process in my blog — check it out here: https://lnkd.in/gFikW6ZB Looking forward to staying consistent and learning in public #DevOps #LearningInPublic #Linux #MariaDB #Troubleshooting #KodeKloud

Day 26/100: Bringing Applications to Life – Linux Service Management ⚙️ Today’s Focus: Yesterday, I learned how to download and install packages like the Apache Web Server (httpd). But installing software is only half the battle—today, I learned how to manage and control those background applications using systemd and the systemctl command! 🛠️ Taking Control with Systemctl: In Linux, background applications are called services (or daemons). I spent today practicing how to manage the lifecycle of the Apache service: systemctl status httpd: The diagnostic tool. I used this to check if my web server was currently running ("active") or turned off ("inactive/dead"). systemctl start httpd: The command to actually ignite the application and get it running in the background. systemctl stop httpd: To gracefully shut the service down. systemctl restart httpd: Essential for applying new configuration changes without bringing the whole server offline. 🔄 Surviving a Reboot: I also learned a crucial DevOps lesson today: just because you start a service doesn't mean it will stay running if the server crashes or reboots! To ensure my web server automatically turns back on after a system reboot, I have to explicitly tell the system to do so using: systemctl enable httpd Why It Matters: Whether it is a web server, a database, or a custom application, a DevOps engineer's job is to ensure high availability. Mastering systemctl is how we ensure critical services stay alive and properly configured! #100DaysOfDevOps #100DaysOfCode #Linux #SystemAdmin #CentOS #Vagrant #Systemctl #DevOpsEngineer #TechJourney #DailyProgress #CloudComputing

Day 28/100: Bundling It Up – Archiving & Compression in Linux 🗜️📦 Today’s Focus: In a real-world DevOps environment, servers generate massive amounts of log files and data (like the Jenkins logs I was working with today!). To save disk space and make transferring files over a network much faster, I learned how to properly archive and compress directories using the Linux CLI. 🛠️ The Tools I Mastered: I practiced bundling multiple files into a single archive and applying compression algorithms to shrink their size: The Mighty tar (Tape Archive): This is the undisputed king of Linux archiving. I learned the classic command flag combinations: tar -czvf archive.tar.gz [directory]: This creates a new archive (-c), compresses it using gzip (-z), shows me the progress verbosely (-v), and outputs it to a file (-f). tar -xzvf archive.tar.gz: The exact opposite! This extracts (-x) the compressed tarball back into a usable directory. I also explored the manual to see other powerful compression options like -j for bzip2 and -J for xz. zip & unzip: I also practiced using the standard zip -r command to recursively compress a directory. While tar is the Linux standard, zip is incredibly useful when I need to share artifacts with Windows environments! Why It Matters: Whether it is backing up application configurations, rotating system logs, or packaging up a build artifact to deploy to a server, we rarely move raw directories around. Compressing everything into a single "tarball" saves bandwidth, storage, and time! ⏳ #100DaysOfDevOps #100DaysOfCode #Linux #Tarball #SysAdmin #CentOS #Vagrant #CLI #DevOpsEngineer #TechJourney #DailyProgress #CloudComputing

Day 22/100: Mastering Identity & Access in Linux 👥 Today’s Focus: After spending the last few days managing files and directories, today I shifted gears into system security and administration. I learned how Linux handles Users and Groups—the core mechanisms that dictate who can log into a server and exactly what they are allowed to do. 🧠 The Core Concepts: In Linux, security is deeply tied to identity: User Accounts: Every user is assigned a unique numerical User ID (UID) and secured with a password. Behind the scenes, the system doesn't care about your username; it only reads the UID! Groups: To make managing permissions easier, users are organized into Groups, each with its own Group ID (GID). Instead of giving 50 individual developers access to a file, you just assign the file to the "developers" group. 🛠️ The Commands I Practiced: I got hands-on in the terminal creating and managing new identities: useradd [username]: The standard command to create a brand new user on the system. passwd [username]: Used immediately after creating a user to assign them a secure login password. groupadd [groupname]: Creating a new group to logically organize my users. usermod -aG [groupname] [username]: The crucial command used to append/add an existing user to a specific group, granting them new file access privileges. Why It Matters: In a DevOps or enterprise environment, you never run applications as the "root" superuser. Understanding how to properly segment users and groups ensures we follow the Principle of Least Privilege, keeping our infrastructure secure and isolated! #100DaysOfDevOps #100DaysOfCode #Linux #SysAdmin #AccessControl #CentOS #Vagrant #CLI #DevOpsEngineer #TechJourney #DailyProgress #CloudComputing

The Complete Linux Sysadmin Toolkit - 118 professional CLI tools for Linux server management, security auditing, performance monitoring, and DevOps operations. One install. All tools. https://lnkd.in/d_e5b__6 #Python #Sysadmins #Toolkit

🚀 From “It’s not working” → to “I can debug it” I recently completed a DNS + Apache Web Server setup on RHEL. But honestly, the biggest learning wasn’t the setup — it was the troubleshooting mindset I built along the way. 🔧 What I worked on: • Configured DNS using BIND (forward & reverse zones) • Hosted a website using Apache • Tested across Windows and Ubuntu clients 🧠 What actually mattered: Instead of just following steps, I started asking: 👉 Why is it not resolving? 👉 Why is Apache showing the default page? 👉 Where exactly is the failure happening? That’s where real learning started. ⚙️ Commands that helped me debug: • systemctl status httpd → Check service status • journalctl -xe → Analyze system errors • ss -tuln | grep :80 → Verify port binding • dig domain.com → Test DNS resolution • firewall-cmd --list-all → Check firewall rules 💡 My troubleshooting flow now: 1️⃣ Check service status 2️⃣ Check logs for errors 3️⃣ Verify port listening 4️⃣ Validate DNS resolution 5️⃣ Check firewall rules Simple steps — but extremely effective in real environments. 📌 Key realization: Linux is not about memorizing commands. It’s about understanding how systems interact. Most real-world issues come down to: → Logs → Networking fundamentals → Service behavior 🌐 GitHub Project: https://lnkd.in/gTpsMqtM If you're learning Linux / DevOps: 👉 Don’t just build projects 👉 Break them, debug them, fix them That’s where real learning happens. #Linux #DevOps #SystemAdministration #DNS #Apache #Troubleshooting #RHCSA #CloudComputing