To protect an SSH key, create it inside hardware it can’t leave: the Mac’s Secure Enclave or a YubiKey. Then require Touch ID or a tap for every use. A key file with tight permissions and a password vault’s SSH agent both leave a copy that malware can reach.
In Protecting SSH Keys with macOS Secure Enclave, Serge Gatezh walks through all three options and the setup that worked. Below is why the first two fail, how to set up the third, and what it costs.
Table of Contents
- Plan A: a key file in ~/.ssh
- Plan B: a password vault’s SSH agent
- Plan C: a key that never leaves hardware
- Set it up on a Mac in four commands
- The catch: no backup
- Does it break automation?
- FAQ
- Sources
Plan A: a key file in ~/.ssh
Most keys live in ~/.ssh/id_ed25519, protected only by file permissions. Gatezh points out that any malicious script with access to your files can copy the key and reach every server it unlocks. He names a real path in: fake interview assignments that ask you to clone a repo and run it. He moved to devcontainers for that reason, and says even that wasn’t enough.
A passphrase helps, one developer in the discussion argued, especially with the passphrase kept in the macOS keychain. Another replied that malware can still log the passphrase or read the key from memory once it’s unlocked.
Plan B: a password vault’s SSH agent
1Password and Bitwarden can both hold SSH keys and serve them through their own agent. Gatezh already uses 1Password, and notes Bitwarden added SSH keys even on its free tier. The problem he describes: the key is encrypted at rest but decrypted in memory when it’s used. It’s still a software secret.
He wanted a key that can’t be extracted even from a fully compromised Mac. Only hardware gives you that.
Plan C: a key that never leaves hardware
Since macOS Sequoia, a Mac can create SSH keys inside the Secure Enclave, a security chip isolated from the main processor. The private key is generated there and never leaves. SSH asks the chip to sign each login challenge, and with Touch ID on, you approve every signature.
| Regular key | Secure Enclave key | |
|---|---|---|
| Private key lives in | ~/.ssh/id_ed25519 |
The Secure Enclave |
| On disk | The private key | A reference, useless on another Mac |
| Server setup | Public key in authorized_keys |
Same |
| Connecting | Just works | Touch ID, then works |
A YubiKey gives you the same property on a device you carry between machines.
Set it up on a Mac in four commands
Gatezh’s steps, condensed:
# 1. Create a non-exportable P-256 key that needs Touch ID for every use
sc_auth create-ctk-identity -l "ssh-MacBook" -k p-256-ne -t bio
# 2. Export the key handle SSH uses (press Enter at the PIN prompt)
ssh-keygen -w /usr/lib/ssh-keychain.dylib -K -N ""
mv id_ecdsa_sk_rk* ~/.ssh/
# 3. Point SSH at the Secure Enclave provider (add to ~/.zshrc)
export SSH_SK_PROVIDER=/usr/lib/ssh-keychain.dylib
# 4. Install the public key on the server
ssh-copy-id -i ~/.ssh/id_ecdsa_sk_rk.pub user@your-server
Then add IdentityFile ~/.ssh/id_ecdsa_sk_rk at the top of the Host * block in ~/.ssh/config. SSH doesn’t find that filename on its own. Skip ssh-add -K from older guides: it’s deprecated and only works with the regular keychain.
Gatezh keeps -t bio on every key. Without it, malware could use the key silently. With it, he always knows when something signs.
The Touch ID prompt reads “ctkcardtoken needs to authenticate to continue”, which he finds ugly. Secretive uses the same Secure Enclave with a friendlier interface.
The catch: no backup
A key that can’t be exported can’t be backed up. If the Mac dies, the key dies with it. Gatezh’s fix is a second key: register the Secure Enclave key and a YubiKey key (or one from another Mac) in every server’s authorized_keys.
Does it break automation?
A hardware key needs a human present. One developer running AI agents headless said that makes the setup hard to scale. Another called it the point: no agent reaches his production servers unless he touches the key. I agree with the second view for production. For dev environments, a separate key with a narrower scope keeps the fingerprint prompts rare enough that you still read them.
What to do this week: run ls ~/.ssh and count the private keys sitting on disk. Then move the one that reaches production into hardware first.
FAQ
Is a passphrase on my SSH key enough?
It stops someone who only copies the file. It doesn’t stop malware that logs the passphrase or reads the unlocked key from memory.
Can I back up a Secure Enclave SSH key?
No. It’s non-exportable by design. Register a second key, such as a YubiKey, on every server instead.
Which macOS version supports Secure Enclave SSH keys?
Gatezh says macOS Sequoia and Tahoe support SSH keys backed by the Secure Enclave through sc_auth and /usr/lib/ssh-keychain.dylib.
Secure Enclave or YubiKey?
The Secure Enclave needs no extra device but is tied to one Mac. A YubiKey moves between machines. Many setups use both.
Why does SSH ignore my new key?
SSH only auto-discovers standard names like id_ed25519. List id_ecdsa_sk_rk with IdentityFile in ~/.ssh/config.
Does a 1Password SSH agent conflict with this?
It can. Gatezh had to comment out 1Password’s IdentityAgent line while testing.
Sources
- Article: Protecting SSH Keys with macOS Secure Enclave by Serge Gatezh.
- Discussion: https://news.ycombinator.com/item?id=50449748, for the passphrase debate and the headless-agent trade-off.
- Related: How to protect an internal admin tool: good, better, best.