在CentOS系统的OpenSSH安全配置中，AllowUsers和DenyUsers的匹配逻辑遵循一个核心规则：DenyUsers优先级高于AllowUsers。也就是说，当一个用户同时出现在AllowUsers和DenyUsers列表中时，系统会先执行DenyUsers的拒绝策略，该用户将被禁止登录。配置文件路径为/etc/ssh/sshd_config，修改后需要执行systemctl restart sshd使其生效。理解这个逻辑是做好服务器SSH访问控制的基础，下面我会把所有细节、注意事项和实战配置全部讲透。

一、AllowUsers与DenyUsers的核心匹配机制

OpenSSH在处理用户登录请求时，会按照固定顺序检查访问控制规则。当sshd_config中同时配置了AllowUsers和DenyUsers时，处理流程如下：首先检查DenyUsers列表，如果用户在其中，直接拒绝，不再继续判断；如果用户不在DenyUsers中，再检查AllowUsers列表，如果在其中则允许登录；如果两个列表都没有匹配到，默认行为取决于其他规则（如AllowGroups或默认策略）。

这个机制可以用一句话概括：拒绝优先，允许在后。这和很多人直觉上认为的"允许优先"完全相反。实际运维中，不少人因为不了解这个优先级，配置了AllowUsers却发现某些用户依然无法登录，排查半天才发现该用户被DenyUsers拦截了。

从OpenSSH官方文档来看，AllowUsers和DenyUsers都支持使用通配符、用户名@主机、用户名@IP等格式。例如：

AllowUsers admin root@192.168.1.100
DenyUsers test guest@*

上面的配置表示：admin用户和从192.168.1.100登录的root用户被允许，test用户以及从任何主机以guest身份登录的用户被拒绝。

二、sshd_config中的完整配置示例

下面给出一个生产环境中常见的、较为完善的SSH用户访问控制配置：

# 允许的用户列表
AllowUsers admin deploy monitor

# 拒绝的用户列表
DenyUsers root test guest nobody

# 允许的用户组（作为补充控制）
AllowGroups wheel admin

# 禁用root直接登录（更安全的做法）
PermitRootLogin no

# 限制登录尝试次数
MaxAuthTries 3

# 限制同时登录数
MaxSessions 2

在这个配置中，admin、deploy、monitor三个用户被明确允许。root、test、guest、nobody被明确拒绝。即便你把root加到AllowUsers里，只要DenyUsers中有root，root依然无法登录——这就是优先级的体现。

三、只配置AllowUsers不配置DenyUsers的风险

很多管理员只设置AllowUsers，认为"没在允许列表里的用户自然就不能登录了"。这种想法在默认配置下是成立的，但存在隐患。如果你的系统之前配置过AllowUsers，后来删除了该配置项，或者sshd_config中有其他宽松的规则（比如AllowGroups包含了大量用户），那么未在AllowUsers中的用户可能反而获得了登录权限。

更安全的做法是同时使用AllowUsers和DenyUsers，形成"白名单+黑名单"的双重保险。白名单明确谁能进，黑名单明确谁绝对不能进，两者配合才能构建真正严密的访问控制体系。

四、用户名@主机格式的精确控制

AllowUsers和DenyUsers都支持"用户@主机"的格式，这在多用户、多IP的服务器环境中非常实用。具体格式包括：

用户名@IP地址：如admin@10.0.0.5，表示只有从10.0.0.5这个IP登录的admin才被允许。

用户名@IP/子网掩码：如deploy@192.168.1.0/24，表示从192.168.1.0网段登录的deploy用户被允许。

用户名@主机名：如monitor@webserver01，表示从主机名为webserver01的机器登录的monitor用户被允许。

# 精确到IP段的控制
AllowUsers admin@10.0.0.0/8 deploy@192.168.1.0/24
DenyUsers test@* root@172.16.0.0/16

这里DenyUsers中的test@*表示从任何主机以test身份登录都被拒绝，root@172.16.0.0/16表示从172.16网段以root登录被拒绝。注意，如果admin同时在AllowUsers和DenyUsers中出现，DenyUsers会优先生效。

五、与其他访问控制指令的配合关系

OpenSSH的访问控制不只有AllowUsers和DenyUsers，还有AllowGroups、DenyGroups、Allow、Deny等指令。它们之间的优先级关系如下：

DenyUsers → AllowUsers → DenyGroups → AllowGroups → 其他规则

也就是说，DenyUsers的优先级最高，AllowGroups的优先级最低。如果一个用户既在DenyUsers中，又在AllowGroups中，依然会被DenyUsers拦截。理解这个完整的优先级链，才能避免配置冲突。

# 完整的多层控制示例
DenyUsers root bin daemon nobody
AllowUsers admin deploy
DenyGroups temp
AllowGroups wheel admin
Allow 192.168.1.0/24
Deny 10.20.30.0/24

上面这个配置中，先拒绝特定用户，再允许特定用户，再拒绝特定组，再允许特定组，最后用IP级别的Allow和Deny做补充。层次分明，逻辑清晰。

六、修改配置后的生效与验证方法

修改/etc/ssh/sshd_config后，必须重启sshd服务才能生效。CentOS 7和CentOS 8/Stream的命令略有不同：

# CentOS 7
systemctl restart sshd

# CentOS 8 / Stream
systemctl restart sshd

重启之前，强烈建议先用sshd -t命令检查配置语法是否正确：

sshd -t

如果没有输出，说明语法正确；如果有报错信息，根据提示修正后再重启。千万不要在没有验证的情况下直接重启，否则配置错误会导致SSH服务无法启动，你将无法远程连接服务器。

验证配置是否生效，可以用另一台机器尝试以被拒绝的用户登录，应该看到"Permission denied"的提示。也可以查看/var/log/secure日志：

tail -f /var/log/secure

日志中会记录用户登录尝试的详细信息，包括用户名、来源IP、匹配到的规则等。

七、常见踩坑点与实战建议

第一个坑：配置了AllowUsers后，发现某些合法用户也无法登录。排查方法是检查该用户是否同时出现在DenyUsers中，或者是否被DenyGroups、Deny指令拦截。

第二个坑：使用通配符时过于宽泛。比如DenyUsers *@*会拒绝所有用户从所有主机登录，这等于把自己锁在门外。通配符要谨慎使用，尽量精确到具体用户和具体IP。

第三个坑：修改配置后忘记重启sshd，或者重启时配置有语法错误导致服务挂掉。建议在修改前先开一个不会关闭的SSH会话作为保底，或者通过服务器控制台（如VNC、IPMI）操作。

第四个坑：忽略了sshd_config中其他可能覆盖用户控制的选项。比如PermitRootLogin yes会允许root直接登录，即使你在AllowUsers中没写root。所以要全局审视整个配置文件，而不是只盯着AllowUsers和DenyUsers。

实战建议：在生产环境中，推荐采用"最小权限原则"。先用DenyUsers拒绝所有非必要用户（包括root），再用AllowUsers精确放开需要的用户。同时配合密钥认证、禁用密码登录、修改默认端口等措施，构建多层防御体系。

八、总结

CentOS上OpenSSH的AllowUsers与DenyUsers逻辑并不复杂，核心就是DenyUsers优先级高于AllowUsers。掌握这个规则，再配合用户@主机格式、优先级链、多层控制策略，就能实现精细的SSH访问管理。配置前用sshd -t验证，修改后重启服务，通过日志确认效果，这是标准操作流程。把这些做到位，你的服务器SSH安全就有了坚实的基础。