Protecting SSH Keys with macOS Secure Enclave

I’ve been paranoid about my SSH secrets for a while now. They simply sit there in ~/.ssh/secured by absolutely nothing however file approvals. Any harmful script that gets access to my filesystem might simply copy them and enter all my servers. There have actually been lots of stories out there online about phony interview projects that asked to clone a repo and run it on your regional device. This is among the factors I changed totally to utilizing devcontainers, however even that was not actually adequate for me (and it should not suffice for you or any person else truly).

I lastly chose to do something about it.TL; DRI have actually chosen to NOT opt for the native macOS Secure Enclave technique (utilizing just out-of-the-box tools) due to the fact that it wound up plain unsightly and I can’t deal with that. It is a completely practical, working service that I would certainly utilize otherwise.The Options

After some research study, I discovered a number of methods to safeguard SSH secrets:

• Native macOS Secure Enclave — no third-party apps, developed into the OS
• Deceptive — third-party app that shops type in Secure Enclave
• YubiKey — hardware security secret with FIDO2 assistance
• 1Password/ Bitwarden — shop type in an encrypted vault, utilize their SSH representative

I currently utilize 1Password, however I may change to something else in the future. Bitwarden just recently included SSH crucial assistance (even on the totally free tier!), however it’s still a software application option– the secrets are secured at rest however decrypted in memory when utilized.

What I actually desired was hardware-backed security. The personal secret needs to actually be difficult to extract, even if my Mac is completely jeopardized.

That left me with YubiKey or Secure Enclave. I have a YubiKey 5C, however I wished to attempt the native method initially– no additional hardware to bring around, no third-party apps to keep.

What is Secure Enclave SSH?

Considering that macOS Sequoia (and Tahoe), macOS supports SSH secrets backed by the Secure Enclave, a security subsystem on the Mac’s chip that is separated from the primary processor. The personal secret is developed inside it and never ever leaves.

When you SSH someplace, your Mac asks the Secure Enclave to sign the authentication difficulty. If you make it possible for Touch ID, you need to authorize each finalizing operation. The real personal crucial never ever exists in memory or on disk.

The workflow is remarkably comparable to routine SSH secrets:

Element	Routine SSH Key	Protect Enclave Key
Where personal crucial lives	~/.ssh/id_ed25519 (a file)	Protect Enclave
What’s on disk	Real personal crucial	Simply a recommendation (worthless without this Mac)
Setup on remote server	Copy public secret to authorized_keys	Very same
Linking	Simply works	Touch ID timely, then works

Setting It UpAction 1: Create the Secure Enclave Key

macOS supplies the sc_auth command (Smart Card Authentication) to handle CryptoTokenKit identities. In spite of the name, it deals with Secure Enclave too.

Breaking this down:

• -l "ssh-MacBook" — a label for your recommendation (just noticeable in your area)
• -k p-256-ne — NIST P-256 curve, non-exportable (the secret can never ever leave Secure Enclave)
• -t bio — need biometric (Touch ID) for each usage

You’ll be triggered for Touch ID to develop the secret.

Issue 1: Touch ID Error

When I initially ran this command, I got a frightening mistake:

Mistake: Error Domain=NSOSStatusErrorDomain Code=-25293 "Failed to generate keypair"
(errKCAuthFailed/ errSecAuthFailed:/ Authorization/Authentication stopped working.) UserInfo=


Ends up my Touch ID registration got reset in some way. After re-enrolling my finger print in System Settings → Touch ID & & Passwordthe command worked fine.

You can confirm the secret was developed:

Output:

Key Type Public Key Hash Prot Label Common Name Valid To Valid
p-256-ne A71277F0BC5825A7B3576D014F31282A866EF3BC bio ssh-MacBook ssh-MacBook 2027-01-26, 10:18 YES
Action 2: Export the Key Handle

Now we require to produce a “essential manage” file that SSH can utilize. This is NOT the personal secret– it’s simply a referral that informs SSH “go ask the Secure Enclave to sign this.”

When triggered for PIN, simply press Enter (it’s not utilized for biometric secrets). Touch ID will turn up. This develops id_ecdsa_sk_rk and id_ecdsa_sk_rk.pub in your present directory site.

Move them to your SSH directory site:

Action 3: Configure SSH to Use the Secure Enclave Provider

Include this to your ~/.zshrc (or ~/.bashrc:

Refill your shell:

Issue 2: Outdated Commands Everywhere

If you look for “macOS Secure Enclave SSH” online, you’ll discover a great deal of guides informing you to run ssh-add -KDo not. It’s deprecated:

WARNING: The -K and -A flags are deprecated and have been replaced
by the --apple-use-keychain and --apple-load-keychain
flags, respectively.


And even the brand-new flags do not work for Secure Enclave secrets– they’re for the conventional macOS Keychain, not CryptoTokenKit. The SSH_SK_PROVIDER environment variable is the right technique.

Step 4: Get Your Public Key

Output:

[email protected] AAAAInNrLWVjZHNhLXNoYTIt... ssh:


That ssh: at the end is the FIDO2 application ID– it’s part of the secret, not a remark. You can include your own remark after it when copying to authorized_keys:

[email protected] AAAAInNrLWVjZHNhLXNoYTIt... ssh: macbook-secure-enclave
Step 5: Copy to Your Server

Or by hand paste the general public secret (with your remark) into ~/.ssh/authorized_keys on the server.

Action 6: Configure ~/. ssh/configIssue 3: SSH Doesn’t Find the Key

After setting whatever up, I attempted to SSH … and it requested for my password.

The verbose output (ssh -vvvrevealed SSH was just attempting my old RSA secret:

debug1: Offering public key: /Users/sergii/.ssh/id_rsa RSA SHA256:...


The issue: SSH does not immediately try to find files called id_ecdsa_sk_rkIt just auto-discovers basic names like id_rsa id_ed25519 id_ecdsa

The repair is to clearly include it to your ~/.ssh/config:

SSH attempts identity files in order, so put the Secure Enclave secret initially if you desire it to be the default.

⚠ Keep in mind: If you’re utilizing 1Password’s SSH representative (IdentityAgentit may contravene this setup. I needed to comment it out while screening.

Action 7: Test It

You must get a Touch ID trigger, then link.

The Ugly Touch ID Prompt

Something I’m not delighted about: the Touch ID dialog states “ctccardtoken requirements to confirm to continue” rather of something friendly like” SSH wishes to utilize your secret.”

This is since the timely originates from CryptoTokenKit– a low-level structure that Apple hasn’t polished for end-user SSH. If this troubles you, Deceptive offers a much better UI while still utilizing Secure Enclave under the hood.

Why Touch ID for Everything?

I at first considered developing 2 secrets– one with Touch ID for “essential” servers, one without for benefit (like Git operations).

Then I recognized: without -t biomalware might utilize my essential calmly. With -t bioI constantly understand when something is utilizing my SSH secret. A couple of additional taps each day is a little cost for that exposure.

My suggestion if you’re preparing to keep your SSH secrets this method: simply utilize -t bio for whatever. If it ever gets frustrating, you can constantly produce a 2nd secret later on.

The Catch: No Backups

Protect Enclave secrets are connected to your particular Mac. If your Mac passes away, the secrets pass away with it.

That’s by style: the crucial can’t be exported, so it can’t be supported either. Keep more than one crucial rather. Include your Secure Enclave crucial AND a backup secret (from a YubiKey, or another Mac) to your servers’ authorized_keysIf one gadget is lost, you still have gain access to through the other.

Last Thoughts

It appears to be an appropriate method to keep your SSH secrets safely, and it is way much better than keeping them on your disk drive.

With the execution above you get:

• ✅ Private essential actually can not be taken (it’s in hardware)
• ✅ Every SSH operation needs Touch ID (I understand when my secret is utilized)
• ✅ No third-party apps required
• ✅ Works with existing authorized_keys workflow

I’ve been rather shocked by the ugliness of the UI. Uncertain why Apple launched such an unpolished thing. In each and every discussion they have an area on security (where their Apple logo design ends up being an Apple lock), so I was anticipating a real visually attractive search for their security functions. It is absolutely not the case. My sense of appeal is not suitable with this ugliness, so I will be checking out other services to keep my SSH type in Secure Enclave such as Secretive

I likewise still require a backup choice in case anything takes place to my Mac.