It happens to almost everyone, eventually.

You stage your changes, type git commit -am "wip", push — and a few minutes later realize that id_rsa (or .env, or credentials.json) was sitting in the working directory the whole time. The file is now in the remote, in every clone, in every CI cache, and worst of all: in the git history, where a simple git rm won’t touch it.

This post walks through fixing exactly that scenario with BFG Repo-Cleaner — a tool purpose-built for ripping unwanted blobs out of git history.

I have been using SSH for over twenty years and I still occasionally forget the flag for tunneling. Not because the syntax is hard, but because SSH has so many little features that you only reach for once every few months — and by the time you need them again, your fingers have moved on.

So this post is the field guide I wish I could hand to past-me. Not “how SSH works under the hood” — there are excellent treatises for that. Just the dozen or so commands and config patterns I genuinely reach for during a normal week of operations work.

Last January, I sat down to review a server’s auth logs and felt a familiar knot in my stomach.

Over 50,000 failed SSH login attempts — in a single month. Bots methodically hammering port 22 with common credentials, dictionary wordlists, and leaked password databases. Just waiting for one mistake.

That audit changed how I think about SSH security. Not as a checkbox, but as a discipline. What follows are the nine hardening techniques I’ve since applied across dozens of production servers. Not theoretical guidelines — actual configurations with real, measurable outcomes.

Convert openssh keys to rsa keys

from something that starts with

-----BEGIN OPENSSH PRIVATE KEY-----

to something that starts with

-----BEGIN RSA PRIVATE KEY-----