Linux Quick Start: From First Login to Confident Admin

A friendly walk through the basics. By the end you'll know how to look around, find out what's wrong, and not break the box.

Why This Page Exists

If you've just been handed a Linux server and the black rectangle staring back at you feels intimidating, you're in good company. I came to Linux from Windows myself, and the first few weeks I genuinely wondered why everything had to live inside a shell — couldn't there just be a window for this?

So let me say up front: yes, it looks weird. Yes, it feels weird. There's a reason for that, and it isn't that Linux people enjoy being unfriendly — Linux is built on a philosophy that's almost fifty years old, and the philosophy is every tool does one thing, you compose them. Once you see the pieces and how they snap together, the same thing that felt cryptic starts feeling like a precision instrument. And then, like me, you'll probably never go back. The reason a million servers on the internet run Linux is the same reason it felt strange on day one.

This page is a quick-tour version of the full commands index, in the order you'll meet the tools on a real box. You don't have to remember anything — just read it through, click the links you find interesting, and come back to it later. By the end, you'll know how to log in, look around, see what's happening, find out what's broken, and avoid the handful of moves that can really hurt you.

1. Getting Onto the Server

Step one is the SSH login — Secure Shell. You type ssh followed by user@hostname and a moment later you're talking to a remote machine somewhere. That moment is the magic — there's no app to install on the server, no port to open beyond 22; SSH ships with Linux and macOS, and the bare minimum on Windows is now built into PowerShell. Once you're in, every command you type runs over there.

A few tools you'll want from day one:

  • ssh — the login itself
  • scp and sftp — copy files to or from the server over the same SSH connection
  • rsync — for syncing folders; resumes interrupted transfers and only copies what changed
  • tmux — runs a persistent shell session on the server, so if your laptop closes mid-task, your work is still right there when you reconnect. This one was a revelation for me.

If you remember nothing else from this section: use tmux. The first time a flaky WiFi disconnect doesn't lose two hours of work, you'll thank past-you.

2. Looking Around

You're in. Now what? Linux gives you a working directory (probably your home directory) and a prompt. Everything else is filesystem navigation.

  • pwd — where am I? Prints your current directory.
  • ls — what's here? Lists files and folders. Add -la to see hidden files and permissions.
  • cd — go somewhere. cd /var/log to jump there, cd .. to go up, cd alone to go home.
  • cat — dump a file's contents to the terminal. Great for short files.
  • less — page through a long file. q quits, /word searches, arrow keys move. Use this for log files, not cat.
  • tail — show the last few lines. tail -f follows the file as it grows — the move for watching a log in real time.
  • find and locate — find files anywhere in the filesystem.
  • man — the built-in manual for every command. man ls tells you everything ls can do. Press q to quit. This is the most underused command in Linux.

The filesystem itself follows a convention worth knowing: everything is under /. Your home is in /home/<you>. System config lives in /etc. Logs go to /var/log. Running programs are tracked under /proc (which isn't a real directory at all — it's a window into the kernel). Once you know the map, you stop being lost.

3. Is the Server Alive and Well?

This is the daily-diagnostic loop, and it's the section that pays the biggest dividends. When something feels slow or wrong, this is the sequence:

  • uptime — how long has the box been up, and what's the load average? Load is "how many processes wanted to run, averaged over 1, 5, and 15 minutes." Compared to the number of CPU cores, it tells you instantly whether the box is calm or drowning.
  • top — a live, self-updating view of every running process and what each one is using. This is the single most important command on Linux. Read the top page — it teaches load, CPU, memory, and the top interface in one shot, and the mental model it gives you applies to half the rest of this list.
  • htop — same data as top but colorful, with a mouse and clickable rows. Most people prefer it once they discover it.
  • ps — a one-shot snapshot of running processes. Use it in scripts when you need to ask "is X running?" without opening an interactive view.
  • free — memory state. Read the page; the headline insight is that Linux uses spare RAM as a disk cache and gives it back instantly when programs ask. The available column is the honest "how much memory is really free?" answer.

Spend an hour with top on your own box. Watch the numbers move while you do things. That hour gets you further than weeks of reading.

4. Disk and Memory Problems

Two of the three classic outages. The third (network) is below.

For disk:

  • df — which mounted filesystem is full? df -h for human-readable sizes.
  • du — where did all the space go? The reflex is du -hd1 /path | sort -h — top-level breakdown, biggest at the bottom.
  • lsof — what files does each process have open right now? Also reveals one of Linux's classic mysteries: a file you've deleted that's still using disk space because something is holding it open.
  • iostat — when the disk feels slow rather than full, this names the device and measures the latency.

For memory:

  • free again — the snapshot view.
  • vmstat — six subsystems on one line, updating every N seconds. The si/so columns are the swap-thrashing alarm.

5. Stopping a Misbehaving Program

When a process is eating the box, you need to talk to it. Linux talks to processes via signals — tiny numbered messages the kernel hand-delivers.

  • kill — send a signal to one PID. The default signal asks the process to quit cleanly. kill -9 is the sledgehammer; learn when not to reach for it.
  • pkill — send a signal by name instead of PID. pkill -HUP nginx tells every nginx process to reload its config.
  • pgrep — find PIDs by name. The safety habit: run pgrep -af 'pattern' to preview what you'd hit, then swap one letter to pkill when you're sure.

The signal page is one of the deepest "aha" reads in this knowledge base — the whole "kill doesn't kill" reveal lives there.

6. The Network — What's Listening, Who's Talking

This is the section that catches the most embarrassing first-server mistakes — and not checking it is how databases end up on the open internet.

The very first command to run on any new server:

ss -ltnp

That's ss: list TCP sockets that are listening, numeric (no slow DNS lookups), with the owning process. If you see MySQL bound to 0.0.0.0:3306 instead of 127.0.0.1, fix it before you do anything else.

Other tools:

  • netstat — older, slower, every tutorial still uses it
  • ip — modern interface and routing config
  • ping — is the box reachable?
  • curl — fetch a URL from the shell; the universal HTTP debugger
  • dig — DNS lookups
  • tcpdump — capture packets when nothing else can answer "is the traffic even arriving?"

7. Reading the Logs

When something broke, the logs are where the story is.

  • journalctl — every log line from every systemd-managed service, queryable by time, service, priority, or boot. journalctl -u nginx -f follows nginx's logs live.
  • dmesg — the kernel's own log buffer. First place to look for hardware errors, disk failures, USB events, or OOM kills.
  • tail -f — follow any log file in real time.
  • grep — find lines that match.
  • strace — when there are no logs and you need to see what a program is doing, strace shows every conversation the program has with the kernel. It feels like magic the first time.

8. Services Themselves

On modern Linux, services are managed by systemctl. The three commands you'll use most:

systemctl status nginx
systemctl restart nginx
systemctl enable --now nginx

status shows whether it's running, its main PID, recent log lines, and what the supervisor thinks of it. restart stops and starts. The enable --now combination starts it now and makes it start on boot — the classic first-timer mistake is doing one without the other and being surprised after a reboot.

9. The Five Things That Can Really Hurt You

You're running a server that strangers can reach. A few habits matter.

  • Never put a database on the public internet. Bind to 127.0.0.1 or behind a firewall. Run ss -ltnp and look at every line.
  • Never run things as root that don't need to. sudo is for surgical use, not daily life.
  • rm -rf is permanent. There is no recycle bin. Triple-check the path before you press Enter, especially when variables are involved (a wrong $VAR can turn rm -rf $VAR/* into rm -rf /*).
  • kill -9 skips cleanup. It's destructive in subtle ways — read the kill page before reaching for it on anything that holds state.
  • Backups matter, and they only count if you've restored from one. Set them up, then test the restore. Untested backups have a 50% chance of being usable.

Where to Go From Here

You now have the map. The full commands index has every tool in this knowledge base, organized in the same reading order with the same kind of depth. The terms section explains the concepts behind the commands — what a process really is, what a signal really is, why load average is counted the way it is. The problems section walks through real symptoms ("the disk is full", "load is high") with diagnosis-and-fix recipes.

A blog series is coming that walks through setting up a real production server from scratch — the kind of thing you build once for your own project and then realize you've built three more for friends. That's the natural next step after this page, and it'll link from here when it's ready.

Until then: read top properly, get tmux under your fingers, and run ss -ltnp on every box you control. Those three habits will save you more outages than any monitoring tool ever will.

Want to see how your own server is actually doing while you're still learning?

CleverUptime watches the symptoms you'd otherwise have to hunt for — load creeping, disk filling, services flapping, kernel errors in dmesg — and tells you what's going on in plain language. It's a friendly second pair of eyes on every box, so you can focus on building instead of babysitting.

Want to see your own server's health right now? One command, no signup, no install.

Check your server →