The sc_auth command generates a non‑exportable SSH key inside the Mac’s Secure Enclave.
MACOS SECURE ENCLAVE SSH KEYS: PRACTICAL GUIDE AND PITFALLS
*Serge Gatezh documents a native macOS Secure Enclave workflow for SSH keys, exposing hidden errors and deprecated flags. The piece weighs functional security against usability friction.*
Serge Gatezh has been paranoid about his SSH keys for months. They sit in ~/.ssh protected only by file permissions. A malicious script that reads the filesystem can copy them and walk into every server the keys unlock. Recent fake interview assignments that ask developers to clone and run a repo illustrate how easy a compromised machine can betray credentials.
To stop the bleed, Gatezh explored macOS’s Secure Enclave, a hardware‑isolated subsystem introduced in macOS Sequoia. The enclave can generate an SSH key that never leaves the chip, requiring Touch ID for each signing operation. He followed the native workflow, documented each command, and ran into two show‑stopping problems: a Touch ID enrollment error and a cascade of deprecated SSH flags that left the key invisible to the client.
The result is a step‑by‑step guide, a list of pitfalls, and a candid verdict: the native solution works but is too ugly to adopt in daily practice.
How does macOS Secure Enclave protect SSH keys?
macOS Secure Enclave SSH keys differ from traditional files. The private key is generated inside the enclave using the p‑256‑ne curve and never appears on disk or in RAM. The only on‑disk artifact is a reference file that tells SSH to ask the enclave to sign a challenge. When Touch ID is enabled, each SSH connection triggers a biometric prompt, and the enclave returns the signature. The public key, prefixed with sk‑ecdsa‑sha2‑nistp256@openssh.com, is copied to the remote server’s authorized_keys just like any other key. The workflow mirrors standard SSH: copy public key, connect, authenticate—except the private material stays locked inside the silicon.
Step‑by‑step setup using native tools
Creating a Secure Enclave key starts with sc_auth. The command `sc_auth create-ctk-identity -l "ssh-MacBook" -k p-256-ne -t bio` labels the identity, selects the non‑exportable P‑256 curve, and forces biometric use. After re‑enrolling Touch ID, the command succeeds and `sc_auth list-ctk-identities` shows a valid entry through 2027‑01‑26. Next, generate a key handle with `ssh-keygen -w /usr/lib/ssh-keychain.dylib -K -N ""`. Press Enter at the PIN prompt; Touch ID pops up. Move the resulting id_ecdsa_sk_rk* files into ~/.ssh. Set the provider with `export SSH_SK_PROVIDER=/usr/lib/ssh-keychain.dylib` in the shell rc file. Finally, extract the public key via `cat ~/.ssh/id_ecdsa_sk_rk.pub`, copy it to the server with ssh‑copy‑id, and optionally add a comment.
Common errors and how to resolve them
The first obstacle was a Touch ID error: “Failed to generate keypair” with code -25293, caused by a reset biometric enrollment. Re‑enrolling the fingerprint resolved it. A second snag involved outdated documentation. Guides still recommend `ssh-add -K`, but the flags are deprecated and only affect the traditional Keychain, not CryptoTokenKit. The correct method is the SSH_SK_PROVIDER variable; the newer `--apple-use-keychain` flag does not apply to enclave keys. A third issue appears when SSH cannot locate the key after setup. Without the provider variable, the client falls back to the regular keychain and reports the key missing, forcing the user to adjust the environment.
Why the author rejected the native approach
Gatezh ultimately rejected the native approach. He calls the workflow “plain ugly” and says he can’t live with that aesthetic, even though the solution is fully functional. The need to juggle sc_auth, custom key handles, and environment variables adds friction compared with third‑party tools like Secretive or hardware tokens such as YubiKey. Those alternatives store keys in the enclave or a separate device but provide smoother integration. Gatezh notes he already uses 1Password for SSH agents and may switch to Bitwarden, but he still prefers hardware‑backed security. The verdict: native Secure Enclave works, but usability concerns outweigh the security gain for most users.
Frequently asked questions
Can Touch ID be used with Secure Enclave SSH keys?
Yes; the sc_auth command uses the -t bio flag, which requires a biometric approval for every signing operation. An enrollment reset can cause a generation error, resolved by re‑enrolling the fingerprint.
What command creates a Secure Enclave identity for SSH?
The native tool sc_auth creates the identity: `sc_auth create-ctk-identity -l "ssh-MacBook" -k p-256-ne -t bio`.
Why does ssh-add -K not work for Secure Enclave keys?
The -K flag is deprecated and applies only to the traditional macOS Keychain, not to CryptoTokenKit identities used by Secure Enclave keys; the correct method is setting SSH_SK_PROVIDER.
Hardware‑backed SSH keys raise the bar for credential theft, but the path to adoption must be smooth. macOS provides the building blocks; developers must navigate Touch ID quirks, deprecated flags, and manual provider configuration. As the ecosystem matures, we can expect tighter integration or third‑party wrappers that hide the ugliness. Until then, the choice sits between a functional but clunky native setup and polished alternatives like Secretive or YubiKey. The security community will watch whether Apple refines the experience or leaves it to the fringe.
Sources: [Hacker News – Protecting SSH Keys with macOS Secure Enclave]