Protecting SSH Keys with macOS Secure Enclave

Re:Protecting SSH Keys with macOS Secure Enclave by mavam on Wednesday November 11, 2026 @03:25AM (#50450945)

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!

[ Parent | on HN ]

Re:Protecting SSH Keys with macOS Secure Enclave by bartekpacia on Wednesday November 11, 2026 @04:24AM (#50451277)

I got a similar idea recently. I was getting annoyed by the coding agent, running on my laptop, being unable to use sudo (with my supervision) when ssh-ing to my remote server. I wanted to build this as a PAM module. I started building this but then I found it already exists, and I use it happily: https://github.com/z4yx/pam_rssh

[ Parent | on HN ]

Re:Protecting SSH Keys with macOS Secure Enclave by jon-wood on Wednesday November 11, 2026 @05:29AM (#50451786)

Two thoughts on this:

1. The Secure Enclave being inaccessible when you're not present is a feature, not a bug. If you need to run headless then its not the correct solution to your problem and you'll have to find another.

2. You don't need an SSH agent proxy, you can use a `match` block in your `ssh_config` with something like `host * exec "test -z $SSH_TTY` to check whether you're operating over an SSH connection and select Secretive's SSH agent if you're using the machine locally.

[ Parent | on HN ]

Re:Protecting SSH Keys with macOS Secure Enclave by briHass on Wednesday November 11, 2026 @12:09PM (#50455782)

Not sure how it works on macos, but on Windows the downside of agents using TPM backed Windows Hello keys (sk) is that the session can't be reused for scp/sftp and agents like to do one-action scripts, so you're doing the user presence pin/finger multiple times for each ssh command it executes.

I've started building a timeout-based ssh-agent population utility, but if I'm honest, TPM keys without user presence is probably sufficient.

[ Parent | on HN ]

Re:Protecting SSH Keys with macOS Secure Enclave by jon-wood on Thursday November 12, 2026 @05:50AM (#50465473)

Set the following in your SSH config, which will cause SSH to establish a single control channel when it first opens a connection to a host and maintain it until there's been 10 minutes of inactivity. That way the first connection requires auth for your SSH agent but it can then be reused for things like SFTP channels or opening another terminal.

  Host \*
    controlMaster auto
    controlPath ~/.ssh/master-%r@%n:%p
    controlPersist 10m

[ Parent | on HN ]

Re:Protecting SSH Keys with macOS Secure Enclave by jwr on Wednesday November 11, 2026 @08:00AM (#50452889)

> requires human presence

I'm not using the secure enclave, but I've been using YubiKeys for many years, and now that AI has arrived, I consider the above to be a good thing.

This means, for example, that unless I am physically present with my key inserted, activated, and touched on every operation, an AI agent cannot access any of my production servers. As I do not want AI agents to access my production servers, this is a very good protection technique. I am assuming that no matter how well you try to sandbox and restrict your AI agents running on your local machine, they might eventually be able to access any file in the file system.

[ Parent | on HN ]

Re:Protecting SSH Keys with macOS Secure Enclave by high_5 on Wednesday November 11, 2026 @11:13AM (#50455089)

Well, don't use secure enclave then, just file based private keys.

[ Parent | on HN ]

Re:Protecting SSH Keys with macOS Secure Enclave by chrononaut on Wednesday November 11, 2026 @12:52PM (#50456262)

As an aside, that's probably one of the best formatted text diagrams I've seen. Did you use a specific tool for that, or via an LLM from a prompt?

[ Parent | on HN ]