I work on data center infrastructure. When something breaks at 2 a.m., nobody re-reads a 400-page manual — you reach for the handful of commands you half-remember and hope you get the flags right.

So I started writing one-page cheatsheets for the commands I keep looking up, and publishing them as open source. The first set covered everyday tools (git, docker, curl, jq, regex). This one is the infrastructure set: SSH, systemd, and kubectl — the three I actually keep open during incidents.

Every command below is copied verbatim from the cheatsheets, and every flag in them was checked against the real tools (OpenSSH 9.6 man pages, systemd 255, the official kubectl reference).

SSH: tunnels and jump hosts, not just login

Most people use SSH to log in. The parts that save me are the forwarding trio and ProxyJump.

Bring a remote port to your machine:

ssh -L 8080:localhost:80 deploy@example.com # http://localhost:8080 on YOUR machine now hits port 80 on the server ssh -L 5433:db.internal:5432 deploy@example.com # ...or reach a third machine (db.internal) through the server you're logged into 

Bake a bastion hop into ~/.ssh/config once, and every tool inherits it:

Host bastion HostName bastion.example.com User ec2-user IdentityFile ~/.ssh/id_ed25519 Host internal HostName 192.0.2.10 User deploy ProxyJump bastion 
ssh internal # the hop happens automatically — # scp / sftp / rsync to "internal" get it for free too 

And the smallest gotcha in the whole set: scp's port flag is capital -P; ssh uses lowercase -p. That mix-up is the #1 reason "scp works but ssh doesn't" (and vice versa).

Full sheet (28 entries: keys, config, forwarding, hardening): https://github.com/Ezra-Zhao/ssh-cheatsheet

systemd: read the journal like you mean it

The service commands everyone knows are start/stop/status. The ones that matter in an incident:

sudo systemctl restart nginx # full stop + start; drops connections sudo systemctl reload nginx # re-read config WITHOUT restarting, if the unit supports it sudo systemctl reload-or-restart nginx # reload if supported, otherwise restart — the safe default 

After a crash or a hang, the previous boot's journal is where the answer lives:

journalctl -b # this boot only journalctl -b -1 # the PREVIOUS boot — where you look after a crash or a hang journalctl --list-boots # list recorded boots with IDs and time ranges, then pick with -b <id> 

Filter by priority instead of scrolling:

journalctl -p err # errors and worse (this boot) journalctl -p warning -b -1 # warnings and worse, previous boot 

And see the unit the way systemd actually sees it — base file plus every drop-in merged:

systemctl cat nginx # base file + every drop-in merged, each piece labelled with its file path # this is the ground truth — what you edited is not always what is running 

Full sheet (30 entries: services, journal, unit files, timers): https://github.com/Ezra-Zhao/systemd-cheatsheet

kubectl: triage in the right order

My triage order is: describe first, events second, previous-container logs third.

kubectl describe pod web-6d9f7c5b4-x2abc # why pending/crashing? read the Events at the bottom kubectl describe node node-1 # capacity, allocatable, taints, conditions 
kubectl get events --sort-by=.lastTimestamp # OOMKilled, FailedScheduling, pull errors live here kubectl get events -n prod --sort-by=.lastTimestamp 
kubectl logs -p web-6d9f7c5b4-x2abc # CrashLoopBackOff? this is where the real error is 

(-p reads the previous, crashed container — the current one just shows you the restart loop.)

When a release goes wrong, the rollback is one command:

kubectl rollout history deployment/web # list revisions kubectl rollout undo deployment/web # back to the previous revision kubectl rollout undo deployment/web --to-revision=2 

Full sheet (30 entries: status, deploy, logs, inside the container): https://github.com/Ezra-Zhao/kubectl-cheatsheet

The whole set

All fifteen one-page cheatsheets (git, docker, ffmpeg, curl, jq, regex, sql, ssh, kubectl, vim, tmux, systemd, and more) are MIT-licensed, each with a Chinese / Spanish / Portuguese README:

If you find a wrong command or an outdated flag, a PR or a comment is the fastest way to fix it — the sheets only stay useful if they stay accurate.