服务账号SSH密钥应单独隔离

服务器上的 authorized_keys 常常是个大杂烩：运维自己的登录密钥、CI/CD 流水线用的密钥、备份脚本用的密钥，全挤在同一个 root 账号下面。平时没人管，等到有人离职或者某把私钥不小心泄露，麻烦就来了——你根本分不清哪一把是哪一把，也不敢随便删，删错了流水线当天就停摆。

服务账号的 SSH 密钥，恰恰是最该单独隔离的那一类。

原因不难理解。个人密钥背后是一个活人，人走了，密钥跟着走，职责边界清楚。服务账号密钥背后是一段脚本、一个流水线、一个监控采集任务，它 7×24 小时在跑，没人会主动想起它，也不会有人定期更换。更糟的是，很多团队把同一把私钥复制到好几个地方使用，结果就是这把密钥谁都能用，出了事谁都不用负责。想单独撤销某个使用方的权限？做不到，只能全部推倒重来。

隔离的第一层，是账号隔离。服务账号就该有独立的系统用户，而不是图省事直接塞进 root。这么做的直接好处是权限可以被约束：它能碰哪个目录、能执行哪些命令，都是可以划定的范围。第二层是配置隔离，OpenSSH 本身支持在 authorized_keys 里对单把公钥加限制，比如用 command= 限定它只能跑某个脚本，用 from= 限定它只能从内网地址登录。这些限制写在密钥条目上就生效，不用动服务器的全局配置，改动成本低，效果却实在。

还有一个容易被忽略的点：隔离之后，轮换才真正可操作。如果流水线、备份、监控共用一把密钥，换密钥就意味着要同时协调所有使用方，风险高、周期长。而一旦每类任务各用各的密钥，你就可以分批推进——先在服务器上追加新公钥，逐个更新使用方配置，每更新一个就验证对应任务是否正常，全部确认后再移除旧的。这个节奏慢是慢了点，但出问题时能退得回来。

反过来看，没做隔离的团队在应急时会特别被动。发现某把私钥泄露了，第一反应是从所有服务器上移除对应公钥，可移除完之后才发现，好几个自动化任务跟着一起挂了，只能手忙脚乱地重新配。而如果一开始就把服务账号密钥单独拎出来，止血的范围就是可控的，其他部分不受牵连。

所以这件事没有多复杂：给服务账号一个独立的系统用户，给它单独一把密钥，把权限压到刚好够用，再记清楚这把密钥用在哪些地方。花不了多少时间，但能省掉后面很多说不清的麻烦。