SSH & Working on Remote Servers

Everything in this guide so far assumed you were sitting at the machine. But the servers your software actually runs on live in data centres you'll never set foot in — headless boxes with no screen, no keyboard, reachable only across the network. This chapter is how you reach them. SSH opens an encrypted tunnel to a computer anywhere in the world and hands you its shell, so you can work on it as naturally as if it were under your desk. It is, without exaggeration, how the entire internet is administered.

What SSH actually does

SSH stands for Secure Shell, and the name is the whole idea: it gives you a shell — the same command line from chapter one — on a remote machine, over a connection that's secure. You type on your laptop; each command travels across the internet to the server, runs there, and its output travels back to your screen. For the duration of the session, your terminal is the server's terminal.

The "secure" part is why SSH won. Everything it carries — your login, every keystroke, every line of output — is encrypted, so anyone snooping on the network in between sees only scrambled noise. Its predecessors (telnet, rlogin) sent everything, including passwords, in plain readable text; on today's internet that's unthinkable. SSH made remote access safe, and it's now the universal standard: cloud servers, Raspberry Pis, network gear, deployment pipelines — all speak SSH.

Connecting: ssh user@host

The command itself is refreshingly plain. You name the user to log in as and the machine to reach, joined by an @:

$ ssh raghav@203.0.113.5

That's "connect to the server at 203.0.113.5 and log me in as raghav." The host can be an IP address like this, or a domain name like ssh raghav@app.example.com. Once you're in, watch the prompt change — from your laptop's raghav@laptop to the server's own name, say raghav@web-prod-1. That changed prompt (recall chapter one) is your constant reminder of which machine you're about to run commands on — and here it's a safety feature, not a decoration. When you're done, type exit to close the session and drop back to your local shell.

Passwords work, but keys are better

SSH can log you in with a password, but the professional standard — and often the only option cloud providers allow — is a key pair. This is a pair of matched cryptographic files:

• A private key, which stays on your laptop and which you never share with anyone, ever.
• A public key, which you can hand out freely and which gets placed on any server you want to reach.

The two are mathematically linked such that the public key can verify the private one without ever revealing it. When you connect, the server challenges your laptop to prove it holds the matching private key; it does, silently, and you're in — no password typed, nothing secret sent across the wire.

Why this beats passwords on every axis: a good key is far longer and more random than any password a human would type, so it can't be guessed or brute-forced; nothing secret ever crosses the network; and it's convenient, because once set up you log in instantly with no typing. The one rule that matters absolutely: the private key is like the only key to your house — guard it, never email it, never commit it to a repo, never paste it anywhere. Anyone who gets your private key can log in as you.

Setting up a key, once

You generate a key pair a single time and reuse it for every server. ssh-keygen creates the pair:

$ ssh-keygen -t ed25519 -C "raghav@laptop"

This produces two files in the hidden ~/.ssh folder: id_ed25519 (your private key — the secret one) and id_ed25519.pub (your public key — the shareable one). The ed25519 part just names a modern, strong algorithm. It'll offer to protect the private key with a passphrase; on a personal laptop that's a sensible extra layer.

To let a server recognise you, its ~/.ssh/authorized_keys file needs your public key. The easiest way to install it is ssh-copy-id, which appends it for you (this one time you'll enter the server's password):

$ ssh-copy-id raghav@203.0.113.5

From then on, ssh raghav@203.0.113.5 logs you straight in with the key — no password. Cloud providers usually let you paste your public key into their dashboard when you create a server, achieving the same thing before the machine even exists.

Moving files: scp and rsync

A shell lets you run things on a server; you also need to get files onto and off it — your code, a config file, a database backup. Because these ride the same secure SSH channel, they're encrypted in transit too.

scp (secure copy) works just like the cp from chapter three, except one side is a remote machine written as user@host:path:

$ scp report.pdf raghav@203.0.113.5:~/          # laptop → server
$ scp raghav@203.0.113.5:/var/log/app.log .     # server → laptop (into here)
$ scp -r ./site raghav@203.0.113.5:/var/www/    # -r for a whole folder

For anything you copy repeatedly — syncing a project folder, pushing updated files — rsync is smarter: it compares both sides and transfers only the parts that actually changed, which is dramatically faster on the second and later runs:

$ rsync -avz ./site/ raghav@203.0.113.5:/var/www/site/

The flags read as archive (preserve everything), verbose, compressed. rsync is the quiet backbone of countless deployment scripts, precisely because "send only what changed" scales to large projects where scp's "send everything, every time" would crawl.

The config file that saves your sanity

Typing ssh raghav@203.0.113.5 over and over — and remembering which cryptic IP is which server — gets old fast. The file ~/.ssh/config lets you give servers friendly names and store their details once:

Host prod
    HostName 203.0.113.5
    User raghav
    Port 22
 
Host staging
    HostName staging.example.com
    User deploy

With that saved, the whole connection collapses to a nickname:

$ ssh prod

SSH looks up prod, fills in the host, user, and port, and connects. scp and rsync understand these nicknames too, so scp file.txt prod:~/ just works. On a real job you'll accumulate a handful of these entries, and reaching any server becomes a short, memorable word instead of an IP address you have to look up.

The remote workflow, end to end

Put the pieces together and a normal day of server work looks like this: ssh prod to land on the machine, then every skill from this guide applies unchanged — cd to the app directory, ps aux | grep to check the process is alive, lsof -i :443 to confirm it's serving, edit a config, sudo systemctl restart the service. Push new code up with rsync, pull a file down with scp, and exit when you're done. Nothing in that flow is new — SSH simply relocated your terminal onto a computer on the other side of the world.

That's the payoff the whole guide has been building toward — the reason chapter one insisted the terminal is non-negotiable. Production lives on headless machines, and SSH is the door to every one of them.

There's one skill left, and it's the one you'll lean on hardest when something goes wrong on that remote server. When a deploy fails or an app misbehaves at 2 a.m., the truth of what happened is written down in one place: the logs. The final chapter is how to read them — how to find the one line that matters in a river of thousands, and turn "it's broken" into "here's exactly why."