Linux Commands for Cloud Servers: Practical Reference (2026)

Linux commands are shell tools used to inspect, configure, secure, monitor, and troubleshoot a Linux server.

For cloud servers, the useful skill is not memorizing hundreds of commands. It is knowing which command reveals the current state, which command changes it, and which command proves the change worked. Most daily work fits into a small operating loop: inspect → change → verify.

Raff Technologies supports 3,000+ customers and 15,000+ VMs. Serdar’s operating rule for remote Linux work is simple: inspect before changing anything, and verify immediately after. That habit matters most around SSH, firewalls, permissions, services, storage, and deployments because a small mistake can remove your recovery path.

This guide is a task-based Linux commands cheat sheet for cloud-server administration. Examples use common Ubuntu/Debian and systemd conventions where stated; package names, service units, and file paths can differ by distribution. For the wider access decision, read Bastion Host vs VPN vs Public SSH.

Start with inspection before changing a Linux server

The fastest safe workflow is to pair every change with an inspection command and a verification command.

A useful first inspection after connecting is:

hostnamectl
whoami
pwd
ip addr
df -h
free -h
uptime

These commands answer six different questions: which host is this, which account is active, where am I, what network interfaces exist, how full are the filesystems, and what is the current memory/load context?

Do not treat uptime load average as CPU percentage. Linux load can reflect runnable work and tasks waiting in uninterruptible states, so correlate it with CPU, I/O, process, and application evidence before blaming compute.

Quick Linux command map

The command name is only the beginning. The operational habit is to know what evidence you expect before and after running it.

SSH and file transfer commands control remote access

SSH is the normal administrative path for Linux cloud servers.

ssh user@server_ip

With a specific private key:

ssh -i ~/.ssh/raff_key user@server_ip

Before accepting a first-connection host key, confirm that you are connecting to the expected server and address. Do not copy private keys into tickets, chat, repositories, or shared documents.

Generate an Ed25519 key with:

ssh-keygen -t ed25519 -C "admin@cloud-server"

For repeated connections, an SSH config entry reduces copy-and-paste errors:

Host production-vm
    HostName 203.0.113.42
    User deploy
    IdentityFile ~/.ssh/raff_key

Then connect with:

ssh production-vm

File transfer commands have different risk profiles

Use scp for simple copies:

scp ./app.tar.gz user@server_ip:/home/user/

Use rsync when transfers are repeated or you need a preview before changing many files:

rsync -avz --dry-run ./site/ user@server_ip:/var/www/site/

After reviewing the dry run, remove --dry-run only if the source and destination are correct.

rsync -avz ./site/ user@server_ip:/var/www/site/

Options that delete destination files deserve a separate review. Never add destructive sync flags simply because they appear in a deployment snippet.

Files, permissions, and text tools handle most daily server work

A small group of filesystem commands covers a large part of Linux administration.

Navigation and inspection

pwd
ls -lah
cd /var/log
cd -

Run pwd and ls -lah before recursive permission changes, archive operations, or cleanup work. cd - returns to the previous directory and is useful when comparing two locations.

For long files, prefer less over dumping everything into the terminal:

less /var/log/syslog

For recent log lines:

tail -n 100 /var/log/nginx/error.log
tail -f /var/log/nginx/error.log

Use Ctrl+C to stop a live tail.

Search commands reduce guesswork

Search text with grep:

grep -in "error" /var/log/nginx/error.log
grep -n "listen" /etc/nginx/sites-available/default

Find files by type, age, or size:

find /etc -type f -name "*.conf"
find /var/log -type f -mtime -1
sudo find /var -type f -size +500M 2>/dev/null

Use awk, sort, and uniq to summarize structured text. For example, top source IPs in an Nginx access log:

awk '{print $1}' /var/log/nginx/access.log | sort | uniq -c | sort -nr | head

Permission changes need path verification

Confirm identity first:

whoami
id

Common permission examples include:

chmod 600 ~/.ssh/id_ed25519
chmod 755 deploy.sh

Change ownership only after confirming the target path:

pwd
ls -la /var/www/app
sudo chown -R deploy:deploy /var/www/app

Recursive chmod and chown commands can affect thousands of files. Treat the path as the critical input, not as an afterthought.

Packages and services are the core operating controls

Ubuntu and Debian normally use APT. RHEL-family distributions such as Rocky Linux and AlmaLinux normally use DNF.

On Ubuntu/Debian:

sudo apt update
apt policy nginx
sudo apt install nginx

On Rocky/AlmaLinux/Fedora:

sudo dnf check-update
sudo dnf install nginx

Package names and repositories can differ, so check the distribution before copying an installation command from another server.

systemctl controls systemd services

Common inspection commands are:

sudo systemctl status nginx --no-pager
systemctl is-enabled nginx
systemctl --failed

When a service has failed, read the logs before restarting it:

sudo journalctl -u nginx -n 100 --no-pager

If configuration is valid and a reload is supported, a reload may be less disruptive than a full restart:

sudo systemctl reload nginx
sudo systemctl status nginx --no-pager

For an application service, inspect the unit definition when paths or environment configuration look wrong:

sudo systemctl cat app.service
sudo journalctl -u app.service -n 100 --no-pager

The useful sequence is not “restart until it works.” It is status → logs → configuration → controlled change → status → application check.

Resource and network commands diagnose pressure before guessing

Use resource commands to identify which layer is under pressure before changing VM size or application architecture.

CPU, memory, and processes

uptime
free -h
ps aux --sort=-%cpu | head
ps aux --sort=-%mem | head
top

free -h should be interpreted with available memory and swap behavior, not only the “used” column. Linux can use otherwise idle memory for useful cache.

If CPU, memory, disk, or network behavior is affecting latency or stability, use Cloud Server Performance Bottlenecks before resizing.

Filesystem capacity and growth

df -h
df -ih
sudo du -h --max-depth=1 /var 2>/dev/null | sort -h

df -h checks space. df -ih checks inode usage. du helps identify which directories are consuming capacity. Do not delete database, upload, log, or backup data until you know who owns it and what recovery path exists.

Network and application reachability

ip addr
ip route
sudo ss -tulpn
curl -I http://127.0.0.1
curl -I https://example.com
dig +short example.com

ss -tulpn shows listening sockets and processes. curl tests the application path. dig tests DNS resolution. These commands answer different questions; a successful ping does not prove that the application is healthy.

For a specific TCP port:

nc -zv example.com 443

A network diagnosis should follow the path: DNS → route → listening socket → firewall → application response → dependency response.

Firewall and SSH changes need a rollback path

Remote access changes are different from ordinary configuration edits because a mistake can lock you out of the machine.

On Ubuntu with the OpenSSH UFW profile available, inspect first:

sudo ufw status numbered
sudo ss -tulpn | grep ':22'

Allow SSH before enabling the firewall:

sudo ufw allow OpenSSH
sudo ufw enable
sudo ufw status numbered

If SSH uses a custom port, allow that port instead of assuming port 22. Keep the current SSH session open and test a second connection before closing the working session.

For SSH server configuration changes, validate syntax before reloading:

sudo sshd -t

Then use the correct SSH service unit for the distribution and verify a new login before ending the existing session. Do not disable password or root login until key-based access has already been tested for the account you intend to use.

For a deeper access-model decision, use Bastion Host vs VPN vs Public SSH. For firewall policy, use Firewall Best Practices for Cloud Servers.

Troubleshooting works best as a verification sequence

The same small set of commands can diagnose many incidents when they are run in the right order.

A website-down sequence

curl -I http://127.0.0.1
sudo systemctl status nginx --no-pager
sudo journalctl -u nginx -n 100 --no-pager
sudo ss -tulpn | grep ':80\|:443'
df -h
free -h

This separates application, service, socket, disk, and memory evidence instead of treating every outage as the same problem.

A full-disk sequence

df -h
df -ih
sudo du -h --max-depth=1 /var 2>/dev/null | sort -h
sudo journalctl --disk-usage

The next action depends on what is consuming the space. Log retention, container layers, package caches, uploads, and databases need different cleanup and recovery decisions.

Kernel messages provide another evidence layer

sudo dmesg -T | tail -n 100

Kernel messages can reveal device, filesystem, network, or memory-related events that application logs do not contain. Use them as evidence, not as a substitute for application monitoring.

Raff provides the VM layer while Linux operations stay with you

Raff provides the infrastructure layer; the guest operating system remains under your administrative control.

Current Raff Linux VMs provide full root access through SSH plus browser-console access. Current Cloud Server plans include a 3 Gbps public port, unmetered bandwidth, private networking, DDoS protection, backups and snapshots, API/Terraform access, monitoring, and CPU/RAM/storage resize support.

That division of responsibility matters when using the commands in this guide:

The browser console is especially important as a recovery path when an SSH or guest-firewall change blocks remote access.

Use the live Raff pricing page for current VM sizes, subscription terms, and pay-as-you-go details rather than relying on an old price embedded in a Linux command reference. Use VM Sizing when CPU, RAM, or storage requirements need a separate capacity decision.

Build a small command runbook around your workload

A useful Linux command reference follows the operating sequence of the server rather than the alphabet.

Start with the commands that let you identify the host, user, filesystem, memory, services, sockets, and logs. Add one safe change at a time. Verify the resulting state before moving to the next action. For recurring incidents, save the inspection and verification sequence as a runbook so the next response starts with evidence instead of memory.

For administrative exposure and private access, continue with Bastion Host vs VPN vs Public SSH. For workload pressure, continue with Cloud Server Performance Bottlenecks.

Sources

• Ubuntu Server: OpenSSH server
• Ubuntu Server: Firewall and UFW
• systemd: systemctl
• systemd: journalctl
• Linux kernel: /proc filesystem
• GNU Coreutils
• Raff Linux VM
• Raff Pricing