su对配置的核心是把 /etc/pam.d/su 里的 wheel 限制、rootok 例外和环境传递约束组合起来，避免普通用户绕过边界直接拿到 root 身份。
su对配置是什么？核心是PAM里的账号边界
很多人第一次接触 Linux 时，只把 su 当成“切 root 的命令”，却不理解 su对配置 背后的多层判断，简单说，su 在输入密码后并不会直接放行，而是把请求交给 PAM（可插拔认证模块）处理，PAM 会根据 /etc/pam.d/su 中定义的规则，逐条检查当前用户、目标用户、是否在 wheel 组、终端是否受信任。
su对配置 并不是改一个文件就完成,它更像一条链：
- 第一层：PAM 规则决定是否允许认证。
- 第二层：用户组和 wheel 组决定能否切换到 root。
- 第三层：login.defs 和 securetty 控制登录环境与日志记录。
- 第四层：shell 和 ulimit 决定切换后能否正常执行。
su对配置涉及的核心文件与作用
不同发行版路径基本一致，但细节有差异,以下是最常需要检查的四个位置：
- /etc/pam.d/su：核心入口，包含 pam_rootok、pam_wheel、pam_unix 等模块。
- /etc/login.defs：定义 SU_LOG_FILE、SU_NAME 等与 su 行为相关的变量。
- /etc/group：root 和 wheel 组关联,控制哪些用户有切换特权。
- /etc/securetty：部分旧式发行版会限制 root 登录的终端，间接影响 su 后的终端行为。
su对配置怎么检查？从一条命令开始排查
如果你怀疑当前 su对配置 有问题，先别急着改文件,按下面顺序排查最省时间。
第一步：查看当前 PAM 规则
打开核心文件：
cat /etc/pam.d/su典型输出中会看到类似规则：
auth sufficient pam_rootok.so
auth required pam_wheel.so use_uid这两行含义不同，pam_rootok.so 表示 root 用户切换时不需要密码；pam_wheel.so 表示只有 wheel 组成员才能执行 su。auth required pam_wheel.so use_uid 没有被注释，而你的普通用户又不在 wheel 组,就会出现认证失败。
第二步：确认用户组归属
执行：
id 用户名如果输出中没有 wheel 组，但配置又要求 wheel 才能切 root,就需要把用户加入组：
usermod -aG wheel 用户名注意，加入组后需要重新登录才生效，也可以临时用 newgrp wheel 验证当前会话是否已获得 wheel 身份。
第三步：观察失败日志
多数情况下，su对配置 的错误不会直接显示细节,需要看系统认证日志：
- 在 RHEL/CentOS 系：
tail -f /var/log/secure - 在 Debian/Ubuntu 系：
tail -f /var/log/auth.log
日志里出现 pam_wheel(su:auth): Access denied 这类记录，基本可以定位是 wheel 组限制，如果没有这条日志，再去检查密码是否正确、pam_unix 是否被错误注释。
su对配置常见报错与调整方向
| 报错信息 | 可能原因 | 调整方向 |
|---|---|---|
| su: Authentication failure | 密码错误或被 PAM 策略拦截 | 核对密码，检查 pam_wheel 是否拦截 |
| su: Permission denied | 当前用户不在 wheel 组 | 加入 wheel 组或注释 pam_wheel |
| su: cannot set user id | 用户存在但无法切换，ulimit 限制 | 检查 ulimit -u 和 /etc/security/limits.conf |
| su: /bin/bash: Permission denied | 目标用户 shell 不可执行或无权限 | 检查 /etc/passwd 中 shell 路径 |
su对配置和sudo对比：日常登录用哪个更合适？
很多人搜 su对配置和sudo对比，其实两者不是对立关系,而是不同场景下的互补工具。
| 维度 | su | sudo |
|---|---|---|
| 密码对象 | 目标用户密码，通常因共享 root 密码而扩散风险 | 当前用户密码，避免共享 root 密码 |
| 权限颗粒度 | 切换后获得完整目标身份，权限大 | 可精确到单条命令、参数和用户 |
| 审计能力 | 默认记录较粗，需配合 SU_LOG_FILE | 日志更细，可追踪到具体命令 |
| 配置复杂度 | 主要在 PAM 和 wheel 组，上手简单 | 需编辑 sudoers，语法复杂 |
多人共用服务器时的场景化建议
如果是一台多人共用的 Linux 服务器，行业共识认为最稳妥的做法是：禁止普通用户直接 su 到 root，只允许 wheel 组通过 sudo 提权，这样即使某个开发账号泄露，攻击者也拿不到 root 密码，配置上可以保留 pam_wheel.so use_uid 作为硬限制，并把日常维护命令放进 sudoers 白名单。
su对配置要花多少钱？其实先算时间成本
不少新手会问 su对配置要花多少钱，如果只是配置 Linux 系统，su对配置 本身不产生任何软件授权费，真正消耗的是学习成本和服务器资源，以常见入门云服务器为例，多数服务商的基础实例月成本在两位数到三位数，地域选择如北京、上海等会影响价格，但 su对配置 不会作为单独收费项出现，对个人开发者来说，更值得计算的是排查一轮认证问题要花多少分钟,而不是软件费用。
su对配置在Ubuntu和CentOS中的差异
很多教程只讲 CentOS，但 Ubuntu 的默认行为并不完全一样，Ubuntu 默认 root 账号是锁定的，普通用户通过 sudo 提权，而不是直接 su 到 root，CentOS 和 RHEL 系则更常直接启用 root 账号，su对配置 在两类系统中的侧重点不同。
- Ubuntu：更依赖 sudo 组，/etc/pam.d/su 中可能默认没有启用 pam_wheel,需要手动加入。
- CentOS/RHEL：wheel 组是传统管理入口，通常与 pam_wheel 搭配使用。
- Debian：与 Ubuntu 类似，root 默认无密码，日常管理通过 sudo。
- Arch Linux：用户需要自行配置 sudo 或 su 策略,灵活性高但易出错。
推荐的一套最小化安全配置
如果你需要快速落地一套可用的 su对配置,可以按以下步骤操作：
新建管理用户并加入 wheel 组：
useradd -m admin
usermod -aG wheel admin-
保持
pam_wheel.so use_uid生效，并确保 rootok 放在 wheel 之前。 -
禁止 root 直接 SSH 登录，修改
/etc/ssh/sshd_config：
PermitRootLogin no
-
给 admin 用户配置 sudo 权限，避免日常操作直接 su 到 root。
-
检查日志文件路径，确认 su 登录行为有记录。
su对配置在北京Linux服务器运维中的典型用法
在北京的 Linux 运维岗位中，su对配置 常和系统加固一起出现，很多生产服务器交付前会做一轮基础检查：确认 /etc/pam.d/su 中 wheel 限制已开启，确认 root 密码没有多人共享，确认 sudoers 授权范围最小化，这样做的目的不是让登录变麻烦，而是减少 root 身份扩散后被滥用的可能。
哪些场景不建议使用 su 切换 root
- 需要审计到具体命令的生产环境。
- 多人共享同一台服务器的开发测试环境。
- 对外提供 Web 服务、可能被入侵的边界服务器。
- 已经使用集中认证或堡垒机的企业环境。
在这些场景下，改用 sudo 配合审计日志，比单纯开放 su对配置 更符合安全基线。
su对配置并不复杂，但因为它横跨 PAM、用户组、日志和 shell 环境，出错时往往让初学者摸不着头脑，只要抓住 /etc/pam.d/su 中的 wheel 限制和 rootok 例外两条主线，再配合日志定位,就能解决大多数问题。
su对配置相关问题
su对配置失败提示Authentication failure怎么排查？
先输入正确密码再次确认，若仍失败，执行 cat /etc/pam.d/su，重点看 pam_wheel.so 是否启用，再看 id 用户名 是否包含 wheel 组，若没有，需要加入 wheel 组或调整 PAM 规则,日志文件通常能给出更具体的拒绝原因。
su对配置和sudo配置哪个更安全？
从权限控制角度说，sudo 更安全，它不需要共享 root 密码，并且可以限制到具体命令，su 切换后权限完整，一旦密码泄露，攻击者能以 root 身份做任何事，因此多数生产环境建议禁用普通用户的 su 到 root，改用 sudo 管理日常任务。
su对配置修改后不重启能生效吗？
PAM 认证规则通常即时生效，不需要重启服务，用户组的变化则需要重新登录才生效，如果修改的是 /etc/login.defs 中与 su 日志相关的变量，通常也在下一次 su 操作时生效。