痛点拆解：抗钓鱼的代价不是「多插一把钥匙」这么简单
痛点 1：把 FIDO2-SK 当成「更强 ed25519」。安全密钥绑定的是 WebAuthn/FIDO2 语义与固件策略；一旦启用用户在场或 PIN，失败模式从「密钥错」变成「人不在」「PIN 锁计数」「USB 口供电抖动」，排障日志更难对齐到单一组件。
痛点 2：CI 与工程师共用 authorized_keys。GitHub Actions 托管 Runner 无法稳定挂载你的硬件；若仍把同一 principal 混写，夜间任务会在人类睡眠窗口集中失败，误配重试还会触发 sshd 限次与封禁策略 的二次伤害。
痛点 3：忽略主机侧身份。FIDO2 只强化客户端，不解决「连的是否目标远程 Mac」；须 known_hosts 固定指纹。
痛点 4：传输与会话层混谈。大文件与多 Job 并行时，并发 SFTP 与 TCP keepalive 若不评审，会把「认证变慢」误判成「密钥坏了」。
痛点 5：短期证书与 OIDC 被当成互斥。常见组合是 CA 管到机登录、OIDC 管仓库到流水线；矩阵用于写清边界。
威胁模型与指标基线：把「安全」拆成可观测事件
至少记录四类事件：认证成功/失败原因码、主机密钥校验结果、并发会话峰值、部署凭据发放失败率；人类路径看 PIN/触控耗时，自动化路径看证书 TTL 余量与 OIDC audience 拒绝率，并与 OIDC 部署矩阵 的 claims 变更审计联动。
可量化基线：用数字结束「感觉更安全」
人类交互式 ssh 启用触控常见附加耗时约 2–8 秒；CI 证书建议在剩余 TTL 低于 20% 时刷新；OIDC 发放失败若高于约每千次构建 3 次，应优先查 audience 与出口 IP；MaxAuthTries 与 Runner NAT 组合时把误配重试与真实暴力分层统计（见 限次文）。并发上传接近单会话 200 Mbps 时应为传输任务单独限速，避免挤占交互式运维窗口。
决策矩阵：FIDO2-SK、SSH CA 短期证书与 OIDC 发放如何分工
| 路径 | 最适合的调用方 | 主要收益 | 主要代价与风险 |
|---|---|---|---|
FIDO2 *-sk | 工程师工作站 | 抗钓鱼强 | 触控/PIN 与 CI 冲突 |
| SSH CA | 平台统一登录 | 短 TTL、可吊销 | CA 运维成本高 |
| OIDC | 托管 Runner | 无硬件、可审计 | 依赖 IdP 与 audience |
| 混合 | 中大型团队 | 体验与安全折中 | 须清晰 principal 与账号隔离 |
实操步骤：从密钥类型选择到 sshd 与会话治理
# 1) 人类路径：生成 ed25519-sk（示例，按企业策略替换验证选项）
# ssh-keygen -t ed25519-sk -O resident -O verify-required -f ~/.ssh/id_ed25519_sk_remote_mac
# 2) 审计当前 sshd 是否混用密码与公钥（生产建议关闭密码）
# sshd -T | egrep 'passwordauthentication|pubkeyauthentication|authenticationmethods'
# 3) CI 路径：优先使用 OIDC + 部署私钥或短期证书，而非共享静态 PEM
# （具体 claims 与 audience 见仓库内 OIDC 指南文）
# 4) 主机身份：在 Runner 侧使用固定 known_hosts，而非每次 keyscan
# 参见 GitHub Actions known_hosts 决策矩阵文
# 5) 并发 SFTP：为传输任务设置会话上限与 keepalive，避免半开堆积
上述命令只作锚点；生产须把 StrictHostKeyChecking 与 并发 SFTP 写入 YAML 与 Runbook。
步骤 1：列出全部调用方并打标签（人类/自动化/第三方），禁止「临时共用」不写文档。
步骤 2：为人类选择 FIDO2-SK 时，明确是否强制 verify-required，并准备备用访问通道（如 break-glass 证书 principal）。
步骤 3：为自动化选择 CA 或 OIDC 时，把 TTL、刷新点、吊销接口与构建缓存清理写进同一变更单。
步骤 4：在 sshd 层分离 Match User 或 Match Group，让 CI 账号不走交互式 FIDO2 插件路径。
步骤 5：把 known_hosts、并发、限次与日志保留写入检查表并按季度复盘。
步骤 6：升级 OpenSSH 或固件后做小样本回归并归档日志。
强相关 CTA：把身份、主机与会话放在同一阅读顺序
FAQ 与为什么考虑 SFTPMAC 托管远程 Mac
FIDO2 能否完全替代 SSH CA？
不能简单替代：CA 解决的是「短期身份与可撤销性」与大规模机器池的运维效率；FIDO2 解决的是「人类凭证抗导出」。组织需要两条故事线并存，并在 authorized 文件中物理隔离。
OIDC 发放会不会让「仓库即根权限」？
风险真实存在，应通过最小权限、环境隔离、以及把远程 Mac 账号拆成上传/编译/发布多 principal 来收敛爆炸半径；详见 OIDC 安全矩阵。
触控失败率高时先查什么？
先查 USB 供电与扩展坞，再看 sshd 是否因重试触发限次，以及人机是否共用账号。
总结：引入 FIDO2-SK 是把「人类在场」写进认证最短路径，抗钓鱼强但不解决 CI 无头、主机身份与会话并发；应把 FIDO2 留给工程师、CA/OIDC 留给自动化，并以 known_hosts 与限次兜住公网现实。
局限：自建池要在固件、USB、sshd、流水线三方对齐版本与策略，间歇性触控失败常跨夜排障。
对比与收束：SFTPMAC 托管远程 Mac 将 Apple 生态兼容、稳定在线与传输治理产品化，团队可专注编译与发布，减少「CI 等人摸密钥」的迭代损耗；认证与传输一并托管时，租赁远程 Mac 往往比自管节点更易获得稳定交付体验。
把人类 FIDO2 路径与自动化 CA/OIDC 路径拆 principal，托管环境更容易做到配额、审计与回归样本统一。