3 min read#ai#infrastructure#engineering

My SSH key sat in a plain file — while the same chip guarded my email password

macOS Tahoe (26.5) has native hardware-backed SSH keys — no third-party software required. The command is sc_auth create-ctk-identity. The key lives inside the Secure Enclave, the same chip that unlocks Touch ID for 1Password and system login.

I use that chip every day — and never once connected it to SSH. The key that opens my infrastructure sat as a plain file, like everyone's, while the same chip spent its time guarding my email password. (the chip wouldn't have minded the extra work)

Not an abstract itch — a week of reading about prompt injection in coding agents on HN got me here. An agent reads a hostile page, the page asks it to read ~/.ssh and send it somewhere. I run agents in a terminal all day and had never thought about what physically stands between them and the key.

Along the way I was also mapping which service lives on which host — contracts changed this year, a couple of providers got cancelled. Mixed up two hosts sharing adjacent IP ranges, trusting the address pattern instead of checking. Caught it against the actual infrastructure code — a comment with the real migration date, not a guess.

What's verified:

sc_auth create-ctk-identity — a real command, documented only in its own --help. The RU tech community (Habr) has covered Secure Enclave + SSH before — Sekey, an unstable third-party agent, verdict "just use a YubiKey." The native replacement that actually fixes that complaint — nobody's written about yet. → -k p-256-ne — non-exportable key. Not "more encrypted" — it physically doesn't exist outside the chip, nothing to export → -t bio — every signature requires Touch ID fresh, not a one-time session unlock → SSH_SK_PROVIDER=/usr/lib/ssh-keychain.dylib — the one line that tells the system ssh to use this path instead of the regular agent → sc_auth list-ctk-identities — empty. No identities, clean slate

What's not verified yet:

Syntax is real, I can see the (empty) identity list. Next is getting the public key out. ssh-keygen -w /usr/lib/ssh-keychain.dylib -K (the resident-key-download flag) fails:

Enter PIN for authenticator: Provider "/usr/lib/ssh-keychain.dylib" returned failure -1
Unable to load resident keys: invalid format

The empty identity list is the likely cause, unconfirmed. The full path — create an identity, pull the public key, run it through ProxyJump, upload to GitHub — not done yet. I'll write it up when it works end to end, or when it gets stuck (that's worth writing up too).

Related reading