Protecting SSH Keys with macOS Secure Enclave

Security features like this works, until it doesn't.

When I installed WireGuard on macOS, I was happy to discover that it stores private keys in the system keychain. Accessing the private key requires Touch ID.

Then one day after a system upgrade, the WireGuard app crashed on startup with:

  [APP] Unable to open config from keychain: -25300

Then the app deleted all profiles because they are all "orphaned", apparently for "keychain consistency" [0].

From then on, I just use a text editor to edit my WireGuard configuration files, and import them to the app. The bug still exists to this day [1].

[0] https://github.com/WireGuard/wireguard-apple/commit/dfb685f2...

[1] https://www.reddit.com/r/WireGuard/comments/wyt828/osx_wireg...

I decided years ago that I want to protect my keys with a hardware device that is independent of the vendor of the machine that I'm currently using. I also want to have backup keys and I want to be able to freely move them around various physical locations. Or have a backup shipped to me across the world if necessary.

YubiKeys were the only solution that fit these requirements, so I went with those. I have been using them for the last ten years or so and I've been very happy with this solution. See https://github.com/drduh/YubiKey-Guide for a description of how to make your RSA keys stored on YubiKeys work with GPG and SSH at the same time.

One fundamental problem with agentic development is that accessing the secure enclave key requires human presence. If you're running headless and aren't logged in, Secretive (not sure about others) will not be able to access the enclave, even when you only chose "notify" and not "touchid".

This is why I'm skeptical that the approach can scale reliably, even though I'm relying on it today. (Yes, PATs would fix this, but the enclave model is what I'm trying to retain for now.) What I've done instead is wrote a small daemon that sets the SSH authentication socket and does agent forwarding. This works when I'm traveling with laptop...but not yet from my mobile phone.

Example:

    Laptop                                   Remote Mac
   ┌─────────────────────┐                  ┌──────────────────────────┐
   │ Secretive           │                  │ ssh / git commit -S      │
   │ (Secure Enclave)    │                  │          │               │
   │        ▲            │  ForwardAgent    │          ▼               │
   │        └── ssh ─────┼─────────────────►│  ~/.ssh/agent.sock       │
   │                     │                  │  (stable proxy)          │
   └─────────────────────┘                  │      │          │        │
                                            │      ▼          ▼        │
                                            │  forwarded   local       │
                                            │  laptop      Secretive   │
                                            │  agent       (if you sit │
                                            │              at this Mac)│
                                            └──────────────────────────┘

NB: I'm not using Rex instead of herdr and because Rex uses its own protocol, I always need to have one SSH tunnel to reset the remote agent socket. Not optimal, but it works. All of this feels wrong from a UX perspective, and it feels like I'm holding on too hard on secure enclave for what my use cases are. Feedback appreciated!

I’ve been a happy user of Secretive for years, including for Git commit signature which it make it a separate key with interaction but not for pull / push. I find the trade off ideal for GitHub.com and have other keys with different setup for servers.

SSH keys in plaintext was one of the first thing that bagel [0] our developer endpoint secret detection focused on. Then we embedded bagel as a library in our developer endpoint protection [1].

[0] https://boostsecurityio.github.io/bagel/ [1] https://boostsecurityio.github.io/dazio/docs/install/

The article starts on an incorrect premise.

The author says he doesn’t like the idea of having keys sitting on his file system ready to be snatched by bad actors.

That’s why they should be passphrase protected.

You use ssh agent to store the keys in memory and for convenience you can store the passphrases in keychain. MacOS OpenSSH has the UseKeychain config directive for that.

I use Yubikey/FIDO2 myself, but not because private keys cannot be protected on a file system.

I use 1Password's `op` for this, but with an allowance: my dev environment keys.

I found I was getting fingerprint fatigue. Do I need a fingerprint request every time my dev server wants to connect to dev Supabase? No. That's expected, and zero risk. There's no data there.

I worried that a nefarious request would be auto-approved by me. When you see 20 requests a day, your muscle memory just reaches for the sensor.

So I have a separate 1Password vault that a service account [0] can read. That token is in my environment as OP_SERVICE_ACCOUNT_TOKEN, which the `op` tool understands.

It also has access to a vault with 'AI-safe' keys that I want Claude to be able to access without asking me.

Now, these requests work invisibly. And when I see a fingerprint popup, it's unusual, and I don't auto-approve by habit.

I also keep an item called '_One-day keys' in a separate vault. (The underscore just pushing it to the top of the list for easy access.)

It has prod keys, mostly restricted read-only. If required, I move that over to the open vault. Claude knows this item and has instructions to remind me to move it back out when it's finished what it was doing.

[0]: https://www.1password.dev/service-accounts/get-started

You should checkout the TKey (https://www.tillitis.se/products/tkey/)

It's effectively an open source version of a YubiKey, the hardware itself is all open source and it handles ed255519 SSH keys really well.

inb4 they're not the same, I know, I really like what the TKey team is doing.

Secure Enclave, TPM and other such security features are unfortunately so badly documented and need so many hoops to jump through to get them working, with any mistake either causing you to be locked out completely or to not give you the protection you wanted. There really should be a better way to make these technologies usable...

The `sc_auth` trick was posted about a year ago, since macOS 26 Tahoe added the SSH related functions into the keychain.dylib.

> https://news.ycombinator.com/item?id=46025721

One of the problems I constantly face is that the SSH configuration is not portable when I use these esoteric things. Even with Secretive (which plugs a simple SSH socket), remote agent forwarding sometimes fail. (ie. Due to the old version on the server or configuration issue, or something else setting SSH_AUTH_SOCK...)

Moreover, it is not possible to drop these files into a file-sharing folder, like OneDrive or iCloudDrive or SMB share, and share them with many hosts at the same time. (Especially when different operating systems are involved...)

I found the hacker way simplest and easiest; put a basic Makefile with bunch of rules, have a "central" host/machine to distribute the keys and configuration from that point on...

Why would you trust the NIST P-256 curve?

It is not one of the cryptographically safe curves, likely intentionally so.

https://safecurves.cr.yp.to/

I used yubikeys for ssh for years. First via the older clunky gpg as ssh key feature. Then via the FIDO api. My biggest issue was the chicken and egg issue when using this setup on a new machine or god forbid in a container etc. windows and WLS wasn’t super thrilled either. I switched to 1Password ssh because I actually like the fact that I can simply share my keys. It’s still not perfect. Agent forwarding needs an extra configuration and depending how many keys you have and how verbose your ssh config gets it becomes also very finicky. This solution feels for me like a slight setback because it’s a macOS only solution. If you have a Linux or windows machine next to a Mac you have to deal with the insecure key file on your hard drive again either via yubi keys or software solutions.

But I think I would take this over a yubikey. I really disliked the fact that one usb port was constantly in use.

These days I'm mainly doing development inside VM's. Previously I was embedding Github key to each VM, but since I setup Secure Enclave (with Secretive), I'm only forwarding it's agent to VM and each git action on origin now requires approval using fingerprint reader. I think this a good way to prevent malware from gaining access to github

I wish there was a way to cache the touch. As it stands, this is mostly unusable for commit signing in a rebase-heavy workflow.

On macOS use “Secretive”. It’s a small app that can generate keys from Secure Enclave and prompts you with touchid whenever those keys are being used

On iOS/ipad/(also macOS) you can also use the SSH terminal emulator Termius which has support for SE keys built in as well. So I have the set of keys synced to my VPS, this way I know that only my physical devices can log in and nothing else.

Has anyone managed to extract a fingerprint reader from an Apple Magic Keyboard? I usually run my Macs in clamshell mode.

The thing I don't like about the Secure Enclave is that it does not yet support ed25519 keys.

It's a shame that the poster doesn't mention what they ended up using instead in their update. Presumably a hardware key.

What's the general consensus around ssh-agent?

It's often the case that we make much effort into securing the key but expose it via an open agent socket at a well known path or use an open control master path for multiplexing.

Certain automation and dev tools like Ansible make it a pain to work if agent key requires a confirmation.

Not sure how many people feel like this, the risk in plain sight is a lot easier to handle than the risk hiding under the layers. You can keep shifting the storage for the key, one way or another you have to open up a channel to access to key or use the key. That channel would then become the vulnerability target.

Somebody posted a tool here in the last couple of weeks that was doing this (using macos secure storage for local credentials/ keys)

I was looking in to this just earlier today. The native macos version worries me a little because it seems someone just happened to discover it in MacOS, rather than it being a documented feature. The worry being Apple could change or remove it later locking you out of your keys since they never advertised this as a thing you could do.

> That ssh: at the end is the FIDO2 application ID — it’s part of the key, not a comment.

I think this is incorrect and the "ssh:" at the end is indeed a comment.

If someone like the native approach or is familiar with SeKey, I created sekey-sh to simplify the process: https://github.com/cavoirom/sekey-sh

Work on macOS 26 and later.

I have applied this at our company using Secretive, and extended to sudo over SSH: The remote end uses an SSH Agent PAM module that forwards sudo requests to the connected SSH Agent, which is Secretive running on the employee Macs, so we get remote sudo with TouchID prompts.

No more passwords to enter anywhere, and whatever an (AI) agent or malware is trying to do will require a human interaction at least, and not work when the screen is locked. The public keys authorized for this are distributed to the fleet via puppet, so we get control over who gets to sudo permissions and can easily provision or decommission machines.

Pretty stoked about it so far.

Isn't a GitHub app project Secretive doing that but better?

I've been using Secretive (a nice software wrapper for these) for a few days for my Github keys (where 1Password holds the rest of my SSH keys). It works nicely, but obviously you can't back up a key that started life in a secure enclave, so you'll need alternative access arrangements for anything you setup that way.

.

1

ss

We should have had this 20 years ago. It is almost pathological how difficult it is to reliably use hardware keys as ssh credentials.

..

[dead]

[flagged]