sshd_config中DenyUsers userid@host配置生效异常排查求助

Hey there, let's walk through the key troubleshooting steps to figure out why your DenyUsers userID@host rule is working on some hosts but not others:

SSH doesn’t always rely solely on the main /etc/ssh/sshd_config—it might load additional config files that override your rule.

• On both working and non-working hosts, run sshd -T to dump the actual running configuration (this is what the sshd daemon is really using). Search for the denyusers line here—if it doesn’t match what you set in the config, another file is overwriting it.
• Keep an eye out for Include directives in the main config, or files in /etc/ssh/sshd_config.d/ (many modern distros use this directory to split configs). A stray rule in one of these could be undoing your DenyUsers setting.

The host part in your rule needs to match how the SSH server identifies the client.

• When the user tries to connect to a non-working host, check the SSH logs (usually /var/log/auth.log or /var/log/secure). Look for lines like Accepted publickey for userID from 192.168.1.50—this tells you the server is seeing an IP, not a hostname. If your rule uses a hostname (like userID@client.example.com), DNS resolution might be broken on that server.
• Test using the client’s IP in the rule (e.g., DenyUsers userID@192.168.1.50) to rule out DNS-related issues.

SSH processes user/group rules in a specific order, and an AllowUsers or AllowGroups rule can override your DenyUsers setting. The processing order is:

1. DenyUsers
2. AllowUsers
3. DenyGroups
4. AllowGroups

• If you have an AllowUsers userID@* or similar rule on a non-working host, it will let the user connect regardless of your DenyUsers line. Double-check all allow/deny rules to ensure there’s no overlap.

It’s easy to overlook, but updating the config won’t take effect until you restart the sshd daemon.

• On non-working hosts, run sudo systemctl restart sshd (or sudo service ssh restart for older distros) and test again.
• Check the daemon status with sudo systemctl status sshd to make sure it restarted without errors—if there was a config syntax mistake, it might have failed to reload.

SSH ignores config files that have overly open permissions (since they pose a security risk).

• Ensure /etc/ssh/sshd_config and any included files have permissions set to 600 (sudo chmod 600 /etc/ssh/sshd_config) and are owned by root:root (sudo chown root:root /etc/ssh/sshd_config).
• Check the SSH logs for warnings about "bad ownership or modes for file"—this is a super common issue that’s easy to miss.

From the user’s client machine, run ssh -vvv userID@non-working-host and look through the detailed output. This will show you exactly what’s happening during the connection attempt—whether the server is rejecting the connection at the rule level, or if another auth method (like SSH keys) is being allowed before the deny rule kicks in.

内容的提问来源于stack exchange，提问作者user227863