Linux如何禁止用户使用su切换到root（切换到.禁止.用户.Linux.su...）

答案：通过配置PAM的pam_wheel.so模块并结合wheel组管理，可限制仅特定用户能su到root，同时推荐使用sudo实现更细粒度的权限控制和审计。

linux如何禁止用户使用su切换到root

在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”的错误。 Linux如何禁止用户使用su切换到root

为什么我应该限制

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

，因为它是一个更通用的配置。

打开文件后，你需要添加或取消注释以下这行：

Post AI

博客文章AI生成器

50 查看详情 Post AI

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的详细内容，更多请关注知识资源分享宝库其它相关文章！

相关标签： linux word centos app ubuntu 工具 session mac ai linux系统区别 Session linux ubuntu centos ssh debian 自动化工作效率大家都在看： Linux常用命令行操作入门教程 Linux如何查看网络接口的MAC地址 Linux怎么查看某个服务的进程详情如何在Linux中分析启动耗时 Linux systemd-analyze诊断 Linux进程管理基础命令总结