>_How the Terminal Works · Lesson 6 of 7

SSH — Your Terminal, Any Machine

The payoff for all this text-protocol archaeology: because a terminal session is just a byte stream, it travels over a network connection perfectly. SSH is how every server on Earth is administered.

Bash

ssh user@server.example.com
# Encrypted connection; the server starts a shell for you;
# your keys flow there, its output flows back. Your
# terminal now controls a machine anywhere on Earth.

# Set up key-based login (no passwords, more secure):
ssh-keygen -t ed25519            # once: makes a keypair
ssh-copy-id user@server          # install public key on server
ssh user@server                  # now logs in with the key

# Run one command instead of a session:
ssh user@server 'df -h'

# Copy files over the same protocol:
scp report.pdf user@server:/tmp/
rsync -av ./site/ user@server:/var/www/   # sync, resumable

Everything from earlier lessons applies unchanged over SSH — pipes, redirection, environment variables, escape codes, vim. The shell doesn't know it's remote; the terminal doesn't know either. Two machines, one byte protocol. This is why the terminal remains the universal server interface while GUIs come and go: bytes over a wire beat pixels over a wire.

Bash

# The one problem: hang up, and your processes die
# (they get SIGHUP when the TTY disappears).

# Solution: terminal multiplexers — tmux (or screen):
tmux                     # start a session on the server
long_running_job.sh      # kick something off
# Ctrl+B then D          # detach — job keeps running
# ...close laptop, fly home, reconnect...
tmux attach              # session exactly as you left it

# tmux also splits panes and windows inside one SSH
# connection — many terminals through one pipe.

✦ Tip
Next steps from here: the Bash track for real command-line fluency, and ~/.ssh/config for saving host aliases (ssh myserver instead of ssh -p 2222 admin@203.0.113.9). Once tmux + ssh feel natural, you can work from anything with a keyboard.