Almost every server, container, and cloud instance a DevOps engineer touches runs some flavor of Linux, and almost everything you do to manage it happens through a terminal, not a graphical interface. That’s not a stylistic choice; the command line is faster to automate, faster to script, and the only interface that reliably works the same way over SSH on a remote box as it does on your laptop. If you’re building a DevOps skill set, Linux and the command line aren’t optional groundwork before the “real” work starts, they’re the substrate everything else, Bash scripting, Docker, Kubernetes, Terraform, sits on top of.

This guide covers the command categories that come up constantly in real DevOps work: navigating and manipulating the filesystem, managing permissions and ownership, controlling processes, installing software across different distributions, and enough networking basics to diagnose a connectivity problem without leaving the terminal. It also covers a few areas that tutorials often skip but that come up just as often on the job: reading logs efficiently, working with environment variables, connecting to remote servers over SSH, and editing files without a graphical interface.

None of this requires memorizing an exhaustive command reference before you can be useful. Most working DevOps engineers use a core set of maybe thirty commands daily and look up the rest as needed; the goal here is building genuine comfort with that core set, not encyclopedic recall of every flag every command supports.

The Core Command Categories

Navigating the Filesystem

Everything in Linux is organized as a single tree rooted at /, and fluency in moving through it quickly is the first real productivity unlock. ls -la lists every file in a directory including hidden ones (anything starting with a dot) along with permissions, ownership, and size. cd changes your working directory, and combined with tab-completion, lets you navigate deep directory structures without typing full paths. find searches recursively by name, type, or modification time, and grep searches file contents, both essential for tracking down a specific config file or log line across a large system.

ls -la /var/log
cd /etc/nginx
find / -name "*.conf" -mtime -1
grep -r "error" /var/log/nginx/

That last command searches recursively (-r) through every file in the nginx log directory for the string “error,” which is a pattern you’ll use constantly when debugging a production issue: narrow down which log has the problem, then search its contents for the relevant string or timestamp.

Permissions and Ownership

Linux permissions are one of the first genuinely confusing things for people new to the command line, and also one of the most important to actually understand rather than pattern-match. Every file has an owner, a group, and a set of permissions (read, write, execute) for the owner, the group, and everyone else. chmod changes those permissions, usually expressed as a three-digit number where each digit represents owner/group/other as a sum of read (4), write (2), and execute (1).

chmod +x deploy.sh
chmod 755 deploy.sh
chown appuser:appgroup /var/www/app
sudo chmod -R 644 /etc/ssl/certs

chmod +x deploy.sh makes a script executable, the single most common permission fix you’ll make when a deploy script fails with “permission denied.” chmod 755 sets read/write/execute for the owner and read/execute for everyone else, a common default for scripts and executables. chown changes who owns a file, critical when a service running as one user needs to read files created by a deploy process running as another. Getting comfortable with these two commands alone resolves a large share of the permission-related errors you’ll hit early in a DevOps role.

Process Management

Knowing what’s actually running on a system, and being able to control it, is core to both day-to-day work and incident response. ps aux lists every running process; top (or the more modern htop) shows a live, updating view of CPU and memory usage per process, invaluable when a server is running hot and you need to identify what’s consuming resources right now. kill sends a signal to a process, usually to terminate it gracefully (SIGTERM) or forcefully (SIGKILL) when it’s unresponsive.

ps aux | grep node
top
kill -15 4821
kill -9 4821

The distinction between kill -15 and kill -9 matters in production: -15 (SIGTERM) asks a process to shut down cleanly, closing connections and finishing in-flight work first, while -9 (SIGKILL) terminates it immediately with no cleanup. Reaching for -9 as a default habit can leave a database mid-write or a connection pool in a bad state; it’s a last resort, not a first move.

Package Management Across Distributions

Software installation commands differ by Linux distribution, and knowing the right one for your environment matters since cloud images and CI runners vary. Debian and Ubuntu-based systems use apt; Red Hat, CentOS, and Fedora-based systems use yum or the newer dnf; Alpine, common in minimal container images, uses apk. All three follow a similar pattern: update the local package index, then install.

sudo apt update && sudo apt install -y curl git
sudo dnf install -y curl git
apk add --no-cache curl git

This distinction matters more than it might seem in DevOps work specifically because Dockerfiles frequently need to install dependencies inside a base image, and using the wrong package manager for a given base image is one of the most common early Dockerfile mistakes, covered in more depth in our Docker and containers guide.

Basic Networking From the Terminal

A meaningful share of production troubleshooting is diagnosing connectivity, and a handful of commands cover most of it. curl and wget fetch URLs directly from the terminal, useful for testing whether an API endpoint or health check is actually reachable. ping checks basic network reachability. netstat or the newer ss shows what ports are listening and what connections are active, essential when debugging “why can’t my app reach the database.”

curl -I https://legendarywaysacademy.com
ping -c 4 8.8.8.8
ss -tulpn | grep 5432

curl -I fetches only the response headers, a quick way to check a service is up and returning the expected status code without downloading the full body. ss -tulpn lists listening TCP and UDP ports along with the process holding each one, the fastest way to confirm whether your database is actually listening on the port your application expects.

Reading and Managing Log Files

Logs are where most production debugging actually happens, and the terminal has purpose-built tools for reading them efficiently. tail -f streams new lines from a file as they’re written, the standard way to watch a log in real time while reproducing an issue. less opens a file for paginated, searchable viewing without loading the whole thing into memory, essential for multi-gigabyte log files that would choke a text editor. On systems using systemd, journalctl is the modern equivalent for viewing service logs directly, rather than hunting through files in /var/log.

tail -f /var/log/nginx/access.log
less +F /var/log/syslog
journalctl -u nginx.service --since "1 hour ago"
journalctl -f

journalctl -u nginx.service --since "1 hour ago" filters directly to a specific service’s logs within a time window, far faster than manually paging through a raw log file looking for a timestamp. journalctl -f follows new entries live, the systemd equivalent of tail -f, and is one of the first commands worth running when a service managed by systemd starts misbehaving.

Environment Variables and PATH

Environment variables configure how programs behave without changing their code, and understanding them is essential once you start deploying applications that expect database URLs, API keys, or feature flags to arrive this way. export sets a variable for the current shell session and anything launched from it; echo $VARNAME reads one back. The PATH variable specifically controls which directories the shell searches when you type a command name, and “command not found” errors are very often a PATH problem rather than a missing install.

export DATABASE_URL="postgres://user:pass@localhost/db"
echo $DATABASE_URL
echo $PATH
export PATH="$PATH:/usr/local/mybinary/bin"

A common early mistake is setting an environment variable in one terminal session, then being confused why a script run in a different session (or a systemd service, or a cron job) can’t see it. Environment variables set with plain export don’t persist beyond the current session or propagate to processes that don’t inherit that shell’s environment; production configuration needs to be set at the service, container, or system level instead, not just exported ad hoc in a terminal you’ll close later.

SSH and Remote Access

Nearly all server administration in DevOps happens over SSH, and comfort with it beyond just “connecting” is worth building deliberately. Key-based authentication (rather than passwords) is the standard, generated locally and added to a server’s authorized keys. SSH config files let you define shortcuts for frequently accessed hosts instead of typing full connection strings every time, and scp or rsync handle file transfer over the same encrypted connection.

ssh-keygen -t ed25519 -C "you@example.com"
ssh-copy-id user@server.example.com
ssh user@server.example.com
scp deploy.sh user@server.example.com:/opt/app/
rsync -avz ./build/ user@server.example.com:/var/www/app/

An SSH config file (~/.ssh/config) letting you type ssh prod-web-1 instead of a full username, hostname, and key path is a small setup investment that pays off constantly once you’re regularly connecting to more than a couple of servers, and it’s the same mechanism most CI/CD pipelines use under the hood to deploy to remote infrastructure.

A Quick Reference for the Commands That Come Up Constantly

Beyond the categories already covered, a handful of individual commands are worth having genuinely memorized rather than looked up every time, because they show up in nearly every debugging session: df -h for checking disk space before a deploy fails from a full disk, du -sh * for finding what’s actually consuming that space, history | grep for recovering a complex command you ran previously, and man followed by any command name for the full manual page when a flag’s exact behavior isn’t obvious. Building genuine muscle memory around this small set of commands, rather than relying on search every single time, is what separates comfortable command-line use from constant friction.

Shell Customization for Everyday Productivity

Once the fundamentals are comfortable, small productivity investments compound quickly. Aliases in your .bashrc or .zshrc turn long, frequently-typed commands into short ones; a well-configured shell prompt shows your current git branch and directory at a glance; and command history search (Ctrl+R) lets you re-run a complex command from last week without retyping it. None of this is essential to get started, but engineers who invest a small amount of time here save real hours over a career spent living in a terminal.

Editing Files Without Leaving the Terminal

Editing a config file on a remote server means using a terminal-based editor, since there’s no desktop GUI to open a graphical text editor with. nano is the friendliest starting point, with on-screen shortcuts and a low learning curve. vim has a steeper learning curve but is installed on nearly every Linux system by default and is worth learning eventually, since it’s frequently the only editor available in a minimal container image or a stripped-down production server. The essentials to survive in vim: press i to enter insert mode and start typing, press Esc to leave insert mode, and type :wq then Enter to save and quit, or :q! to quit without saving.

nano /etc/nginx/nginx.conf
vim ~/.bashrc
# inside vim: press i to insert, Esc to stop, :wq to save and quit

It’s worth deliberately practicing the save-and-quit sequence in vim before you’re under pressure fixing a production config at 2am; it’s one of the more common moments of genuine panic for engineers newer to the command line, and it takes only a few minutes of practice to make it automatic.

How This Connects to the Rest of DevOps

Every topic that follows in a DevOps curriculum assumes comfort with what’s covered here. Bash scripting is these same commands strung together into reusable automation. Docker images are built from a Linux base and configured with the exact package-management and permission commands covered above. Kubernetes nodes are Linux servers underneath the orchestration layer, and debugging a failing pod often comes down to shelling into a container and running the same ps, grep, and curl commands you’d run on a bare server. There’s no DevOps skill that doesn’t eventually route back through comfort with the Linux command line.

Frequently Asked Questions

Treat the command line the way you’d treat learning any new instrument: short, regular, hands-on practice beats occasional long study sessions. Open a terminal daily, even for small tasks you could technically do through a GUI, and the categories covered here (navigation, permissions, processes, packages, logs, networking, and remote access) will move from effortful to automatic faster than most people expect.

If you’re building this skill set specifically to move into a DevOps role, treat the command line as the one area worth over-preparing on relative to everything else. Interviewers frequently probe basic terminal fluency informally, through live troubleshooting exercises or pairing sessions, and hesitation here reads as a bigger red flag than gaps in more advanced, specialized tooling that’s easier to learn on the job.

Related reading: continue to Bash scripting, see the full DevOps topics overview, or check the DevOps career roadmap for how this fits into the bigger learning path.