背景：SSH 密钥的安全隐患与防护需求
仅依赖文件权限保护 SSH 密钥存在显著风险。一旦恶意脚本获得文件系统访问权限，即可复制密钥并入侵所有关联服务器。网络中常见的“假面试任务”攻击（要求克隆仓库并在本地运行）便是典型案例。尽管 Devcontainer 提供了一定程度的隔离，但对于高安全需求的场景而言仍显不足。
方案对比与选择
经过调研，目前保护 SSH 密钥主要有以下几种途径：
- 原生 macOS Secure Enclave：无需第三方应用，操作系统内置支持。
- 第三方安全 enclave 应用：如 Secretive 等。
- 硬件安全密钥：支持 FIDO2 协议的 YubiKey。
- 密码管理器集成：1Password 或 Bitwarden 通过加密库存储密钥并使用其 SSH 代理。
虽然 1Password 已被广泛使用，且 Bitwarden 近期在免费层也增加了 SSH 密钥支持，但这类软件解决方案在密钥使用时仍需将其解密至内存中。对于追求极致安全的用户而言，硬件级别的支持更为关键——即使设备完全被泄露，私钥也无法被提取。因此，在不携带额外硬件且不维护第三方应用的前提下，macOS 的 Secure Enclave 成为首选方案。
技术原理：Secure Enclave SSH
自 macOS Sequoia（及 Tahoe）版本起，macOS 正式支持由 Secure Enclave 托管的 SSH 密钥。Secure Enclave 是 Mac 芯片上独立于主处理器的安全子系统，私钥在此生成后永不离开该区域。
当进行 SSH 连接时，Mac 会请求 Secure Enclave 对验证挑战进行签名。若启用生物识别功能，每次签名操作均需用户批准（如 Touch ID）。整个过程中，私钥从未存在于内存或磁盘上。
| 特性 | 传统 SSH 密钥 | Secure Enclave 密钥 |
|---|---|---|
| 私钥存储位置 | ~/.ssh/id_ed25519（普通文件） |
Secure Enclave 内部 |
| 磁盘上的内容 | 实际的私钥数据 | 仅为引用标识（脱离该 Mac 即失效） |
| 远程服务器配置 | 将公钥复制到 authorized_keys |
同上 |
| 连接体验 | 直接连接 | 触发 Touch ID 提示，确认后连接 |
实施步骤
步骤 1：创建安全密钥
macOS 提供了 sc_auth 命令用于管理 CryptoTokenKit 身份，该命令同样适用于 Secure Enclave。执行以下命令创建密钥：
sc_auth create-ctk-identity -l "ssh-MacBook" -k p-256-ne -t bio
参数说明：
-l "ssh-MacBook"：设置本地可见的标签名称。-k p-256-ne：指定 NIST P-256 曲线，其中n代表非导出性（Non-exportable），确保密钥无法离开 Secure Enclave。-t bio：强制每次使用需通过生物识别（Touch ID）授权。
执行后系统将提示使用 Touch ID 完成密钥创建。
常见问题排查：Touch ID 错误
若遇到如下错误：
Error: Error Domain=NSOSStatusErrorDomain Code=-25293 "Failed to generate keypair"
(errKCAuthFailed / errSecAuthFailed: / Authorization/Authentication failed.)
UserInfo={..., NSUnderlyingError=... "Failed to get bio catacomb UUID for user 502." ...}
这通常意味着 Touch ID 注册信息已重置。解决方法是前往「系统设置」→「Touch ID 与密码」重新录入指纹，随后再次运行命令即可成功。可通过以下命令验证密钥是否创建成功：
sc_auth list-ctk-identities
输出示例：
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
步骤 2：导出密钥句柄
需要创建一个供 SSH 使用的“密钥句柄”文件。该文件并非私钥本身，而是一个指向 Secure Enclave 的引用。
ssh-keygen -w /usr/lib/ssh-keychain.dylib -K -N ""
当提示输入 PIN 码时，直接按回车键（生物识别密钥不使用 PIN）。此时会在当前目录生成 id_ecdsa_sk_rk 和 id_ecdsa_sk_rk.pub 文件。将其移动至 SSH 目录：
mv id_ecdsa_sk_rk* ~/.ssh/
步骤 3：配置 SSH 使用 Secure Enclave 提供者
在 ~/.zshrc 或 ~/.bashrc 中添加环境变量：
export SSH_SK_PROVIDER=/usr/lib/ssh-keychain.dylib
重新加载配置文件：
source ~/.zshrc
注意事项：过时命令警告
网上许多旧指南建议使用 ssh-add -K，但该标志已弃用并被替换为 --apple-use-keychain 和 --apple-load-keychain。然而，这些新标志仅适用于传统的 macOS Keychain，不适用于基于 CryptoTokenKit 的 Secure Enclave 密钥。正确的方法是通过上述环境变量 SSH_SK_PROVIDER 进行配置。
步骤 4：获取公钥
cat ~/.ssh/id_ecdsa_sk_rk.pub
输出示例：
sk-ecdsa-sha2-nistp256@openssh.com AAAAInNrLWVjZHNhLXNoYTIt... ssh:
末尾的 ssh: 是 FIDO2 应用 ID，属于密钥的一部分而非注释。在复制到服务器时，可在其后添加自定义注释：
sk-ecdsa-sha2-nistp256@openssh.com AAAAInNrLWVjZHNhLXNoYTIt... ssh: macbook-secure-enclave
步骤 5：部署到服务器
使用以下命令将公钥复制到目标服务器：
ssh-copy-id -i ~/.ssh/id_ecdsa_sk_rk.pub user@your-server
或手动将公钥粘贴至服务器的 ~/.ssh/authorized_keys 文件中。
步骤 6：配置 SSH Config
SSH 默认不会自动发现 id_ecdsa_sk_rk 等非标准命名的密钥文件。需在 ~/.ssh/config 中显式指定：
Host *
IdentityFile ~/.ssh/id_ecdsa_sk_rk
IdentityFile ~/.ssh/id_rsa
IdentityFile ~/.ssh/id_ed25519
SSH 会按顺序尝试 IdentityFile，建议将 Secure Enclave 密钥置于首位以设为默认选项。
注意：若正在使用 1Password 的 SSH Agent（通过 IdentityAgent 配置），可能会与此设置冲突，测试期间可能需要暂时注释掉相关配置。
步骤 7：测试连接
ssh user@your-server
连接时应弹出 Touch ID 验证窗口，通过后即可建立连接。
用户体验与局限性
UI 提示不够友好
目前的 Touch ID 弹窗显示内容为 “ctccardtoken needs to authenticate to continue”，而非更直观的“SSH 请求使用您的密钥”。这是因为提示源自底层框架 CryptoTokenKit，Apple 尚未针对终端用户 SSH 场景进行界面优化。若对此介意，可考虑使用同样基于 Secure Enclave 但提供更美观 UI 的第三方应用如 Secretive。
为何推荐全程启用 Touch ID
曾有人考虑为重要服务器启用 Touch ID，而为 Git 等操作创建无生物识别要求的便捷密钥。然而，若不启用 -t bio，恶意软件可能在后台静默使用密钥。启用生物识别虽增加了几次点击成本，但能确保用户知晓每一次密钥调用行为，这种透明度值得保留。建议统一使用 -t bio，如有不便后续再单独创建备用密钥。
缺乏备份机制
Secure Enclave 密钥与特定 Mac 硬件绑定。若设备损坏或丢失，密钥随之失效且无法导出备份。这是硬件级安全设计的必然结果。应对策略是为服务器配置多个密钥：除了 Secure Enclave 密钥外，还应添加一个来自其他设备（如另一台 Mac 或 YubiKey）的备用密钥至 authorized_keys，以防单一设备故障导致访问中断。
总结
利用 macOS Secure Enclave 存储 SSH 密钥是一种比硬盘明文存储更安全的方式。其主要优势包括：
- ✅ 私钥物理不可窃取（存储在硬件中）。
- ✅ 每次 SSH 操作需 Touch ID 确认，防止未授权使用。
- ✅ 无需安装第三方应用程序。
- ✅ 兼容现有的
authorized_keys工作流。
尽管 Apple 在安全性演示中常强调其防护能力，但当前原生 SSH 集成的 UI 细节仍有待打磨。对于追求极致简洁与安全平衡的用户，此方案具备较高实用价值，但仍需规划好多设备冗余备份策略。
