Linux Fundamentals: Complete Command-Line Mastery Guide for System Administrators (2026)

Reading Time: 20 minutes

Introduction

Picture this: You’re managing 50 production servers at 2 AM when a critical web application goes down. Your mouse won’t help you here. No clicking. No graphical interface. Just you, a black terminal screen, and the Linux command line standing between you and disaster recovery.

This is the reality of professional Linux administration—and exactly why 95% of corporate Linux work happens through CLI (Command Line Interface), not GUI . This comprehensive guide transforms you from mouse-dependent beginner into keyboard-fluent system administrator, covering the fundamental commands and concepts that separate junior admins from senior engineers.

What You’ll Learn:

• Three critical Linux characteristics that define system administration
• The 20% of commands you’ll use 80% of the time (cd, ls, pwd, find, and more)
• Linux file system architecture following Filesystem Hierarchy Standard (FHS)​
• Remote access mastery: SSH authentication best practices for 2026​
• Soft links vs hard links: Advanced concepts explained with real-world scenarios
• Professional troubleshooting workflows using logs, wildcards, and file operations

Prerequisites: Completed Linux installation (CentOS/Ubuntu VM), basic familiarity with terminal access, willingness to embrace keyboard-only workflow.

Three Critical Linux Characteristics Every Admin Must Understand

1. Root Account is All-Powerful (Handle With Extreme Care)

The root account in Linux is the superuser with unrestricted access to every file, process, and system configuration . Root can:

• Create, modify, and delete any user account
• Change system-wide configurations affecting all users
• Install/remove software packages
• Access any file regardless of permissions
• Delete the entire operating system with one wrong command

The danger is real:

rm -rf /          # DO NOT RUN: Recursively deletes entire filesystem from root

Corporate reality: In enterprise environments, direct root login is often disabled entirely. Administrators use regular accounts with sudo (temporary privilege escalation) for accountability and audit trails. Every sudo command is logged with timestamp, username, and exact command executed—critical for compliance and forensics.​

Best practice for learning:

• Create regular user account for daily work
• Use sudo prefix for privileged commands
• Never run rm -rf with wildcards as root without triple-checking paths
• Test dangerous commands on test VMs with snapshots first

2. Case-Sensitive File System (File.txt ≠ file.txt)

Unlike Windows, Linux treats uppercase and lowercase as completely different characters :

touch Report.txt
touch report.txt
touch REPORT.txt
ls
# Output shows: Report.txt  report.txt  REPORT.txt (three separate files!)

Real-world implications :

Command execution:

cd /etc          # Works (lowercase)
cd /Etc          # ERROR: No such file or directory
cd /ETC          # ERROR: No such file or directory

File operations:

cp Config.bak config.txt     # Different files
rm CONFIG.TXT                # Won't delete config.txt

Professional habit: Develop consistent naming conventions early:

• Lowercase everything: Most Linux admins default to lowercase for simplicity
• Use hyphens or underscores: web-server-config.txt or web_server_config.txt (never spaces)
• Avoid mixed case: ConfigFile.txt leads to typos and frustration

Corporate standard: Many organizations enforce lowercase-only naming policies in configuration management systems (Ansible, Puppet) specifically to avoid case-sensitivity confusion.​

3. Command-Line Dominance (GUI is Rare in Production)

Corporate Linux servers run headless (no graphical interface) for critical reasons:​

Performance: GUI desktop environments (GNOME, KDE) consume 1-2GB RAM that could serve applications instead

Security: Fewer installed packages = smaller attack surface. No X11 server means thousands fewer potential vulnerabilities

Remote management: SSH works identically whether server is in data center 1,000 miles away or virtualized in cloud​

Automation: Scripts execute commands precisely—GUI clicking cannot be automated at scale

Enterprise statistics: AWS EC2, Azure VMs, and Google Compute Engine instances default to command-line only access. When managing 50+ servers, you’ll SSH into each—never physically sit at a console .​

Career preparation: Get comfortable with black screen + white text. No mouse dependency. Pure keyboard workflow. This defines professional Linux administration .

Three Absolute Must-Master Commands (Cannot Function Without These)

These three commands form the foundation of Linux navigation—you’ll use them hundreds of times daily.​

1. pwd (Print Working Directory)

Purpose: Shows your current location in the file system​

Syntax: pwd (no arguments needed)

Example:

pwd
# Output: /home/admin/projects/web

Why it matters: In CLI, you can’t see folder icons or address bars. pwd is your GPS—constantly verifying location before executing commands .

Professional use case: Before running rm -rf * (delete everything in current directory), always run pwd first to confirm you’re in the correct location:

pwd                          # Output: /tmp/old-logs (correct location)
rm -rf *                     # Safe to delete

2. cd (Change Directory)

Purpose: Navigate between folders​

Basic syntax: cd /path/to/directory

Essential shortcuts :

cd                # Jump to YOUR home directory from anywhere (~)
cd /              # Go to root directory (filesystem start)
cd ..             # Go up one level (parent directory)
cd ../..          # Go up two levels
cd -              # Return to previous directory (like browser "back" button)
cd ~              # Go to home directory (same as cd with no arguments)

Absolute vs relative paths :

Absolute path (starts with /—works from anywhere):

cd /var/log/httpd          # Direct navigation from any location

Relative path (no leading /—depends on current location):

cd /var                    # First go to /var
cd log                     # Navigate relative to /var → now in /var/log
cd httpd                   # Navigate relative to /var/log → now in /var/log/httpd

Common mistake: Forgetting you’re in wrong directory before using relative path:

pwd                        # Output: /home/admin
cd etc                     # ERROR: /home/admin/etc doesn't exist
cd /etc                    # CORRECT: Absolute path works from anywhere

3. ls -l (List Directory Contents with Details)

Purpose: Display files and folders with complete metadata​

Basic usage:

ls                # Simple list (filenames only)
ls -l             # Long format (detailed information)
ls -la            # Long format + hidden files (starting with .)
ls -ltr           # Long format + sorted by modification time (newest at bottom)

Understanding ls -l output (critical skill for every Linux admin) :

drwxr-xr-x  2  root  root  4096  Dec 19 10:30  Documents
-rw-r--r--  1  admin admin  256  Dec 18 15:22  config.txt

Column-by-column breakdown:

1. File type + permissions: drwxr-xr-x (explained in depth later)
2. Link count: 2 (number of hard links or subdirectories)
3. Owner: root (username owning this file)
4. Group: root (group owning this file)
5. Size: 4096 (bytes—directories show block size, not actual size)
6. Modification time: Dec 19 10:30 (last changed date/time)
7. Name: Documents (filename or directory name)

Professional comparison to Windows :

Key insight: In Windows, one double-click performs 3 actions (navigate + display contents + show location). In Linux CLI, you explicitly command each step .

Linux File System Architecture: Understanding the Hierarchy

The Linux file system follows a tree-like hierarchical structure governed by the Filesystem Hierarchy Standard (FHS), maintained by the Linux Foundation. Understanding this structure is fundamental to system administration.​

What is a File System? (Real-World Analogy)

A file system is organizational storage—like organizing a closet :

Disorganized closet (no file system):

• Shirts, pants, shoes, accessories thrown in one pile
• Finding jeans = digging through entire closet for 15 minutes
• No categories, no structure

Organized closet (file system):

• Shirts → Top shelf
• Pants → Middle drawer
• Shoes → Bottom rack
• Accessories → Side compartment
• Finding jeans = Open middle drawer (5 seconds)

Linux file system logic: System configuration files → /etc, user files → /home, logs → /var/log, commands → /usr/bin. Each category has a dedicated, standardized location for instant retrieval.​

The Root Directory: Starting Point of Everything

/ (root directory) is the topmost directory in the Linux hierarchy—everything branches from here.​

Visualization:

/                           ← Root (starting point)
├── boot                    ← Bootloader files
├── etc                     ← Configuration files
├── home                    ← User directories
├── root                    ← Root user's home
├── var                     ← Variable data (logs)
└── usr                     ← User programs
    ├── bin                 ← User commands
    └── sbin                ← System admin commands

Critical distinction: / (root directory) ≠ /root (root user’s home directory). This confuses many beginners.​

Critical Directory Structure: The 20% You’ll Use 80% of the Time

These directories appear in every Linux distribution and form the foundation of system administration.​

/ (Root Directory)

Definition: Starting point of entire file system—everything branches from here​

Navigation:

cd /              # Always brings you to root directory from any location
ls /              # Shows top-level directories (boot, etc, home, var, usr)

/boot

Purpose: Contains GRUB bootloader and kernel files​

Critical file: /boot/grub2/grub.cfg tells system which OS/kernel to start on power-on

Real-world scenario: Corrupted /boot = unbootable system requiring rescue mode recovery

Contents:

ls -lh /boot
# Typical contents:
# vmlinuz-5.14.0-503.el9.x86_64    ← Linux kernel
# initramfs-5.14.0-503.el9.x86_64  ← Initial RAM filesystem
# grub2/grub.cfg                   ← Boot configuration

Warning: Never manually delete files from /boot unless you’re 100% certain—one wrong deletion prevents system boot .

/etc (Configuration Files Central)

Purpose: ALL system and application configuration files​

Critical rule: ALWAYS backup before editing

# Before editing any config:
sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.backup.$(date +%F)

Common configuration locations :

• Email server: /etc/postfix/main.cf
• Network settings: /etc/sysconfig/network-scripts/ (CentOS 7) or /etc/NetworkManager/ (CentOS 8+)
• DNS resolver: /etc/resolv.conf
• SSH server: /etc/ssh/sshd_config
• Web server (Apache): /etc/httpd/conf/httpd.conf
• Firewall: /etc/firewalld/ or /etc/sysconfig/iptables

Real-world troubleshooting: When any service fails, check /etc first for misconfigured settings .

/home (User Directories)

Purpose: Regular user personal directories​

Structure:

/home/admin      ← admin user's home
/home/developer  ← developer user's home
/home/john       ← john user's home

Windows equivalent: C:\Users\

Critical exception: Root user’s home is /root, NOT /home/root​

User isolation: Each user can only access their own /home/username directory by default (unless explicitly granted permissions) .

/root (Root User’s Home Directory)

Purpose: Root user’s personal home directory​

Access:

su -              # Become root user
pwd               # Output: /root (automatically lands here)

Common confusion (three meanings of “root”) :

1. root (account): Username with ultimate system privileges
2. / (root directory): First directory in filesystem hierarchy
3. /root (root’s home): Root user’s personal home directory

Clarification scenarios :

• “Go to root directory” → cd /
• “Go to root home directory” → cd /root
• “Become root” → su - (switch user to root account)

/var/log (System and Application Logs)

Purpose: ALL system and application logs—troubleshooting starts here​

Critical logs every admin must know :

/var/log/messages         # General system logs (CentOS/RHEL)
/var/log/syslog           # General system logs (Ubuntu/Debian)
/var/log/secure           # Authentication/authorization logs (login attempts, sudo)
/var/log/httpd/           # Apache web server logs
    ├── access_log        # Successful HTTP requests
    └── error_log         # Web server errors
/var/log/mariadb/         # Database logs
/var/log/firewalld        # Firewall logs

Real-world troubleshooting workflow :

Problem: Web server down

Solution path:

sudo tail -f /var/log/httpd/error_log
# Shows real-time errors as they occur
# Common findings: Permission denied, syntax error in config, port already in use

Problem: User cannot log in via SSH

Solution path:

sudo tail -20 /var/log/secure
# Shows recent authentication attempts
# Common findings: Failed password, public key rejected, account locked

Pro tip: Use tail -f for real-time log monitoring (follows log as new entries append) .

/usr/bin (User Commands)

Purpose: Everyday commands available to all users​

Common commands located here:

ls /usr/bin/
# Contains: ls, cd, pwd, cat, grep, awk, sed, vim, nano, git, python3, etc.

Modern Linux note: /bin is now a symbolic link pointing to /usr/bin (merged in recent distributions for simplification).​

/usr/sbin (System Administration Commands)

Purpose: System-level administration tools​

Difference from /usr/bin:

• /usr/bin = regular user commands
• /usr/sbin = system administration tasks requiring elevated privileges

Common sysadmin commands:

ls /usr/sbin/
# Contains: fdisk, mkfs, ip, firewall-cmd, useradd, systemctl, etc.

/tmp (Temporary Scratch Space)

Purpose: Temporary files cleared on reboot​

Characteristics:

• All users have write access
• Automatically cleared on system reboot (no persistent storage)
• No backup significance

Use case :

cd /tmp
wget https://example.com/installer.tar.gz    # Download installer
tar -xzf installer.tar.gz                    # Extract
./installer/install.sh                       # Run installation
rm -rf installer*                            # Clean up (or reboot clears automatically)

/dev (Device Files)

Purpose: Hardware devices represented as files​

“Everything is a file” philosophy in action :

ls -l /dev/
# Common devices:
/dev/sda          # First hard disk
/dev/sda1         # First partition on first disk
/dev/sdb          # Second hard disk (usually USB drives)
/dev/cdrom        # CD/DVD drive
/dev/null         # Bit bucket (discards all data written to it)
/dev/zero         # Provides infinite stream of null bytes
/dev/random       # Random number generator

Real-world usage:

# Copy disk image to USB drive
sudo dd if=ubuntu.iso of=/dev/sdb bs=4M status=progress

/proc (Process Information)

Purpose: Virtual filesystem exposing kernel and process information​

Key characteristics:

• Size on disk: 0 bytes (doesn’t physically exist—created dynamically by kernel in RAM)
• Disappears on shutdown
• Updates in real-time

Useful files :

cat /proc/cpuinfo         # Detailed CPU information
cat /proc/meminfo         # Memory usage statistics
cat /proc/version         # Kernel version
ls /proc/                 # Shows numbered directories (each is a running process ID)

File and Directory Operations: Hands-On Command Mastery

Creating Files: Three Essential Methods

Method 1: touch command (creates empty file):​

touch report.txt                    # Single file
touch file1.txt file2.txt file3.txt # Multiple files in one command

Method 2: cp command (copy existing file = creates new file):​

cp source.txt destination.txt
cp /etc/ssh/sshd_config /root/sshd_config.backup

Method 3: vim/vi editor (create + edit simultaneously) :

vim notes.txt              # Opens editor, creates file when you save
# Press i → Type content → Press Esc → Type :wq! → Press Enter

Verification best practice: Always run ls -ltr after creation (shows newest files at bottom) :

touch newfile.txt
ls -ltr                    # newfile.txt appears at bottom (most recent)

Creating Directories

Single directory:​

mkdir projects             # Creates 'projects' folder

Multiple directories simultaneously:​

mkdir dir1 dir2 dir3       # Creates 3 folders in one command

Nested directories (create parent + subdirectories) :

mkdir -p /home/admin/projects/web/html/css
# -p flag creates ALL parent directories if they don't exist
# Without -p, you'd get "No such file or directory" error

Real-world example:

# Organize web project structure
mkdir -p ~/projects/webapp/{frontend,backend,database,docs}
tree ~/projects/webapp/
# Output:
# webapp/
# ├── backend
# ├── database
# ├── docs
# └── frontend

Permission Errors When Creating Files

Problem: “Permission denied” when creating files in system directories :

$ touch /etc/test.conf
# ERROR: touch: cannot touch '/etc/test.conf': Permission denied

Solution: Become root or use sudo :

# Option 1: Become root
su -
touch /etc/test.conf       # SUCCESS (root can write anywhere)

# Option 2: Use sudo (recommended)
sudo touch /etc/test.conf  # SUCCESS (temporary privilege escalation)

Copying Directories: The Recursive Flag

Regular file copy:​

cp source.txt destination.txt      # Works for files

Directory copy REQUIRES -R (recursive) :

cp -R /home/admin/config /tmp/config-backup
# -R copies directory + all subdirectories + all files within subdirectories

Without -R flag → Error :

cp /home/admin/projects /tmp/
# ERROR: cp: omitting directory '/home/admin/projects'

Real-world use case: Backup /etc before editing configs :

sudo cp -R /etc /root/etc-backup-$(date +%F)
# Creates: /root/etc-backup-2025-12-20/
# Now safe to edit /etc files—can restore from backup if broken

Recursive explained: -R copies the entire directory tree structure, preserving hierarchy and all nested content .

Finding Files: Two Essential Commands

find Command (Searches File System Directly)

Purpose: Searches filesystem in real-time​

Basic syntax:

find /starting/path -name "filename"

Examples :

find . -name "config.txt"                    # Search current directory (.)
find /home/admin -name "*.log"               # Find all .log files
find / -name "sshd_config"                   # Search entire system from root
find /etc -name "*.conf" -type f             # Only files (not directories)
find /var/log -name "*.log" -mtime -7        # Modified in last 7 days

Common problem: “Permission denied” spam when searching / as regular user :

$ find / -name "network-config"
# Hundreds of lines:
# find: '/root': Permission denied
# find: '/etc/polkit-1': Permission denied
# ...spamming screen

Solution: Become root before system-wide searches :

sudo find / -name "network-config"           # Now works without errors

Real-world scenario: Find network configuration file :

# CentOS 7 network configs
sudo find /etc -name "ifcfg-*"
# Output: /etc/sysconfig/network-scripts/ifcfg-ens33

# CentOS 8+ network configs
sudo find /etc -name "*.nmconnection"
# Output: /etc/NetworkManager/system-connections/ens33.nmconnection

locate Command (Searches Database – MUCH Faster)

Advantage: 10-100× faster than find (searches prebuilt database, not actual disk)

Disadvantage: Database updates every ~24 hours → newly created files won’t appear until next update

Basic usage :

locate filename                              # Instantly searches entire system

Example demonstrating database limitation :

touch newfile.txt                            # Create file RIGHT NOW
locate newfile.txt                           # Returns nothing (database outdated)

sudo updatedb                                # Manually update database (takes 30-60 sec)
locate newfile.txt                           # Now finds it instantly!

When to use each tool :

Pro tip: Run sudo updatedb in hourly cron job for accurate locate results :

# Add to /etc/crontab
0 * * * * root /usr/bin/updatedb

Wildcards: Batch Operations Productivity Power Tool

Wildcards substitute characters in filenames—essential for batch operations.​

Three Core Wildcards

1. * (asterisk/star) – Matches zero or more characters :

ls ab*                    # Lists: abc, abcd, ab123, ab (anything starting with "ab")
rm *.log                  # Deletes: error.log, system.log, access.log (all .log files)
cp /etc/*.conf /backup/   # Copies ALL .conf files from /etc to /backup

2. ? (question mark) – Matches exactly ONE character :

ls file?.txt              # Matches: file1.txt, fileA.txt (NOT file12.txt—too many chars)
rm test?.log              # Deletes: test1.log, testX.log (NOT test12.log)

3. [] (brackets) – Matches any character within range :

ls file[123].txt          # Matches: file1.txt, file2.txt, file3.txt (only these three)
rm log[A-Z].txt           # Deletes: logA.txt, logB.txt ... logZ.txt (uppercase letters)
ls [aeiou]*               # Lists files starting with vowels

Real-World Batch Operations

Create 9 files in one command (curly braces wildcard) :

touch report{1..9}.txt
ls
# Output: report1.txt  report2.txt  report3.txt ... report9.txt

touch file{a..z}.log
# Creates: filea.log, fileb.log, filec.log ... filez.log

Delete all files starting with specific prefix :

ls temp*                  # ALWAYS preview with ls first!
# Output: temp1  temp_old  tempfile.txt

rm temp*                  # Now delete after confirming list is correct

List files ending with specific extension :

ls *XYZ                   # Lists: fileXYZ, reportXYZ, dataXYZ

Safety check workflow (CRITICAL for production) :

# Step 1: Preview what will be affected
ls ab*                    # Check list carefully

# Step 2: Confirm list is exactly what you want

# Step 3: Execute actual operation
rm ab*

❌ NEVER run rm * without checking ls * first—one wrong wildcard can delete entire directories .

Understanding File Types: The Seven Types

First character in ls -l output indicates file type :

Example output breakdown :

ls -l /dev/sda /etc /bin
lrwxrwxrwx  1 root root    7 Dec 15 /bin -> usr/bin        ← Symbolic link
drwxr-xr-x 142 root root 8192 Dec 19 /etc                  ← Directory
brw-rw----  1 root disk 8, 0 Dec 19 /dev/sda               ← Block device

Interview question: “What does a file starting with ‘c’ in ls -l output represent?”

Answer: Character device file representing hardware like keyboards or serial ports, located in /dev/, handles data character-by-character rather than in blocks.

Soft Links vs Hard Links: Advanced Concepts Explained

Understanding Inodes First

Inode = Unique number assigned to each file on disk

• Human sees: “report.txt” (filename)
• Computer sees: “12345678” (inode number—like a social security number for files)

Check inode numbers :

ls -li                    # -i flag shows inode numbers
# Output: 524312 -rw-r--r-- 1 admin admin 256 Dec 19 file.txt
#         ^^^^^^ (inode number)

Soft Link (Symbolic Link)

Definition: Shortcut that points to original file’s name

Critical behavior: If original file deleted → soft link breaks (becomes “orphaned”)

Create soft link:​

ln -s /home/admin/original.txt /tmp/shortcut.txt
# -s flag = soft link (symbolic)

Visual representation :

Soft Link → Original File → Inode
(shortcut)  (myfile.txt)   (12345)

If myfile.txt deleted → Soft Link breaks (points to nothing)

Real-world use case: Desktop shortcut to frequently accessed log :

ln -s /var/log/httpd/access_log ~/Desktop/weblog
# Now viewing ~/Desktop/weblog shows real-time /var/log/httpd/access_log contents

Identifying soft links: ls -l shows → arrow pointing to target :

ls -l ~/Desktop/
lrwxrwxrwx  1 admin admin  27 Dec 19 weblog -> /var/log/httpd/access_log

Hard Link

Definition: Additional name pointing directly to file’s inode

Critical behavior: If original file deleted → hard link STILL works (data remains accessible)

Create hard link :

ln /home/admin/original.txt /tmp/backup.txt
# No -s flag = hard link

Visual representation :

Original File → Inode (12345)
       ↑          ↑
Hard Link --------'

If Original File deleted → Hard Link still points to Inode (data intact)

Soft Link vs Hard Link: Verification Test

Test soft link behavior :

echo "Important data" > original.txt
ln -s original.txt softlink.txt
cat softlink.txt                  # Output: Important data ✅
rm original.txt
cat softlink.txt                  # ERROR: No such file or directory ❌ (link broken)

Test hard link behavior :

echo "Critical info" > original.txt
ln original.txt hardlink.txt
cat hardlink.txt                  # Output: Critical info ✅
rm original.txt
cat hardlink.txt                  # Output: Critical info ✅ (still works!)

Inode comparison :

ls -li
524312 -rw-r--r-- 2 admin admin 13 Dec 19 original.txt
524312 -rw-r--r-- 2 admin admin 13 Dec 19 hardlink.txt  # ← Same inode! (524312)

524400 lrwxrwxrwx 1 admin admin 12 Dec 19 softlink.txt -> original.txt  # ← Different inode!

Notice: Hard links share same inode (524312), soft link has different inode (524400) .

When to Use Each Link Type

Production use case: Keep old config after upgrade :

# Option 1: Regular copy (doubles disk usage)
cp /etc/app/config.xml /etc/app/config.xml.v1      # Uses 2× disk space

# Option 2: Hard link (same disk space)
ln /etc/app/config.xml /etc/app/config.xml.v1      # Uses same inode, no extra space!
# Hard link = instant backup without doubling disk usage

Remote Access Deep Dive: SSH Best Practices for 2026

Two Ways to Access Linux Systems

Modern reality (2026): Windows 10+ includes built-in OpenSSH client—PuTTY no longer required. Simply open Command Prompt or PowerShell:​

ssh admin@192.168.1.22

SSH Security Best Practices (2026 Standards)

Following Google Cloud and industry-standard security practices:​

1. Disable password authentication immediately​

Problem: Attackers automate bots to hammer servers with password guesses 24/7 (brute force attacks)​

Solution: Enforce key-based authentication using public key infrastructure:

# On Linux server:
sudo vi /etc/ssh/sshd_config
# Change: PasswordAuthentication yes
# To:     PasswordAuthentication no
sudo systemctl restart sshd

Why it works: Cryptographic keys are computationally infeasible to guess—removes majority of automated threats.​

2. Always use two-factor authentication (2FA)​

Even best private key can be compromised (stolen laptop, insecure storage). 2FA is essential backup:​

# Install Google Authenticator PAM module
sudo yum install google-authenticator-libpam -y    # CentOS/RHEL
sudo apt install libpam-google-authenticator -y    # Ubuntu

# Run setup as each user
google-authenticator

# Configure /etc/pam.d/sshd and /etc/ssh/sshd_config
# (Full tutorial: man google-authenticator)

3. Audit SSH key sprawl regularly​

Review and revoke old or forgotten private-key access:

# Check authorized keys for your account
cat ~/.ssh/authorized_keys
# Remove unknown or old keys

# For all users (as root):
sudo find /home -name "authorized_keys" -exec grep -H . {} \;

4. Shield servers from public internet​

Don’t expose SSH port 22 directly to internet:

• Change default port (security through obscurity—mild deterrent):bashsudo vi /etc/ssh/sshd_config # Change: Port 22 # To: Port 2222
• Use VPN or bastion host (jump server) for SSH access
• Implement firewall rules allowing SSH only from known IP ranges
• Consider AWS Systems Manager Session Manager or GCP IAP for SSH access without exposed ports​

5. Use ephemeral SSH keys for automation​

For CI/CD pipelines and automated processes:

• Generate short-lived keys (expires after 1 hour or 1 day)
• Avoid long-lived service account keys
• Use cloud provider IAM roles when possible (AWS EC2 Instance Connect, GCP OS Login)

Getting Your Linux VM’s IP Address

Before connecting via SSH, you need the VM’s IP address :

CentOS 7:

ifconfig
# Look for interface ens33, enp0s3, or eth0
# Note IP under "inet" (e.g., 192.168.116.128)

CentOS 8+ / Ubuntu:

ip addr show
# Look for interface ens33 or enp0s3
# Note IP after "inet" (e.g., 10.0.2.15/24 → IP is 10.0.2.15)

AWS EC2 instance:​

# Public IP for SSH from internet:
curl http://169.254.169.254/latest/meta-data/public-ipv4

# Private IP for internal VPC communication:
curl http://169.254.169.254/latest/meta-data/local-ipv4

SSH Connection Workflow

Windows 10/11 Command Prompt :

ssh admin@192.168.1.22
# Prompts for password
# Enter password (cursor won't move—normal security behavior)
# Connected! Command prompt appears: [admin@centos-lab ~]$

Advanced SSH options :

bashssh -l admin 192.168.1.22              # -l specifies username
ssh admin@192.168.1.22 -p 2222         # -p specifies custom port
ssh -i ~/.ssh/mykey.pem admin@10.0.0.5 # -i specifies private key file

Mac Terminal / Linux :

ssh admin@192.168.1.22
# Same workflow as Windows 10+

First connection warning :

The authenticity of host '192.168.1.22 (192.168.1.22)' can't be established.
ECDSA key fingerprint is SHA256:xxxxxxxxxxxxxxxxxxxxxxxxxxx.
Are you sure you want to continue connecting (yes/no/[fingerprint])?

Type yes and press Enter (normal security prompt for first-time connections) .

Command Prompt Anatomy: Understanding What You’re Looking At

Typical Linux prompt :

root@myserver#           ← Root user logged in
admin@ubuntu-lab$        ← Regular user logged in

Prompt structure breakdown :

[username]@[hostname][prompt_symbol]
    ↓          ↓           ↓
  admin   ubuntu-lab      $

• Username: Currently logged-in user (root, admin, john, etc.)
• @: Separator
• Hostname: Computer name on network
• Prompt symbol:
  • # (hash) = Logged in as root (danger zone—unlimited power)
  • $ (dollar) = Logged in as regular user (safer)

Verify your identity anytime :

whoami                    # Shows current username
hostname                  # Shows computer name
pwd                       # Shows current directory

Getting Stuck Prompt Back: Critical Recovery Skill

Scenario: You run a command and prompt doesn’t return—keyboard input does nothing .

Solution: Press Ctrl+C to kill current process and return prompt .

Common stuck scenarios :

Example 1: Incomplete command

cat                       # Hit Enter accidentally without filename argument
                          # Cursor just blinks, no prompt appears
                          # System waiting for input from stdin
# Press Ctrl+C to return prompt ✅

Example 2: Long-running process

top                       # Real-time CPU monitor - screen keeps updating forever
# Press Ctrl+C to exit and get prompt back ✅

Example 3: Typo with pipes

ls -l |                   # Forgot to complete pipe command
>                         # Stuck on redirect symbol (waiting for rest of command)
# Press Ctrl+C to abort ✅

Rule of thumb: Anytime you don’t see # or $ prompt → Ctrl+C brings it back .

Changing Passwords: Security Fundamental

Command: passwd [username]

• No username = Changes YOUR password
• With username = Changes that user’s password (root-only privilege)

Change your own password :

passwd
# Prompts for:
# 1. Current password (verification you're authorized)
# 2. New password
# 3. Retype new password (confirmation to prevent typos)

Password complexity requirements :

• Minimum 8 characters (many systems require 12-16)
• Cannot match dictionary words
• Must not be sequential (12345678, abcdefgh rejected)
• Mix letters + numbers + symbols strongly recommended
• Cannot reuse recent passwords (system tracks last 5-10)

Root changing another user’s password :

su -                      # Become root first
passwd admin              # Changes admin's password
# Only prompts for NEW password (skips current password verification—root is all-powerful)

Error: “Only root can specify a username” :

$ passwd john             # ❌ ERROR (regular user can't change others' passwords)
$ su -                    # Switch to root
# passwd john             # ✅ SUCCESS

First login best practice: Immediately change default password provided by administrator . Default passwords are:

• Often weak (Password123!)
• Shared via insecure email
• Known to multiple people (entire IT team)

Key Career Connections & Transferable Skills

Linux Fundamentals → Cloud/DevOps

These Linux fundamentals directly translate to modern cloud and DevOps roles:​

AWS EC2 instances:​

• SSH remote access = identical PuTTY/Terminal workflow
• /var/log/ troubleshooting = Amazon CloudWatch Logs navigation (same log analysis skills)
• File permissions = AWS IAM role policies (same security principles: least privilege, separation of duties)
• EC2 instance types = resource allocation decisions (same RAM/CPU considerations as VM sizing)

Docker containers:

• Container filesystem = Linux filesystem hierarchy (identical /etc, /var, /tmp structure)
• docker exec -it container bash = SSH into container (uses same Linux commands)
• Dockerfile COPY instructions = understanding source/destination paths (absolute vs relative)

Kubernetes pods:

• kubectl exec -it pod -- /bin/bash = SSH equivalent for containers
• ConfigMaps stored in /etc/config within pods
• Log aggregation from /var/log in containers (same troubleshooting workflow)

CI/CD pipelines (Jenkins, GitLab):

• Build agents run on Linux servers
• Pipeline scripts navigate /home/jenkins/workspace/ using cd, ls, pwd
• Artifacts copied with cp -R and wildcards
• SSH deployments to production servers

Common Beginner Mistakes (Avoid These Pitfalls)

❌ Mistake 1: Using Spaces in Filenames

touch my file.txt         # ❌ Creates TWO files: "my" and "file.txt"

# ✅ Correct approaches:
touch my-file.txt         # Use hyphens
touch my_file.txt         # Or underscores
touch "my file.txt"       # Or quotes (but avoid spaces entirely in practice)

Why avoid spaces: Every command treating filename as argument requires quotes—tedious and error-prone .

❌ Mistake 2: Confusing / with /root

cd /                      # Goes to root directory (filesystem start) ✅
cd /root                  # Goes to root user's home (requires root privileges) ✅
# These are NOT the same!

Clarification :

• / = Top of filesystem hierarchy (like C:\ in Windows)
• /root = Root user’s personal home directory (like C:\Users\Administrator)

❌ Mistake 3: Running rm * Without Verifying

cd /important/data
rm *.tmp                  # ❌ Typo: meant *.txt, deleted wrong files

# ✅ Always preview first:
ls *.tmp                  # Verify list carefully
rm *.tmp                  # Then delete after confirming

Production horror story: rm -rf * run in wrong directory deleted entire codebase (no backups) .

❌ Mistake 4: Editing /etc Configs Without Backup

vi /etc/ssh/sshd_config   # ❌ Edit directly (DANGEROUS—one typo locks you out forever)

# ✅ Correct workflow:
sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.backup.$(date +%F)
sudo vi /etc/ssh/sshd_config       # Now safe to edit
sudo systemctl restart sshd        # Test changes
# If broken: sudo cp /etc/ssh/sshd_config.backup.2025-12-20 /etc/ssh/sshd_config

❌ Mistake 5: Forgetting Case Sensitivity

bashcd /Etc                   # ❌ ERROR: No such directory
cd /etc                   # ✅ Correct (lowercase)

cat Config.txt            # ❌ Won't open config.txt
cat config.txt            # ✅ Correct

Professional habit: Default to lowercase everything (filenames, directories, commands) .

❌ Mistake 6: Weak Root Password “Because It’s Just a Lab”

# ❌ Wrong: passwd → enter "123456"
# Problem: Develops bad security habits that carry into production

Why it matters even in labs :

• Muscle memory—you’ll type weak passwords in production too
• If you accidentally bridge VM to network, weak password = instant compromise
• Security mindset must be practiced, not just learned theoretically

✅ Fix: Use password manager (KeePass, Bitwarden) even for lab VMs

• Lab passwords: 12+ characters minimum
• Example: RedHat2026!Lab#Secure

Hands-On Practice: 5-Day Mastery Progression

Day 1: SSH Setup + Basic Navigation

# From Windows/Mac host, SSH into your CentOS/Ubuntu VM
ssh admin@192.168.1.22
whoami; hostname; pwd                # Verify connection
cd /; ls -l                          # Explore root directory
cd /etc; ls -l | more                # Explore configs (press Space to page)
cd /var/log; ls -ltr                 # Check logs (newest at bottom)

Day 2: File/Directory Creation

cd ~                                 # Go to home directory
mkdir projects backups temp          # Create organizational folders
touch projects/app{1..5}.py          # Create 5 Python files instantly
cp projects/app1.py backups/app1.backup
ls -lR                               # Recursive list (see all subdirectories)

Day 3: Wildcards + Finding

touch test{A..Z}.log                 # Create 26 log files
ls test[AEI]*.log                    # Practice bracket wildcards
rm test[P-Z]*.log                    # Delete P through Z only
find ~ -name "*.py"                  # Find all Python files
sudo updatedb                        # Update locate database
locate app1.py                       # Instant search

Day 4: Links + Advanced Operations

echo "Config v1.0" > app.conf
ln -s app.conf app-soft.conf         # Create soft link
ln app.conf app-hard.conf            # Create hard link
cat app-soft.conf                    # Both work initially
rm app.conf                          # Delete original
cat app-soft.conf                    # ❌ Broken
cat app-hard.conf                    # ✅ Still works!

Day 5: Real-World Scenario

# Simulate backing up web server config before upgrade
sudo cp -R /etc/httpd /root/httpd-backup-$(date +%F)

# Find logs older than 7 days (cleanup candidates)
sudo find /var/log -name "*.log" -mtime +7

# Check what's consuming disk space
du -sh /var/* | sort -h | tail -5

Key Takeaways: The 80/20 Linux Essentials

What You Absolutely Must Know

1. Root account is unlimited power

• Can delete entire OS with one wrong command
• Corporate environments disable direct root login—use sudo instead
• Every sudo command logged for accountability and compliance

2. Linux is case-sensitive

• File.txt ≠ file.txt ≠ FILE.txt (three different files)
• /etc ≠ /Etc ≠ /ETC
• Professional habit: Default to lowercase everything

3. Command-line dominates production

• 95%+ of corporate Linux work happens via CLI (no GUI)
• SSH is your daily workflow—get comfortable with black terminal screen
• Automation requires scriptable commands, not mouse clicks

4. Master the navigation trinity​

• cd = navigate between directories
• pwd = verify current location
• ls -l = see detailed file information
• You’ll use these hundreds of times daily—muscle memory essential

5. Understand filesystem hierarchy​

• / = root directory (filesystem start)
• /etc = configuration files (backup before editing!)
• /var/log = system logs (troubleshooting starts here)
• /home = user directories; /root = root user’s home

6. Wildcards enable batch operations

• * = zero or more characters (*.log matches all logs)
• ? = exactly one character (file?.txt matches file1.txt)
• [] = character range ([A-Z] matches uppercase letters)
• ALWAYS preview with ls before executing rm

7. Links have distinct behaviors

• Soft link = shortcut (breaks if original deleted)
• Hard link = additional name for same inode (survives deletion)
• Check with ls -li to see inode numbers

8. SSH security is critical​

• Disable password authentication immediately
• Enforce key-based authentication
• Always use 2FA for production systems
• Change default port 22
• Never expose SSH directly to public internet

Active Recall Questions (Test Your Understanding)

Question 1: Deep Troubleshooting

You’re troubleshooting a web server that won’t start after a configuration change. Using Linux commands, explain the step-by-step process to:

1. Find the Apache configuration file location
2. Check the error logs for specific failure reasons
3. Verify file permissions on the config file
4. Create a backup before attempting fixes

<details> <summary>Expected Answer</summary>

# 1. Find config location
sudo find /etc -name "httpd.conf"
# or: sudo locate httpd.conf (after updatedb)

# 2. Check error logs
sudo tail -30 /var/log/httpd/error_log
# Look for: syntax errors, permission denied, port conflicts

# 3. Verify permissions
ls -l /etc/httpd/conf/httpd.conf
# Should be: -rw-r--r-- root root (644 permissions)

# 4. Create backup
sudo cp /etc/httpd/conf/httpd.conf /root/httpd.conf.backup.$(date +%F)
# Now safe to edit and test

</details>

Question 2: Synthesis Challenge

A developer accidentally ran rm -rf /home/developer/projects/* instead of rm -rf /tmp/*. All files are gone. Explain:

1. Why hard links could have prevented this data loss
2. How to implement preventive hard link strategy
3. Why soft links wouldn’t help in this scenario

<details> <summary>Expected Answer</summary>

Hard links prevention: If developer created hard link backup in separate directory, deleting original filename wouldn’t destroy data—hard link still points to same inode. Data remains accessible through hard link even after original deletion .

Implementation:

# Daily automated hard link backup
ln /home/developer/projects/critical.py /backup/critical.py.link
# If original deleted, data still exists at /backup/critical.py.link

Soft links fail: Soft link only points to filename, not inode directly. When original file deleted, soft link becomes orphaned—points to nothing .</details>

Question 3: Career Application

In production with 50 servers, you need to find which servers have outdated SSL certificates (stored in /etc/ssl/certs/old-cert.pem). Would you use find or locate? Consider:

• Certificates modified 6 months ago (not recent)
• Need results within 5 minutes across all servers
• Servers under heavy load (minimize disk I/O)

<details> <summary>Expected Answer</summary>

Use locate for this scenario :

Reasoning:

1. Certificate is 6 months old—already in locate database (updated daily)
2. locate searches database (RAM operation)—10-100× faster than find disk scanning
3. Heavy load servers benefit from low disk I/O—locate doesn’t hammer disks
4. 50 servers × 5-minute find scan = 250 minutes total; locate finishes in seconds

Command:

# Run on all 50 servers via Ansible/parallel SSH:
locate old-cert.pem | grep "/