DEV Community

Guangyi Zhao
Guangyi Zhao

Posted on

SSH, systemd, kubectl: the one-page cheatsheets I keep open during incidents

#kubernetes #linux #tutorial #devops

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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode 
ssh internal    # the hop happens automatically —
                # scp / sftp / rsync to "internal" get it for free too
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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>
Enter fullscreen mode Exit fullscreen mode

Filter by priority instead of scrolling:

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

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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode 
kubectl get events --sort-by=.lastTimestamp        # OOMKilled, FailedScheduling, pull errors live here
kubectl get events -n prod --sort-by=.lastTimestamp
Enter fullscreen mode Exit fullscreen mode 
kubectl logs -p web-6d9f7c5b4-x2abc   # CrashLoopBackOff? this is where the real error is
Enter fullscreen mode Exit fullscreen mode

(-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
Enter fullscreen mode Exit fullscreen mode

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.

Top comments (0)