三类痛点：为什么「能登录」不等于「能稽核」
痛点 1：金鑰与人员、流水线生命周期脱钩。工程同学离职后，其笔记本上的私钥无法从服务端「一键收回」，除非逐条清理 authorized_keys；CI 侧若使用长寿命金鑰，流水线改名或仓库归档后旧金鑰仍有效，合规问卷里「该金鑰对应哪条发布路径」往往答不上来。多團隊场景下，远程 Mac作为构建与产物汇聚节点时，这一问题会被构建频率放大：同一目錄上既有交互式 SFTP，也有无人值守 rsync。
痛点 2：authorized_keys 行内注释无法结构化。行数过百时评审成本陡增，也难与 IAM 对齐序列号；没有统一签发台时只能周期性全量輪換，业务侧常拖延成技术债。
痛点 3：与仅 SFTP、Chroot、並發的耦合不清晰。即便已按 internal-sftp + ChrootDirectory 拆目錄，身份层仍可能同一 Unix 账号混跑多把金鑰，稽核只能到账号粒度。Principal 加每流水线独立账号才能问责到團隊。
静态公钥列表与 SSH 使用者憑證：信任锚应该放在哪里
传统模型把信任锚放在每一行公钥：服务端存储的是「允许这把钥匙开门」。使用者憑證模型把信任锚放在憑證颁发机构（CA）公钥：服务端只信任少数 CA，具体使用者钥匙由 CA 签名并在憑證里写明有效期、Principal、允许的来源等扩展字段。这样輪換从「改服务器上 N 行」变为「到期自动失效 + 重新签发」，更贴近 modern zero-trust 的「短期凭据」思路。需要强调的是：憑證并不替代目錄层权限——仍应配合 POSIX 权限、chroot、以及原子发布的 releases/current 结构，否则身份再细粒度也可能误写生产路径。
在 Apple 与通用 OpenSSH 环境，ed25519 为推荐算法；新流水线宜统一 ed25519，旧客户端可单独保留 RSA 分支。
决策矩阵：继续堆金鑰、引入 SSH CA，还是拆账号与拆入口
下表用于在组织规模、变更频率与合规要求之间做显式取舍；可与安全评审结论一并归档。
| 策略 | 适用场景 | 維運成本 | 稽核友好度 |
|---|---|---|---|
| 继续维护超长 authorized_keys | 极小團隊、变更极少、无合规压力 | 低（短期） | 差；难以对齐人员与流水线 |
| 仅拆 Unix 账号 + 静态金鑰 | 中等團隊；可接受多次登录入口 | 中；账号与金鑰数量同步膨胀 | 中；依赖外部台账 |
| 引入 SSH 使用者憑證 + Principal | 多團隊、多流水线、需定期輪換 | 中偏高；需建设签发与吊销流程 | 高；憑證序列号与时间窗可查询 |
| 拆入口（堡垒机 / 專用上传域名） | 强隔离、跨地域多入口 | 高 | 高；与 CA 可叠加 |
实操：从 CA 到 sshd 与使用者憑證（至少五步）
下列命令需在测试环境验证后再用于生产；将路径、Principal 与账号名替换为你的远程 Mac 或 Linux 节点。若与仅 SFTP 结合，请同步核对 chroot 目錄属主与权限红线，详见 Chroot 专文。
# 步骤 1：在离线或專用安全区生成 CA（示例：ed25519）
ssh-keygen -t ed25519 -f ./user_ca -C "[email protected]"
# 步骤 2：将 user_ca.pub 放到目标机 /etc/ssh/user_ca.pub，并在 sshd_config 追加：
# TrustedUserCAKeys /etc/ssh/user_ca.pub
# 可选：指定允许登录的使用者 Principal 白名单
# AuthorizedPrincipalsFile /etc/ssh/auth_principals/%u
# 步骤 3：为某維運使用者公钥签发 90 天憑證（示例 Principal）
ssh-keygen -s ./user_ca -I ci-ios-202603 -n ci-ios -V +90d -z 10001 id_ed25519.pub
# 步骤 4：客户端使用憑證私钥 id_ed25519 与憑證 id_ed25519-cert.pub 连接；
# ssh -i id_ed25519 -o CertificateFile=id_ed25519-cert.pub deploy@remote-mac
# 步骤 5：为仅 SFTP 账号单独 Match User 块，ForceCommand internal-sftp，
# ChrootDirectory 与並發、原子发布目錄模型对齐；记录签发批次到 JSONL。
# 步骤 6（可选）：与 CI 集成——在流水线中短期签发（如 +24h），序列号写入稽核。
若暂不上 CA，也应落实每流水线独立金鑰与账号及目錄前缀，并与並發与 keepalive写入规范。
可引用数据：有效期、序列号与稽核保留
基线建议：（1）交互式憑證 30–90 天，CI 短期 24–72 小时；到期前 7 天提醒。（2）签发记录含序列号 -z、Principal、起止时间与工单或流水线 ID。（3）稽核保留 ≥ 90 天。（4）吊销优先靠短期过期；紧急时停用 Unix 账号或从 Principal 白名单移除。（5）chroot 与多版本 releases 需监控磁盘与 inode。
自建需同时承担硬件、链路与身份、目錄两层維運；发布频次升高时，把准入与隔离目錄託管出去可让團隊聚焦构建与稳定性。
FAQ、内链收束与为何考虑租賃远程 Mac
主机憑證（Host Certificate）一定要上吗？
使用者憑證解决「谁可以登录」；主机憑證解决「这是不是那台服务器」，可显著降低首次连接时的 TOFU（Trust On First Use）风险。在跨地域多入口时值得做；单入口内网可分期上线。
憑證与 FIDO2 / PIV 硬件令牌冲突吗？
不冲突，属于不同层：硬件令牌保护的是客户端私钥材料；憑證是服务端对公钥的声明。可组合使用以满足更高等级合规。
上 CA 后还需要 per-key from= 限制吗？
视威胁模型而定：憑證可承载来源信息，但若网络侧仍需 IP 白名单，可在防火墙或安全组实现双因子约束。
自建可完全复现 SSH CA 与 SFTP 專用账号，但需持续维护签发台与目錄权限一致。希望把線上率、隔离与稽核字段打包交付的團隊，可将SFTPMAC 远程 Mac 与本文憑證模型、Chroot、原子发布叠加使用。
若你希望减少自管远程 Mac 上的准入复杂度和金鑰台账维护成本，同时继续沿用 SFTP/rsync 与原子发布模型，可以了解 SFTPMAC 的套餐与节点选型，把目錄隔离与稳定入口交给专业託管。