Networking

Core idea

Networking from the shell falls into three buckets, and a handful of commands cover all three. Diagnose the network with ping (is the host reachable?) and traceroute (what path do packets take?). Configure with ip (which interfaces, which addresses, which routes?). Use it with ssh (run a shell on a remote machine, securely), scp/sftp (move files securely), curl/wget (fetch URLs), and rsync (efficient incremental sync). The thread running through every modern workflow is encryption: SSH provides an authenticated, encrypted tunnel that the other tools (scp, sftp, rsync --rsh=ssh) ride inside.

Shotts's argument: The old "cleartext" tools — telnet, rlogin, plain ftp — were designed for a friendlier internet. On the modern internet, anything that puts a password on the wire in plain text is unacceptable. Use SSH for everything that crosses an untrusted network.

Why it matters

Diagnosis before remediation

When something is broken — a website doesn't load, a server seems down — instinct says "reboot." A more productive instinct is to measure. ping host tells you whether the host is reachable at all. traceroute host tells you where, along the path, packets stop arriving. Together they isolate the failure to your machine, your gateway, your ISP, or the destination — in seconds, without touching configuration.

SSH is the universal remote

Every serious Linux administrator's daily life consists of ssh user@host. The protocol authenticates the remote host (preventing impostors), encrypts every byte in transit (preventing eavesdropping), and works identically across cloud providers, embedded devices, and your laptop. Mastering SSH — and especially key-based authentication and the ~/.ssh/config file — pays off every working day.

One tunnel, many uses

The SSH connection is not just a remote terminal. It is a generic encrypted byte pipe. scp and sftp move files through it. rsync --rsh=ssh runs efficient incremental backups through it. SSH agent forwarding lets you authenticate from a jump host. X11 forwarding (and these days, port forwarding for web UIs) lets you tunnel arbitrary protocols. Once you have ssh, you have everything.

Bytes flow at the speed of the slowest link

Knowing how to download — curl -O url for one-shot, wget for recursive, rsync for incremental — saves bandwidth and time. rsync in particular only sends deltas: re-running it after a small change re-transmits only the changed blocks, which is the difference between minutes and seconds on a large directory.

Key takeaways

Mental model

Layered tools for layered questions

A practical network problem decomposes into layers. Physical: is the cable in, is wifi associated? Link: does the interface have an IP? Network: can I reach the gateway? Internet: can I reach the destination? Application: does the destination service respond correctly? Different commands answer different layers.

Copy sourceZoom

The SSH handshake

When you type ssh user@host, several things happen in sequence — and understanding the order helps with the "host key changed" and "authentication failed" errors you'll eventually hit.

Copy sourceZoom

Files versus interactive sessions

Three families ride the same SSH tunnel for different purposes. ssh runs a remote shell. scp is non-interactive: it copies one or more files in a single command and exits. sftp is interactive: it opens a session where you cd, ls, put, get like an FTP client, but encrypted. rsync over SSH does incremental delta-sync. Pick by intent — for one file, scp; for browsing, sftp; for repeated sync, rsync.

Practical application

When a service is unreachable, run ping first, then traceroute. If ping succeeds but the application doesn't respond, the network is fine and the problem is in the app or its firewall. If ping fails but ip r shows the right gateway, the problem is upstream. If even the gateway doesn't respond to ping, check the interface with ip a — you may have lost your local IP (DHCP lease expired, wifi dropped).

For downloading: prefer curl -O <url> for one file (CDN-friendly, scriptable), wget -r <url> for mirroring a static site, and rsync whenever you're copying repeatedly to the same destination — the bandwidth savings compound.

For bulk transfer between two of your own machines, rsync -avzh --rsh=ssh src/ host:dest/ is the workhorse. -a preserves attributes, -v shows progress, -z compresses on the wire, -h prints human-readable sizes, --rsh=ssh is now the default but harmless to include.

Example

You've just rented a $5/month VPS to host a personal site. Walk through the full network workflow from the local laptop:

1. Verify the VPS is up. ping -c 4 198.51.100.42. Expect four replies, ~50–150 ms round-trip from a continent away.
2. Check the path. traceroute 198.51.100.42. You should see your local router, then your ISP, then a peering exchange, then your VPS provider's edge. Asterisks at intermediate hops are normal; asterisks at the destination are a problem.
3. Open a remote shell. ssh root@198.51.100.42. The first connection prompts: The authenticity of host '198.51.100.42' can't be established. ED25519 key fingerprint is SHA256:abc... Are you sure you want to continue (yes/no)? Compare the fingerprint to one the provider showed you in the control panel; only then type yes. The fingerprint is added to ~/.ssh/known_hosts and never asked again unless it changes.
4. Create a user and key-based access. On the VPS: adduser deploy, mkdir /home/deploy/.ssh. Log out, then from your laptop: ssh-copy-id deploy@198.51.100.42. Now ssh deploy@198.51.100.42 no longer prompts for a password.
5. Push your site. rsync -avzh --delete ~/projects/site/ deploy@198.51.100.42:/var/www/site/. The first run copies everything; subsequent runs send only changed files.
6. Verify in a browser. If the page doesn't load, ssh deploy@198.51.100.42 back in and check the web server log — the network was already proven good in steps 1–3.

Five distinct tools, one tunnel, one mental model. The same routine scales from a hobby VPS to a fleet of production machines.

Related lessons