Developer guide walks through SSH keys stored in the macOS Secure Enclave

A hands-on guide to storing SSH private keys inside the macOS Secure Enclave — where they cannot be copied off the machine — reached the front page of Hacker News. The post, published on gatezh.com by a developer who spent time fighting macOS's built-in tooling, shows that a fully native, hardware-backed SSH setup exists today, documents the errors encountered along the way, and explains why the author ultimately decided not to use it daily.

The problem with keys on disk

According to the post, a conventional SSH key lives in ~/.ssh protected by nothing stronger than file permissions. Any malicious script with read access to the filesystem could copy the key and use it against every server it unlocks — and the author points to recurring scams involving fake interview assignments that ask candidates to clone and run a repository locally. The author had switched to devcontainers to limit the damage but considered that insufficient.

Software vaults do not fully solve it either: the post notes that 1Password, and Bitwarden (which added SSH key support even on its free tier), encrypt keys at rest but still decrypt them in memory when signing. What the author wanted was a key that is physically impossible to extract even from a fully compromised machine. That narrowed the field to a YubiKey hardware token or the Secure Enclave built into the Mac.

How the native setup works

The Secure Enclave is a security subsystem isolated from the main processor. A key generated inside it never exists in memory or on disk; when SSH authenticates, the Enclave signs the challenge, and with biometrics enabled every signature requires a Touch ID approval. Per the author, macOS has shipped this capability since Sequoia.

The setup sketched in the guide:

• Create the identity with sc_auth create-ctk-identity -l "ssh-MacBook" -k p-256-ne -t bio, which requests a non-exportable NIST P-256 key that requires Touch ID on every use.
• Generate a key handle for SSH with ssh-keygen -w /usr/lib/ssh-keychain.dylib -K -N "" — a reference file, not the private key.
• Point SSH at Apple's token provider via export SSH_SK_PROVIDER=/usr/lib/ssh-keychain.dylib.
• Copy the resulting public key (type [email protected]) into the server's authorized_keys as with any other key.

The rough edges

Much of the guide's value is in its troubleshooting. The first sc_auth run failed with an errSecAuthFailed error ("Failed to get bio catacomb UUID for user 502") because the author's Touch ID enrollment had been reset; re-enrolling a fingerprint fixed it. Many older tutorials recommend ssh-add -K, which macOS now flags as deprecated — and the post warns that even the replacement flags target the traditional Keychain, not the CryptoTokenKit identities the Secure Enclave uses.

SSH also will not auto-discover the generated id_ecdsa_sk_rk file, so it must be listed explicitly as an IdentityFile in ~/.ssh/config, placed first if it should be the default. Users running 1Password's SSH agent may hit a conflict, as the author did during testing.

The dealbreaker for the author is cosmetic but real: the Touch ID prompt reads "ctccardtoken needs to authenticate to continue" rather than naming what is requesting the signature. Because the dialog comes from low-level CryptoTokenKit plumbing, the author judged the native approach too unpolished for daily use and noted that the third-party app Secretive offers the same Secure Enclave backing with a clearer interface.

One key is not enough

The post recommends requiring Touch ID for every key rather than keeping a convenience key without biometrics — without it, malware could sign silently, whereas the prompt surfaces every use. The other trade-off is recovery: a Secure Enclave key is bound to one Mac and cannot be exported, so it cannot be backed up. If the machine dies, the key dies with it. The recommended mitigation is to register at least two keys per server, such as the Enclave key plus one from a YubiKey or a second Mac.

Why it matters

Private SSH keys sitting on a laptop disk are one malware execution away from theft, and attackers demonstrably target developers through cloned repositories and fake assignments. The guide shows that genuine hardware-backed protection already ships with macOS and needs no extra device or third-party software — but also that Apple has not finished the experience: cryptic errors, deprecated flags in most online instructions, no key auto-discovery, and a permission dialog users cannot meaningfully evaluate. For developers who want the security without the friction, Secretive or a hardware key remains the pragmatic route, while the native toolchain is worth watching as it matures. Either way, the no-backup property changes operational planning: recovery shifts from restoring a file to keeping a second registered key on every server.