su 配置 的核心答案：su 命令配置主要解决权限切换问题，正确配置 sudoers 文件、环境变量和免密登录，才能让 Linux 服务器在多用户场景下既安全又高效。
su 配置 之前，先搞懂它和 sudo 的区别
很多人搜“su 配置”时，其实分不清 su 和 sudo，这两兄弟虽然都是切换用户权限，但机制完全不同。su 是切换用户身份，输入目标用户的密码后，你会直接变成那个用户；sudo 是以其他用户身份执行单条命令，只需要输入自己当前用户的密码（或配置免密），行业共识认为，日常运维中 sudo 比 su 更安全，因为 sudo 可以精确控制谁能在哪台机器上执行哪些命令，而 su 一旦切过去就是完全接管。
具体到实际操作，比如你在简米云 ECS 服务器上收到“permission denied”报错，想临时切换成 root 用户执行一条安装命令，这时候 su root 就够了，但如果你需要配置一个自动化脚本来定期执行备份任务，长期用 su 切 root 显然不合适每次都要输密码，密码还会被留在 shell 历史里，这种情况就得靠 su 配置 里的免密 sudo 方案来解决。
su 配置 的核心：sudoers 文件的正确写法
既然要聊配置，就得先找到配置文件。sudoers 文件的路径是 /etc/sudoers，普通用户默认没有写权限，你需要先通过 su - 切到 root，然后使用 visudo 命令打开编辑器，这个命令会做语法检查，防止你改坏了导致整个 sudo 系统崩溃。
我来写一段最基础的配置流程：
- 执行
su -切换 root 用户 - 运行
visudo进入编辑界面 - 找到
root ALL=(ALL:ALL) ALL这一行 - 在下面仿照格式添加新用户规则
比如你想给一个叫 deploy 的用户配置完全的管理员权限，就在 visudo 里加一行：
deploy ALL=(ALL:ALL) ALL这里逐段拆解含义：第一个 deploy 是用户名，ALL= 表示允许从任何终端登录，(ALL:ALL) 表示可以以任意用户和用户组的身份执行命令，最后的 ALL 表示可以执行所有命令，这是最宽松的授权,一般只给运维负责人用。
su 配置 免密登录的实用模板
如果你不想每次执行 sudo 都输密码，可以在 sudoers 文件里这样写：
deploy ALL=(ALL) NOPASSWD: ALL加了 NOPASSWD 字段之后，这个用户执行 sudo 就不再提示输入密码，但这里有个陷阱如果用户同时被多条规则匹配，sudoers 是后者覆盖前者,顺序乱了照样会要密码。
业内专家指出，免密配置最好结合具体命令来收敛权限，别直接给全部命令免密，比如只允许这个用户免密执行 systemctl 重启服务：
deploy ALL=(ALL) NOPASSWD: /usr/bin/systemctl, /bin/systemctl这样即使用户的登录密码泄露，攻击者也无法直接拿到 root shell,只能重启服务而已。
su 配置 常见的长尾搜索：sudo 和 su 的区别
百度上搜“sudo 和 su 的区别”的人特别多,这里做一组对比表格：
| 维度 | su | sudo |
|---|---|---|
| 切换方式 | 彻底切换用户身份 | 临时借用用户权限 |
| 密码要求 | 目标用户的密码 | 当前用户的密码 |
| 日志记录 | 默认不记录 | 会记录到 /var/log/auth.log |
| 风险等级 | 切换后无操作限制 | 可按命令做白名单限制 |
| 适用场景 | 个人单机使用 | 多人协作服务器管理 |
多数情况下，生产服务器只保留 sudo 的配置就够了，root 密码甚至可以禁用掉，毕竟 sudoers 里能实现 su 切换的全部能力,还能留审计日志。
su 配置 环境变量：切换后 PATH 不对的解决方案
另一个高频问题来自“su 配置 环境变量”，很多用户在 CentOS 或者 Ubuntu 上执行 su root 后，发现 java、python 等命令提示未找到，这是因为 su 默认不会加载目标用户的环境变量文件。
具体的处理方式有下面几步：
- 切换到目标用户时加横杠参数，执行
su - root，这样会重新登录并加载完整环境 - 如果加横杠还是不行，检查
/root/.bashrc和/etc/profile.d/目录下的脚本 - 在
/etc/profile.d/里新建一个.sh文件写export PATH=$PATH:/自定义路径 - 执行
source /etc/profile让配置立即生效
这个方案也适用于 su 配置 简米云 的服务器场景，你在云厂商控制台用 VNC 登录时，出来的 shell 往往是非登录式 shell，光改用户目录下的 .bashrc 不一定生效，必须改全局的 /etc/profile 才有可能覆盖所有登录场景。
su 配置 不生效 的排查思路
如果改完配置发现没效果,请按照下面的顺序排查：
- 确认你编辑的是不是
/etc/sudoers而不是其他备份文件 - 用
sudo -l -U 用户名查看该用户的实际权限 - 检查 sudoers 文件里是否有冲突规则
- 看
/var/log/auth.log中最近的 sudo 认证记录 - 尝试把用户从辅助组里移除再重新添加
一个比较隐蔽的问题是多个 sudoers 片段文件顺序冲突，/etc/sudoers.d/ 目录下如果有多个文件，文件内的规则会按 LANG 环境下字母顺序合并，你可以用 sudo visudo -c 强制检查语法和规则嵌套,这个命令会直接提示具体行号的错误。
su 配置 的最佳实践：安全加固方案
聊完基本操作，再来说说安全，服务器暴露在公网后，root 密码首当其冲是暴力破解的重点目标
，既然你已经会用 su 配置 切用户权限了,那不妨做得再彻底一点：
- 修改
sshd_config文件，设置PermitRootLogin no，直接封死 root 远程登录通道 - 为日常操作创建独立用户并赋予 sudo 权限
- 对
/etc/sudoers设置只读权限，chmod 440 /etc/sudoers - 开启审计日志，
sudo的每次执行都会写入/var/log/secure文件
对于 su 配置 价格 这块，可能会有用户觉得是不是要买商业软件才能做权限审计，实际上这是 Linux 内核自带的 PAM（插拔式认证模块）就是免费提供的，根本无需额外付费，通过 PAM 的 pam_wheel.so 模块，你可以实现“只有 wheel 组用户才能 su 切换”的经典限制策略。
用 wheel 组限制 su 切换
这个操作比较隐蔽但非常有效，在 /etc/pam.d/su 文件里,把下面这行取消注释：
auth required pam_wheel.so use_uid执行后，只有属于 wheel 组的用户才能用 su 切换到其他身份，其他用户就算知道密码也没用，然后把你的管理员账号加到 wheel 组：
usermod -aG wheel deploy大多数 Linux 发行版（像 CentOS 8、Ubuntu 22.04）的默认安装就已经预设了这个配置，只是很多人没注意到这一层，在需要规范审计的金融机构服务器上,这个配置是标准操作。
su 配置 在 简米云 / 酷番云 服务器上的特殊场景
如果你的服务器在简米云上，有两个特殊场景需要处理，第一，云服务器控制台的“重置密码”功能会直接修改系统 root 密码，重置完成之后，你之前的 su 配置 免密规则其实不受影响，因为免密配置在 sudoers 里,和密码机制是两条独立路径。
第二，简米云自带的云监控插件可能会使用一个独立的 agent 用户执行命令，如果你给这个 agent 用户配置了 sudo 权限的规则，注意不要把 shell 环境变量改坏,否则监控数据会上报失败。
假设你在华东1杭州节点买了一台 ECS，从本机 SSH 登录后想快速确认自己的 sudo 权力范围,直接执行：
sudo -ll这会列出当前用户可以执行的所有命令名单，还能看到是否包含 NOPASSWD 标志，这是排查问题最高效的一招,比翻配置文件快得多。
su 配置 常见错误梳理与修复
很多新手会碰到 su: Authentication failure 这个报错，多半是把 sudo 的密码和 root 密码搞混了，sudo 输的是你当前登录用户的密码，su 输的是目标用户的密码，如果你安装了系统后没有手动设置 root 密码（Ubuntu 默认禁用 root 密码），第一次执行 su - 会直接失败,解决办法很简单：
- 执行
sudo passwd root来主动设置一个 root 密码 - 或者放弃 su，改用
sudo -i直接获取 root 环境的 shell - 用
sudo -s也可以临时加 root 权限但不切换工作目录
另一个高频需求是“su 配置 免密 sudo 指定用户”，比如你希望用户 A 能切换成用户 B 并免密执行某个脚本，sudoers 里的写法是这样的：
A ALL=(B) NOPASSWD: /opt/scripts/backup.sh这种写法在自动化部署工作流里极其常用，Jenkins 构建机要重启 Tomcat，或者大数据平台切换提交用户，都可以通过这行精确授权完成，完全不用暴露 A 用户的全部 root 能力。
自动化脚本中的 su 配置 技巧
写 Crontab 定时任务时，如果你在脚本里用了 su - oracle -c '脚本内容'，记得加上全路径，/bin/su 而不是 su，因为 Cron 执行时的环境变量很精简，PATH 里可能不包含 /usr/sbin，这就是很多用户“我手动跑脚本没问题，一加入定时任务就报错”的根本原因。
更保险的写法是把标准输出和错误都重定向到日志文件：
/10 /bin/su - deploy -c "/opt/app/deploy.sh" >> /var/log/deploy.log 2>&1这样一来排错时可以直接看日志内容,不用盲猜是哪一步出了问题。
su 配置 最后还是得回归到这件事上
简单打出这句话：su 配置 的价值从来不是让你多掌握几条命令，而是让你在管理服务器时始终明白自己在以什么身份做什么事情。
认真对待 /etc/sudoers 文件里的每一行权限，比装任何安全软件都管用，开好审计日志，养成定期查看 /var/log/secure 的习惯，你会发现自己对服务器的掌控力会明显提升一个水平，配置本身不难,难的是每一次切换时都想清楚这个权限该不该给。
su 配置 相关问题解答
问：su 切换 root 之后怎么退出回到普通用户？
执行 exit 或者按下 Ctrl + D 组合键即可退出 root 身份，回到原来的普通用户 shell，如果使用了 su - 登录，执行 logout 同样有效。
问：修改 su 配置 免密之后，sudo 还是提示要密码怎么办？
检查 sudoers 文件里该用户的规则顺序，是否有其他规则在你写的 NOPASSWD 之后覆盖了它，建议通过 sudo -l -U 用户名 查看实际匹配规则，若确认规则正确，清理 /etc/sudoers.d/ 目录下的重复配置片段，修改完成或删除后执行 sudo visudo -c 检查语法。
问：不小心把 sudoers 文件改坏了，sudo 命令全部失效怎么恢复？
sudo 本身不可用，直接切换至 root 用户执行命令已经不可能，可以重启服务器进入单用户模式，把 /etc/sudoers 从备份恢复，系统通常会自动生成 /etc/sudoers.bak（visudo 的临时备份），在单用户模式下执行 cp /etc/sudoers.bak /etc/sudoers 再重启即可恢复原状。