三类痛点：为什么「能登录」不等于「能审计」
痛点 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 的套餐与节点选型，把目录隔离与稳定入口交给专业托管。