账号与权限的迁移梳理

服务器搬上云，账号和权限常常被原样照搬：一台机器一个 root 密码全员共用，离职同事的公钥还留在 authorized_keys 里。迁移恰好是清理这些历史包袱的机会，值得趁机器搬家做一次梳理。 一、为什么要最小化重建 旧环境里的账号大多按"当年出了问题就加一个"的方式长出来，没人说得清哪个密钥还在用。到了新平台，与其逐条复制，不如按角色重建：部署用一个账号，日志查看用一个，数据库管理单独一个，各自的权限边界写进文档。文档不用长，一张表列出账号、用途、权限范围三个字段，之后每次调整都更新这一张表。这样短期费事，换来的是以后排查问题时能确定"谁改过什么"，不用再猜。 二、迁移期正好轮换密钥 迁移意味着凭据要重新分发一遍，顺手轮换最省事。SSH 密钥方面，在新机器上重新生成密钥对，旧公钥不复制过去；老机器销毁前先清点一遍： ``` cat ~/.ssh/authorized_keys ``` 逐条确认归属，无人认领的直接删除。密码类凭据不沿用旧密码，用密码管理器生成新的随机串再分发给需要的人。数据库账号同理：应用连接用的账号只给目标库的增删改查权限，不给全局权限，管理账号另行创建。 三、交接后怎么验证 验收方式很直接：每个成员用新凭据登录一次，确认该做的能做、不该做的做不了。再翻一遍登录记录，`last -20` 加上 /var/log/secure，确认没有陌生来源用旧凭据连进来。验证别漏掉自动化环节：CI 或发布脚本里写死的旧凭据同步换掉，否则部署会在最不该失败的时候失败。旧机器退租前，最后检查一次 authorized_keys 和 crontab，别把同步任务或密钥留在上头。 账号梳理不是一次性工程，但迁移这一轮做扎实，之后加人减人都只是改文档和权限组，不用再翻遍服务器找密钥。