通过 macOS Secure Enclave 保护 SSH 密钥

标准的 SSH 密钥通常存放在 `~/.ssh/` 目录中，它们仅受文件权限保护，极易受到任何获得文件系统访问权限的恶意脚本的攻击。通过利用 macOS Secure Enclave，用户可以确保私钥永远不会以文件形式存在于内存或磁盘中，而是驻留在专门的安全芯片内，由该芯片内部执行签名操作。

这张图片展示了使用硬件支持密钥的每次 SSH 身份验证所需的强制性 Touch ID 生物识别提示。

硬件支持的密钥隔离

Secure Enclave 是 Mac 芯片上的一个安全子系统，与主处理器隔离。当 SSH 密钥由此硬件支持时，私钥在 enclave 内部生成且永远不会离开。当发起连接时，Mac 会要求 enclave 对身份验证挑战进行签名，而实际密钥对操作系统保持不可访问。

HN Digest 根据 github.com 报告的数据绘制的图表；数值按原文显示。

这种方法解决了重大的安全漏洞：软件类解决方案（如加密保险箱）在运行时仍会将密钥解密到内存中。相比之下，Secure Enclave 确保即使操作系统被完全攻破，也无法“窃取”私钥，因为密钥材料从未暴露给主 CPU。

技术实现与配置

设置原生方法涉及使用 `sc_auth` 命令来创建 CryptoTokenKit 身份。用户必须指定 NIST P-256 曲线和 `bio` 标志以要求生物识别身份验证。此过程会生成一个“密钥句柄”——这是一个引用文件，告诉 SSH 客户端请求 enclave 提供签名，而不是读取原始私钥文件。

为了使系统正常运行，用户必须将 `SSH_SK_PROVIDER` 环境变量设置为指向 `ssh-keychain.dylib` 库。由于 SSH 不会自动发现这些特定的密钥句柄，因此必须在 `~/.ssh/config` 文件中明确定义它们，以确保系统优先使用 Secure Enclave 密钥而非标准的 RSA 或 Ed25519 密钥。

权衡与用户体验

这种高水平安全的主要权衡是缺乏可移植性。Secure Enclave 密钥与特定的 Mac 硬件绑定；如果设备损坏，密钥将丢失。用户必须维护一个备用密钥（例如存储在 YubiKey 或另一台机器上），以确保不会被锁在自己的服务器之外。

原生的 macOS 体验明显不够完善，它显示的是低级别的 'ctccardtoken' 提示，而不是标准的 SSH 界面。对于寻求更精致体验的用户，Secretive 等第三方应用程序提供了精美的 UI 和系统通知，同时仍利用相同的底层 Secure Enclave 硬件。

此截图展示了原生 macOS 实现用于密钥身份验证的未经润色的低级别界面。

Secretive 是一个第三方应用程序，与原生实现相比，它提供了更精美的 UI 和系统通知。