答案：通过配置PAM的pam_wheel.so模块并结合wheel组管理，可限制仅特定用户能su到root，同时推荐使用sudo实现更细粒度的权限控制和审计。
在Linux系统中，禁止普通用户通过
su
命令切换到root用户，最常见且有效的方法是利用PAM（Pluggable Authentication Modules）机制，特别是通过配置
pam_wheel.so
模块，将root权限的
su
命令限制给特定的用户组。这样一来，只有属于该组的用户才有资格尝试切换到root，大大增强了系统的安全性。
解决方案
要实现这一目标，我们主要需要修改PAM针对
su
服务的配置文件，并管理一个特定的用户组（通常是
wheel
组）。这个过程并不复杂，但每一步都需要细心。
首先，你需要编辑
su
命令的PAM配置文件。在大多数基于PAM的Linux发行版中，这个文件通常是
/etc/pam.d/su
或
/etc/pam.d/su-l
。我个人习惯修改
/etc/pam.d/su
，因为它影响所有
su
的使用，包括
su -
。
打开这个文件（使用
vi
、
nano
或你喜欢的编辑器）：
sudo vi /etc/pam.d/su
在文件的开头部分，通常会有一行注释掉的关于
pam_wheel.so
的配置。你需要找到类似下面这样的行（或在适当位置添加）：
# auth required pam_wheel.so use_uid
将其取消注释，或者直接添加进去：
auth required pam_wheel.so use_uid
这行配置的意思是：在进行认证时，
pam_wheel.so
模块是必需的（
required
）。
use_uid
选项告诉PAM，在检查用户是否属于
wheel
组时，要检查目标用户（即root）的UID，而不是发起
su
命令的用户的UID。这意味着，只有当尝试切换到root的用户同时也在
wheel
组中时，认证才会通过。
保存并关闭文件。
接下来，你需要确保系统上存在
wheel
用户组，并将允许使用
su
切换到root的用户添加到这个组中。
检查
wheel
组是否存在：
grep wheel /etc/group
如果不存在，你需要创建它：
sudo groupadd wheel
然后，将需要拥有
su
到root权限的用户添加到
wheel
组中。例如，如果你想让用户
adminuser
可以
su
到root：
sudo usermod -aG wheel adminuser
这里的
-aG
参数表示将用户添加到附加组，且不移除其现有组。
完成这些步骤后，只有
wheel
组的成员才能使用
su
命令切换到root。其他普通用户尝试
su -
到root时，将会收到“Authentication failure”的错误。
为什么我应该限制
su
到root，以及
sudo
是不是更好的选择？
限制
su
到root，在我看来，是任何认真对待系统安全的管理员都应该考虑的基本措施。原因很简单：root账户拥有对系统无限制的权力。如果任何用户都能轻易地通过
su
并猜测或窃取到root密码，那么系统的安全防线就形同虚设了。这就像把银行金库的钥匙随便放在某个抽屉里，虽然加了锁，但谁都能去试。
从安全原则上讲，我们应该遵循“最小权限原则”。用户只应拥有完成其工作所需的最低权限。让所有用户都能尝试
su
到root，显然违背了这一点。
你提到了
sudo
，这确实是一个非常好的替代方案，甚至可以说，在大多数现代Linux环境中，
sudo
是进行系统管理的首选工具，而非
su
。我个人几乎所有的管理操作都通过
sudo
完成。
su
和
sudo
的主要区别在于：
认证方式：
su
要求你输入目标用户（通常是root）的密码，而
sudo
要求你输入自己的密码。这意味着使用
sudo
时，你不需要知道root密码，从而避免了root密码泄露的风险。粒度控制：
sudo
可以通过
/etc/sudoers
文件进行极其精细的权限控制，你可以指定某个用户或用户组可以执行哪些特定的命令，甚至不需要密码（尽管不推荐）。而
su
要么全给root权限，要么不给。审计日志：
sudo
会详细记录哪个用户在何时执行了哪个命令，这对于安全审计和故障排查至关重要。
su
虽然也能记录，但其日志不如
sudo
那样细致和易于追踪。
所以，回到你的问题，是的，
sudo
在绝大多数情况下都是比
su
更好的选择。通过限制
su
到root，并鼓励（或强制）用户使用
sudo
进行管理操作，我们不仅提高了安全性，还大大提升了系统的可审计性和管理效率。我甚至会建议，在可能的情况下，完全禁用root用户的直接登录，只允许通过
sudo
进行权限提升。
如何配置PAM以允许特定用户组使用
su
到root？
配置PAM来限制
su
到root的过程，其实就是我们前面解决方案中提到的核心步骤，但这里我们可以更深入地探讨一下细节和一些需要注意的地方。
首先，再次强调配置文件路径：
/etc/pam.d/su
。在某些系统上，可能还有
/etc/pam.d/su-l
，其中
su-l
通常用于
su -
（带登录shell的切换），而
su
用于
su
（不带登录shell）。为了确保全面限制，通常我会选择修改
/etc/pam.d/su
，因为它是一个更通用的配置。
打开文件后，你需要添加或取消注释以下这行：
auth required pam_wheel.so use_uid
我们来解析一下这行的含义：
auth
: 这表示这是一个认证模块。PAM的配置分为
auth
（认证）、
account
（账户管理）、
password
（密码管理）和
session
（会话管理）等不同类型。
required
: 这表示这个模块必须成功通过认证。如果这个模块失败，整个认证过程就会失败，并且PAM不会继续处理后续的模块。
pam_wheel.so
: 这是实际执行
wheel
组检查的PAM模块。
use_uid
: 这个选项非常关键。它告诉
pam_wheel.so
模块，在检查用户是否属于
wheel
组时，应该检查目标用户（即
su
命令尝试切换到的用户，在这里是root）的UID，而不是发起
su
命令的用户的UID。这听起来有点反直觉，但实际上，它意味着只有当发起
su
命令的用户，同时也是
wheel
组的成员时，它才能成功切换到目标用户（root）。如果没有
use_uid
，
pam_wheel.so
可能会检查目标用户（root）是否在
wheel
组，这显然不是我们想要的效果。
操作步骤回顾：
编辑PAM配置：
sudo vi /etc/pam.d/su
添加或取消注释：
auth required pam_wheel.so use_uid
并保存。
创建
wheel
组（如果不存在）：
sudo groupadd wheel
在一些发行版（如Red Hat/CentOS）中，
wheel
组可能已经存在，并且默认配置允许其成员使用
sudo
。在Debian/Ubuntu中，通常是
sudo
组。但对于
su
限制，我们这里明确使用
wheel
组。
将允许的用户添加到
wheel
组：
sudo usermod -aG wheel username
将
username
替换为实际的用户名。请记住，你至少应该将自己（当前正在操作的用户）添加到
wheel
组，否则一旦保存PAM配置，你可能会发现自己也无法
su
到root了。这是一个非常常见的“把自己锁在门外”的错误。
一个简单的测试流程：
在你将自己添加到
wheel
组之前，尝试用普通用户
su -
到root，应该会失败。将你的用户添加到
wheel
组。注销并重新登录（或使用
newgrp wheel
来激活新的组权限）。再次尝试用你的用户
su -
到root，这次应该会成功。用一个不在
wheel
组的普通用户尝试
su -
到root，应该会失败。
这个配置是相当可靠的。它提供了一个明确的门槛，确保只有经过授权的用户才能尝试获取root权限。
控制root访问的常见挑战与替代方法
在管理root访问权限时，我们总会遇到一些挑战，同时也有多种方法可以作为补充或替代方案，共同构建一个更健壮的安全体系。这不仅仅是技术上的配置，更是一种安全策略的考量。
常见挑战：
遗漏授权： 最常见的问题之一是，当有新的系统管理员加入团队时，忘记将他们添加到
wheel
组（或
sudo
组）。这会导致新管理员无法执行必要的系统维护任务，影响工作效率。反之，如果有人离职，也需要及时从这些特权组中移除。PAM配置错误： 错误地修改
pam.d
文件，比如语法错误，或者配置了一个过于严格的规则而没有给自己留后门，这可能导致所有人都无法
su
到root，甚至无法登录。这是一种灾难性的错误，可能需要进入恢复模式才能修复。密码管理： 即使限制了
su
到特定组，如果root密码本身被泄露，或者设置得过于简单，那么限制的意义也会大打折扣。其他提权途径： 限制
su
只是堵住了一个口子。系统可能还存在其他漏洞，比如内核漏洞、不安全的
setuid
程序、或者配置不当的服务，这些都可能被恶意用户利用来获取root权限。
替代或补充方法：
强化
sudo
配置： 我一直认为
sudo
是管理特权访问的最佳实践。与其让少数人能
su
到root，不如让更多人通过
sudo
以最小权限执行特定命令。
细粒度控制： 使用
visudo
编辑
/etc/sudoers
文件，精确定义哪些用户或组可以执行哪些命令。例如，只允许某个用户重启服务，而不允许他们安装软件包。强制密码： 确保
sudo
始终要求用户输入自己的密码，而不是使用
NOPASSWD
选项（除非有非常特殊的自动化需求）。日志审计： 利用
sudo
的日志功能，定期审查谁在何时执行了哪些特权命令。
禁用root用户的SSH直接登录： 这是一个非常重要的安全措施。编辑
/etc/ssh/sshd_config
文件，将
PermitRootLogin
设置为
no
：
PermitRootLogin no
然后重启SSH服务。这样，即使用户知道root密码，也无法直接通过SSH登录root账户。他们必须先登录一个普通用户账户，然后才能通过
sudo
或
su
提升权限。这增加了攻击者的难度，并且为审计提供了额外的上下文。
使用密钥对认证，并禁用密码认证： 对于SSH登录，强烈推荐使用SSH密钥对进行认证，并禁用基于密码的认证。这大大降低了暴力破解的风险。
系统强化（Hardening）：
SELinux/AppArmor： 这些强制访问控制（MAC）系统可以进一步限制即便是root用户或特权进程能做什么。它们为系统提供了额外的安全层，即使某个服务被攻破，其权限也可能被SELinux/AppArmor限制。定期更新系统： 及时打补丁，修复已知的安全漏洞，这是防止各种提权攻击的基础。禁用不必要的服务： 减少攻击面，只运行必需的服务。
堡垒机/跳板机： 在大型或高安全要求的环境中，可以引入堡垒机或跳板机作为所有SSH连接的入口。用户首先登录堡垒机，再从堡垒机跳转到目标服务器。这有助于集中管理和审计所有对生产系统的访问。
综合来看，限制
su
到root只是我们构建安全堡垒的第一步。一个真正安全的系统需要一个多层次、综合性的安全策略，将技术配置、流程管理和人员培训结合起来。我个人偏向于“纵深防御”的理念，即便是root访问，也要有层层关卡，确保每一步操作都是可控、可审计的。
以上就是Linux如何禁止用户使用su切换到root的详细内容，更多请关注创想鸟其它相关文章！
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 chuangxiangniao@163.com 举报，一经查实，本站将立刻删除。
发布者：程序猿，转转请注明出处：https://www.chuangxiangniao.com/p/201029.html
微信扫一扫 
支付宝扫一扫 
