# The Server Mindset

Before a single command, let's fix the mental model - because almost everything that feels strange about a
server comes from one change, and once you see it, the strangeness evaporates.

You already know desktop Linux. A server is *that same Linux* - same kernel, same `/etc`, same permissions,
same shell. What changed is that this machine has no person sitting in front of it, and it isn't there to
be *used* - it's there to *serve*. Hold those two facts and the rest follows.

## What's actually different about a server

**What it actually is.** A server is a Linux box that runs **headless** (no monitor, keyboard, or graphical
desktop), that you reach **over the network** instead of in person, and whose whole reason for existing is
to keep a few **long-running services** alive and answering requests - a web server, a database, an SSH
daemon - for weeks or months without a human touching it.

**Why people get this wrong.** Coming from the desktop, the instinct is "where's the GUI? how do I open the
settings app?" There isn't one, and that's not a missing feature - it's the point. A GUI needs a screen, a
logged-in session, and a pile of graphics packages that would sit idle and just add attack surface. A
server strips all of that away so the machine spends its resources on the actual job.

Here's the shape of the difference, side by side:

```text
   DESKTOP LINUX                          SERVER LINUX
   ─────────────────────────────         ─────────────────────────────
   you sit in front of it          │     you reach it over SSH (a network login)
   a GUI you click through         │     a shell, config files in /etc, that's it
   apps you launch and quit        │     services that start at boot, run for months
   you log in, do a thing, log off │     it runs unattended, you visit to administer
   reboot whenever                 │     a reboot means downtime - you plan it
```

**Why this saves you later.** Every "how do I do X on a server" question answers itself once you accept the
posture. *Change a setting?* Edit a config file under `/etc` (it's text - that's why servers are scriptable
and reproducible). *Make something run all the time?* That's a service (Phase 2). *See what's happening?*
Read logs, not a status window (also Phase 2).

📝 **Terminology.** *Headless* = a machine running with no display, keyboard, or mouse attached. *Daemon* =
a long-running background service process; by convention its name often ends in `d` (`sshd`, `nginx` runs as
a daemon, `systemd` itself). *Service* and *daemon* are used almost interchangeably in practice.

## You reach it over SSH

The one skill you cannot administer a server without is **SSH** - *Secure Shell*. It's how you get a shell
on a machine that's somewhere else, with everything between you and it encrypted.

**What it actually is.** SSH gives you a terminal session on a remote machine, exactly as if you'd opened a
terminal while sitting in front of it - except the keystrokes travel over an encrypted network connection.
You type locally; the commands run *there*. There's a client on your laptop (`ssh`) talking to a daemon on
the server (`sshd`, which we'll meet again in Phase 2 as a real service).

**A real example.** The basic connect is one command:

```console
$ ssh deploy@203.0.113.10
The authenticity of host '203.0.113.10 (203.0.113.10)' can't be established.
ED25519 key fingerprint is SHA256:Z9k3...Qp1A.
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added '203.0.113.10' (ED25519) to the list of known hosts.
deploy@203.0.113.10's password:
Welcome to Ubuntu 24.04.1 LTS (GNU/Linux 6.8.0-41-generic x86_64)

Last login: Wed Jun 18 09:14:02 2026 from 198.51.100.7
deploy@web-prod-1:~$
```

*What just happened:* `ssh deploy@203.0.113.10` means "open a shell on the host at `203.0.113.10` as the
user `deploy`." Because this was your first connection, SSH showed you the server's **host key
fingerprint** and asked you to confirm it - proof of *which* machine you're talking to, so nobody can
impersonate it later. You said `yes`, authenticated (here with a password), and the prompt changed to
`deploy@web-prod-1:~$` - the tell that every command you type now runs *on the server*. `exit` (or Ctrl-D)
drops you back to your own machine.

⚠️ **Gotcha.** That fingerprint prompt only happens *once* per host. If you ever connect again and SSH
instead prints a loud red `WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!`, do **not** blindly type `yes`.
It means the host key is different from the one you trusted before - usually an innocent server rebuild, but
potentially someone intercepting your connection. Confirm out-of-band why the key changed before you clear
the old entry from `~/.ssh/known_hosts`.

📝 **Terminology.** *Host* = the remote machine (its IP or DNS name). *Host key* = the server's permanent
cryptographic identity; the *fingerprint* is its short, human-checkable form. *known_hosts* = the local file
where your SSH client records host keys it has trusted.

### A note on passwords vs. keys

You just logged in with a password, which works but is the weaker option. Real servers use **key-based
authentication**: you hold a private key on your laptop, the server holds your public key, and you connect
without typing a password - more convenient and dramatically harder to brute-force. We revisit setting this
up when we harden SSH in [Phase 3](03-running-it-safely.md). For now: *passwords get you in, keys are how
grown-up servers actually do it.*

🪖 **War story.** The classic first-day mistake: leave an `ssh` session open, run a long task in it, close
the laptop - and watch the task die when the connection drops. A server runs unattended, but *your shell
session does not*: it's tied to your connection. The fix is to detach long work from your session (a
`systemd` service, a scheduled job, or `tmux`), which is exactly the muscle the rest of this guide builds.

## Everything is a file you can edit

One more piece of the mindset. On a server, configuration isn't hidden behind dialog boxes - it lives in
**plain-text files**, overwhelmingly under `/etc`. The SSH daemon's behavior is in `/etc/ssh/sshd_config`. A
web server's sites are in `/etc/nginx/`. Scheduled jobs, users, mounted disks, the firewall - all text.

**Why this is the whole game.** Text config is what makes a server *operable at a distance and reproducible*
- you can read it over SSH, diff it, put it in version control, copy it to the next server, let automation
generate it. That's what lets one person administer a hundred machines. Every time you reach for a setting:
*which file under `/etc` owns this, and what does it say right now?*

## Recap

1. A server is the **same Linux** as your desktop, run **headless** - no GUI, reached over the network, built
   to keep **long-running services** alive unattended.
2. You get a shell on it with **`ssh user@host`**; the first connection asks you to verify the **host key
   fingerprint**, and the changed-prompt is your signal that commands now run *there*.
3. **Keys beat passwords** for SSH auth - we set that up properly later.
4. Configuration is **plain text under `/etc`**, which is exactly what makes a server scriptable, diffable,
   and reproducible.

Next, the tool that actually starts, stops, and supervises all those long-running services: **systemd**.