su是身份切换，sudo是权限委托；企业规范强调最小权限、可审计、密码隔离和环境可控；日常运维首选sudo因其审计明确、无需root密码、权限自动回收、支持精细授权。

区分 su 和 sudo 的核心在于：一个是“换人”，一个是“借权”。su 是身份切换，直接变成另一个用户；sudo 是权限委托，以当前身份临时获得执行特定命令的权限。企业级规范围绕最小权限、可审计、密码隔离和环境可控这四点建立。

什么时候该用 su -，而不是 su 或 sudo

需要完整加载目标用户的登录环境时，必须用 su -（或 su -l）。

• 部署服务前初始化系统用户：比如创建 redis 用户并配置 /opt/redis 目录，依赖 /root/.bashrc 中定义的 PATH 或自定义函数，用普通 su 会因路径缺失导致 chown 或 systemctl 找不到命令
• 调试某个用户专属环境问题：例如 www-data 用户启动失败，需模拟其完整 shell 初始化流程，检查 ~/.profile 是否被正确读取
• 执行一连串强环境依赖操作：如编译安装软件、运行旧版脚本，这些脚本硬编码了 $HOME 或调用了 /usr/local/bin 下的工具，而该路径只在目标用户 PATH 中

为什么日常运维首选 sudo，而不是 su

sudo 不是“替代 su”，而是解决 su 在企业场景中的三个硬伤：密码共享、操作不可溯、权限收不回。

• 审计明确：每条 sudo command 都记入 /var/log/auth.log，含时间、发起用户、终端、命令全路径，满足等保和 SOC2 合规要求
• 无需 root 密码：员工只需自己密码即可提权，避免 root 密码在团队中流转、截图、粘贴泄露
• 权限自动回收：默认 15 分钟无操作后失效，不会像 su - 那样长期滞留在 root shell 中，误删 / 或覆盖关键配置的风险大幅降低
• 支持精细授权：可在 /etc/sudoers 中限定某用户只能重启 nginx、只能读取日志、只能执行备份脚本，不给 ALL

企业级权限切换安全规范要点

不是靠“记住哪个命令更好”，而是靠机制设计堵住漏洞。

• 禁用 root 远程登录：修改 /etc/ssh/sshd_config 中 PermitRootLogin no，强制所有管理走普通用户 + sudo
• 全员加入 sudo 组，而非 wheel：Ubuntu/Debian 默认用 sudo 组，执行 usermod -aG sudo username 即可，比手动配 sudoers 更可控
• 禁止裸 sudo 权限：不用 NOPASSWD: ALL，至少保留密码验证环节；对自动化任务，用 sudo -n + 限定命令白名单
• 限制 su 使用范围：启用 pam_wheel，仅允许 wheel 组成员执行 su -，再把极少数高级运维加入该组
• 禁用交互式 shell 授权：在 sudoers 中不开放 /bin/bash、/usr/bin/python3 等，防止通过 sudo python3 -c "import pty; pty.spawn('/bin/bash')" 绕过命令级限制

一个典型误用对比：查日志 vs 调整服务

同样是“要干 root 才能干的事”，选法完全不同。

• 错误做法：用 su - 登录 root，然后 tail -f /var/log/nginx/error.log → 查完忘记 exit，后续 rm -rf 或 git push 全在 root 下执行，污染归属、埋下误操作隐患
• 正确做法：用 sudo tail -f /var/log/nginx/error.log → 查完自然回到当前用户，环境干净，日志可查谁、何时、查了什么
• 错误做法：用 sudo systemctl restart nginx 后，顺手 cd /etc/nginx 再 vim nginx.conf → 后者仍是普通权限，编辑失败还可能触发奇怪的权限报错
• 正确做法：若需连续编辑+重载，应统一用 sudo -i 进入 root shell（明确上下文切换），或拆成两条带 sudo 的命令：sudo vim /etc/nginx/nginx.conf && sudo systemctl reload nginx