Linux开发服务器SSH安全加固记录：从两次异常登录到子账号+sudo黑名单

团队最近在维护的 Ubuntu 24.04 KVM/OpenStack 开发服务器上，接连出现了两次针对 root 账号的异常 SSH 登录尝试。虽然最终都被拦截，但也让我意识到，团队共用一个 root 账号登录服务器的模式该改一改了。这里简单记录一下这次安全加固的思路和做法。

问题在哪

团队开发用的这台服务器，此前所有人都是用 root 账号 SSH 登录，权限没有区分，操作也没有留痕。一旦密钥或密码泄露，攻击者拿到的就是最高权限，风险敞口很大。两次异常登录事件算是给敲了个警钟。

白名单还是黑名单

最初的思路是给每个团队成员建普通账号，再用 sudo 白名单严格限制能执行的命令——只放行开发、部署相关的固定命令。但实际用下来发现白名单维护成本很高：团队日常工作里命令种类繁多，稍微遇到没预料到的操作就要临时改配置，来回申请、修改，效率很低，大家也会抱怨。

后来改成了黑名单模式：默认放行大部分命令，只针对高危操作（比如 rm -rf /、修改关键系统文件、操作磁盘分区、关停核心服务等）做拦截。这样既保留了日常开发的灵活性，也把真正可能造成破坏的操作挡住了，团队反馈也更顺畅。

最终方案

• 为每位团队成员创建独立的子账号，SSH 登录使用各自的密钥，操作可追溯到人；
• 子账号通过 sudo 黑名单机制获得受限的管理权限，日常开发部署不受影响；
• root 账号的 SSH 登录仍然保留，但仅限我个人使用，作为兜底和应急通道；
• 后续计划再补充登录异常告警，进一步收紧暴露面。

这次调整整体思路是"够用就好"：完全照搬企业级的严格白名单方案，对一个小团队的开发服务器来说维护成本偏高，反而容易被绕过或干脆被放弃执行。黑名单 + 子账号的组合，在安全性和易用性之间找到了一个比较实际的平衡点。之后如果这套机制在使用中暴露新的问题，再继续记录更新。