Protecting SSH Keys with macOS Secure Enclave

Security features like this works, until it doesn&#x27;t.<p>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.<p>Then one day after a system upgrade, the WireGuard app crashed on startup with:<p><pre><code> [APP] Unable to open config from keychain: -25300 </code></pre> Then the app deleted all profiles because they are all &quot;orphaned&quot;, apparently for &quot;keychain consistency&quot; [0].<p>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].<p>[0] <a href="https:&#x2F;&#x2F;github.com&#x2F;WireGuard&#x2F;wireguard-apple&#x2F;commit&#x2F;dfb685f2580403cc28aeae7428d52f3655d3436b" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;WireGuard&#x2F;wireguard-apple&#x2F;commit&#x2F;dfb685f2...</a><p>[1] <a href="https:&#x2F;&#x2F;www.reddit.com&#x2F;r&#x2F;WireGuard&#x2F;comments&#x2F;wyt828&#x2F;osx_wireguard_config_vanished&#x2F;" rel="nofollow">https:&#x2F;&#x2F;www.reddit.com&#x2F;r&#x2F;WireGuard&#x2F;comments&#x2F;wyt828&#x2F;osx_wireg...</a>

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 &#x2F; push. I find the trade off ideal for GitHub.com and have other keys with different setup for servers.<p>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].<p>[0] <a href="https:&#x2F;&#x2F;boostsecurityio.github.io&#x2F;bagel&#x2F;" rel="nofollow">https:&#x2F;&#x2F;boostsecurityio.github.io&#x2F;bagel&#x2F;</a> [1] <a href="https:&#x2F;&#x2F;boostsecurityio.github.io&#x2F;dazio&#x2F;docs&#x2F;install&#x2F;" rel="nofollow">https:&#x2F;&#x2F;boostsecurityio.github.io&#x2F;dazio&#x2F;docs&#x2F;install&#x2F;</a>

One fundamental problem with agentic development is that accessing the secure enclave key requires human presence. If you&#x27;re running headless and aren&#x27;t logged in, Secretive (not sure about others) will not be able to access the enclave, even when you only chose &quot;notify&quot; and not &quot;touchid&quot;.<p>This is why I&#x27;m skeptical that the approach can scale reliably, even though I&#x27;m relying on it today. (Yes, PATs would fix this, but the enclave model is what I&#x27;m trying to retain for now.) What I&#x27;ve done instead is wrote a small daemon that sets the SSH authentication socket and does agent forwarding. This works when I&#x27;m traveling with laptop...but not yet from my mobile phone.<p>Example:<p><pre><code> Laptop Remote Mac ┌─────────────────────┐ ┌──────────────────────────┐ │ Secretive │ │ ssh &#x2F; git commit -S │ │ (Secure Enclave) │ │ │ │ │ ▲ │ ForwardAgent │ ▼ │ │ └── ssh ─────┼─────────────────►│ ~&#x2F;.ssh&#x2F;agent.sock │ │ │ │ (stable proxy) │ └─────────────────────┘ │ │ │ │ │ ▼ ▼ │ │ forwarded local │ │ laptop Secretive │ │ agent (if you sit │ │ at this Mac)│ └──────────────────────────┘ </code></pre> NB: I&#x27;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&#x27;m holding on too hard on secure enclave for what my use cases are. Feedback appreciated!

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&#x27;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.<p>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&#x27;ve been very happy with this solution. See <a href="https:&#x2F;&#x2F;github.com&#x2F;drduh&#x2F;YubiKey-Guide" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;drduh&#x2F;YubiKey-Guide</a> for a description of how to make your RSA keys stored on YubiKeys work with GPG and SSH at the same time.

I use 1Password&#x27;s `op` for this, but with an allowance: my dev environment keys.<p>I found I was getting fingerprint fatigue. Do I need a fingerprint request <i>every</i> time my dev server wants to connect to dev Supabase? No. That&#x27;s expected, and zero risk. There&#x27;s no data there.<p>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.<p>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.<p>It also has access to a vault with &#x27;AI-safe&#x27; keys that I want Claude to be able to access without asking me.<p>Now, these requests work invisibly. And when I see a fingerprint popup, it&#x27;s unusual, and I don&#x27;t auto-approve by habit.<p>I also keep an item called &#x27;_One-day keys&#x27; in a separate vault. (The underscore just pushing it to the top of the list for easy access.)<p>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&#x27;s finished what it was doing.<p>[0]: <a href="https:&#x2F;&#x2F;www.1password.dev&#x2F;service-accounts&#x2F;get-started" rel="nofollow">https:&#x2F;&#x2F;www.1password.dev&#x2F;service-accounts&#x2F;get-started</a>

The article starts on an incorrect premise.<p>The author says he doesn’t like the idea of having keys sitting on his file system ready to be snatched by bad actors.<p>That’s why they should be passphrase protected.<p>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.<p>I use Yubikey&#x2F;FIDO2 myself, but not because private keys cannot be protected on a file system.

You should checkout the TKey (<a href="https:&#x2F;&#x2F;www.tillitis.se&#x2F;products&#x2F;tkey&#x2F;" rel="nofollow">https:&#x2F;&#x2F;www.tillitis.se&#x2F;products&#x2F;tkey&#x2F;</a>)<p>It&#x27;s effectively an open source version of a YubiKey, the hardware itself is all open source and it handles ed255519 SSH keys really well.<p>inb4 they&#x27;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...

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.<p>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&#x27;m mainly doing development inside VM&#x27;s. Previously I was embedding Github key to each VM, but since I setup Secure Enclave (with Secretive), I&#x27;m only forwarding it&#x27;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

The `sc_auth` <i>trick</i> was posted about a year ago, since macOS 26 Tahoe added the SSH related functions into the keychain.dylib.<p>&gt; <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=46025721">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=46025721</a><p>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...)<p>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...)<p>I found the hacker way simplest and easiest; put a basic Makefile with bunch of rules, have a &quot;central&quot; host&#x2F;machine to distribute the keys and configuration from that point on...

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<p>On iOS&#x2F;ipad&#x2F;(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.

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.

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

Windows can do this too, btw: ssh-keygen -t ed25519-sk<p>It uses either the TPM with Windows Hello, or an external security key.<p>It might require downloading a newer Microsoft openssh release to generate the keys, but the current Windows 11 ssh can use those keys.

From a user perspective, I&#x27;ve been happy with Secretive[0] for quite some time across several machines (mentioned in TFA).<p>[0]<a href="https:&#x2F;&#x2F;secretive.dev" rel="nofollow">https:&#x2F;&#x2F;secretive.dev</a>

I’ve used the 1Password SSH agent at work and had to disable it because of prompt fatigue.<p>Claude and Cursor love to do `git ls-remote` at random times, which makes 1Password show a prompt asking me for permission, even though they initiated it from a non-interactive shell.<p>So now they just fail silently at the password prompt over and over again.

What&#x27;s the general consensus around ssh-agent?<p>It&#x27;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.<p>Certain automation and dev tools like Ansible make it a pain to work if agent key requires a confirmation.

Author here. Thanks to js2 for posting this, and to everyone for the comments. I&#x27;ve learned a lot from this thread.<p>To answer the question a few people asked: I ended up using Secretive. The native approach works, but I couldn&#x27;t live with the Touch ID prompt it shows. Secretive keeps the keys in the Secure Enclave too, with a much better prompt and per-key settings. I&#x27;m writing a part 2 about it, including forwarding the agent into a dev container so the key never enters the container.

Never missing an opportunity for self-promotion, if you use a lot of machines and have issues with agent forwarding and Git (i.e. because you&#x27;re using a remote coding agent), I wrote <a href="https:&#x2F;&#x2F;github.com&#x2F;anaisbetts&#x2F;ts-ssh-agent" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;anaisbetts&#x2F;ts-ssh-agent</a> - your keys are stored on a remote Tailscale node, and agent signing requests are verified via your Tailscale identity and gated by Tailscale access rules.<p>This means the machines you want have access to SSH (i.e. GitHub push&#x2F;pull), but none of them have an actual SSH key - if a machine is compromised you drop it from Tailscale. More of a security&#x2F;usability compromise than what OP is looking for, but solved a lot of frustrating paper cuts for me - I use it every day and I never think about SSH agents any more, it all just works

I wish I could import an existing key. Also when sharing the pub key, as far as I understand, shares the hardware dependence, e.g. on GitHub.

Why would you trust the NIST P-256 curve?<p>It is not one of the cryptographically safe curves, likely intentionally so.<p><a href="https:&#x2F;&#x2F;safecurves.cr.yp.to&#x2F;" rel="nofollow">https:&#x2F;&#x2F;safecurves.cr.yp.to&#x2F;</a>

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.

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.

Any reason to not store in a kdbx file this way your keys are platform independent.

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

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

If someone like the native approach or is familiar with SeKey, I created sekey-sh to simplify the process: <a href="https:&#x2F;&#x2F;github.com&#x2F;cavoirom&#x2F;sekey-sh" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;cavoirom&#x2F;sekey-sh</a><p>Work on macOS 26 and later.

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

&gt; That ssh: at the end is the FIDO2 application ID — it’s part of the key, not a comment.<p>I think this is incorrect and the &quot;ssh:&quot; at the end is indeed a comment.

Isn&#x27;t a GitHub app project Secretive doing that but better?

I&#x27;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&#x27;t back up a key that started life in a secure enclave, so you&#x27;ll need alternative access arrangements for anything you setup that way.

it’s a worthy experiment but I wouldn’t want hobbyists making life miserable for the rest of us.<p>There’s no reason the private key needs to be stored in Secure Enclave. Your passkeys are in the MacOS Keychain, encrypted using the Secure Enclave. They are decrypted when iCloud transfers them to a new machine.<p>A similar protocol could be used with ssh keys. Keep the keys on disk as usual, making them easy to back up. Encrypt them using the enclave. You can use the Secure Enclave to decrypt the key for backing up (with a backup-specific secret).<p>This way all of the protocols and tooling remains the same, except for obtaining the SSH key encryption secret from Secure Enclave. Backup, ssh login, ssh agent all use the same keys.<p>Do what Apple does. Making the process more difficult actually makes security worse.

The details of using the SE are interesting. I still don&#x27;t understand the threat analysis here. Basically here&#x27;s the lede:<p>&gt; Any malicious script that gets access to my filesystem could just copy them and get into all my servers.<p>So this is postulating a &quot;malicious script&quot; that has access to your filesystem but not the running system. Because if it&#x27;s running on the actual system it doesn&#x27;t need the key, it can just execute your remote stuff on its own. Or it can get the key by MitMing you by making your next &quot;ssh&quot; invocation steal your passphrase, or just read the unencrypted key out of the ssh process, or even just reimplement ssh to do the SE negotiation on its own. Or...<p>Like, there&#x27;s near zero added security here. The only scenario I can think of that would have any meaning is someone getting access to an offline image of your filesystem, an attack already prevented by drive encryption (and, perhaps, already defeated by insecure backups!).<p>You see occasional attempts to use TPMs for similar purposes, and they&#x27;re similarly silly. People need to understand that the TPM&#x2F;SE exists <i>for the benefit of third party authentication</i>. It&#x27;s not for you, the operator. It&#x27;s there so that your bank&#x2F;employer&#x2F;intelligence-agency&#x2F;whatever can know that the human being doing authentication is using the same device they&#x27;ve been known to use before.

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.<p>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.<p>Pretty stoked about it so far.

SSH keys at ~&#x2F;.ssh it&#x27;s a disaster. These should have been handled by something like factotum in 9front, but for Unix&#x2F;POSIX.

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.

.

..