很多新手刚接触Linux服务器时，都会被两个命令搞混：su和sudo。它们都能让你获得更高权限，但背后的安全逻辑完全不同。用错了，轻则操作不便，重则留下安全隐患。
先说结论：日常运维请优先用sudo，su只留作特定场景备用。这不是个人偏好，而是业界用二十年教训换来的共识。
su的本质是"完全变身"
su代表substitute user，功能是切换用户身份。执行su devuser后，你需要输入目标用户的密码，然后整个会话就变成那个用户了。
这里有个细节很多人忽略：su devuser和su - devuser是两回事。前者只切换身份，环境变量还是原来的；后者加了个横杠，会完整加载目标用户的环境配置、PATH变量和家目录。生产环境切用户，务必带横杠。
切换到root更是常见操作。su -或su root能让你获得系统最高权限，但代价是：从此你做的任何事都不会被记录是谁干的，误删系统文件也没人拦得住。
sudo的设计哲学是"精准授权"
sudo是Super User DO的缩写，但它能做的远不止以root身份跑命令。核心语法很简单：sudo command，比如sudo apt update。
关键区别在于：sudo不需要知道root密码，只需要你自己的密码。系统管理员通过/etc/sudoers文件（必须用sudo visudo编辑，防止语法错误锁死系统）来精确控制谁能做什么。
Ubuntu/Debian把用户加入sudo组，RHEL/CentOS则是wheel组，就能获得基础sudo权限。但更精细的做法是给特定命令开白名单，比如只允许某个用户重启nginx服务，而不是给他完整的root权力。
为什么sudo更安全？四个硬性优势
日志审计是sudo的杀手锏。每次sudo操作都会留下记录，谁在什么时间执行了什么命令，一目了然。su切换后的一切行为都挂在目标用户名下，出了问题难以追溯。
权限粒度方面，sudo可以限制到单条命令，su则是"全有或全无"。最小权限原则（Principle of Least Privilege）在合规场景下不是可选项，而是必选项。
密码管理上，sudo用用户自己的密码，root密码可以严格管控甚至分段保管。su则必须把目标用户密码交出去，离职交接、密码轮换都是麻烦事。
误操作缓冲也是个隐性收益。sudo每次都要敲密码（可配置免密时间），给了操作者一个"真的要执行吗"的思考窗口。su切换后长时间保持高权限，手滑的风险指数级上升。
实际工作流怎么搭配
DevOps场景的典型配置：创建专用账户sudo useradd -m devops，加入sudo和docker组，这样既能sudo docker ps管理容器，又不用直接碰root。
需要临时获得完整root环境时，sudo -i或sudo su可以开启root shell，但记得办完事立刻exit。更安全的做法是sudo -u nginx whoami这种精确到用户和命令的用法。
应用账户切换是su的合理场景。比如排查nginx问题时su - nginx，完整加载该用户环境，验证配置文件权限、测试启动脚本，这种一次性身份模拟用su更直接。
几个容易踩的坑
把su -当日常工具是最常见的坏习惯。一旦养成，权限边界就模糊了，多人共用root密码更是安全审计的红线。
sudoers文件编辑错误会导致所有sudo命令失效，把自己锁在系统外面。visudo的好处是会检查语法，报错时拒绝保存，这个保险不能省。
给用户开ALL权限等于变相给root，违背了用sudo的初衷。定期审计/var/log/auth.log里的sudo记录，清理不再需要的授权，是运维的基本功课。
权限管理没有银弹，但su和sudo的选择是有明确倾向的：能sudo不su，能具体命令不开放shell，能限时权限不永久授权。这套规则写进过无数安全规范，也救过无数凌晨被叫醒的运维工程师。
热门跟贴