How to fix User user from hostname not allowed because listed in DenyUsers in SSH

SSHBEGINNERHIGHUpdated Jan 4, 2026· 179 views

This SSH error occurs when a user is explicitly blocked by the DenyUsers directive in sshd_config. Remove the user from the DenyUsers list and restart the SSH service to restore access.

Quick fix

Fixes User user from hostname not allowed because listed in DenyUsers

grep -n "DenyUsers" /etc/ssh/sshd_config
  1. View the current DenyUsers configuration
  2. Backup the sshd_config file
  3. Edit sshd_config to remove the user from DenyUsers
  4. Validate the sshd_config syntax
ssh — error
grep -n "DenyUsers" /etc/ssh/sshd_config
User user from hostname not allowed because listed in DenyUsers

What this error means

The SSH daemon (sshd) evaluates access control directives in a specific order: DenyUsers has the highest priority, followed by AllowUsers, DenyGroups, and AllowGroups. When a login attempt matches a pattern in DenyUsers, the SSH server immediately rejects the connection with this error message. This is a security feature that prevents specific users or user@host combinations from accessing the system via SSH, regardless of whether they are listed in AllowUsers.

Typical symptoms

  • SSH login fails with "not allowed because listed in DenyUsers" in server logs
  • User can connect from some hosts but not others (if using user@host patterns)
  • Error appears in /var/log/auth.log or /var/log/secure depending on your distribution
  • Authentication is rejected before password prompt on some systems
  • Sudo or other local access methods may still work while SSH is blocked

Common causes

  1. The user is explicitly listed in the DenyUsers directive in /etc/ssh/sshd_config
  2. A wildcard pattern in DenyUsers matches the user (e.g., "bad*" matches "baduser")
  3. A user@host pattern matches both the username and connecting hostname/IP
  4. The DenyUsers directive appears after a Match block in sshd_config, applying only within that context
  5. Configuration was set intentionally as a security policy and is now blocking legitimate access

How to fix "User user from hostname not allowed because listed in DenyUsers"

1View the current DenyUsers configuration

SSH into the server with an administrative account or physical console access and check the SSH configuration file:

bash
grep -n "DenyUsers" /etc/ssh/sshd_config

This shows all DenyUsers lines and their line numbers. Note the exact pattern matching your user.

2Backup the sshd_config file

Before editing, create a safety backup:

bash
sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.backup

This allows you to quickly restore if something goes wrong.

3Edit sshd_config to remove the user from DenyUsers

Open the SSH configuration file with a text editor:

bash
sudo nano /etc/ssh/sshd_config

Locate the DenyUsers line (or lines) and either:
- Remove the specific username: DenyUsers baduser1 baduser2 → DenyUsers baduser1
- Delete the entire DenyUsers line if the user was the only entry
- For user@host patterns, remove only the matching pattern: DenyUsers user@*.example.com user@10.0.0.0/8 → DenyUsers user@*.example.com

Save the file (Ctrl+O, Enter, Ctrl+X in nano).

4Validate the sshd_config syntax

Before restarting SSH, verify the configuration file has no syntax errors:

bash
sudo sshd -t

If this command produces no output, the configuration is valid. If you see errors, fix them before proceeding.

5Restart the SSH service

Apply the configuration changes by restarting the SSH daemon. The command depends on your init system:

For systemd (Ubuntu, Debian, RHEL 7+, CentOS 7+):

bash
sudo systemctl restart sshd

For older systems with SysVinit:

bash
sudo service ssh restart

Or for Alpine Linux:

bash
sudo rc-service sshd restart
6Test SSH access from another terminal

Verify the user can now log in. Open a new terminal or SSH session and attempt to connect:

bash
ssh username@server_ip

If access is restored, the error is resolved. If the error persists, verify in Step 1 that all matching patterns were removed, including user@host entries.

Advanced notes

DenyUsers patterns support wildcards ("ba*" matches "baduser", "badmin") and user@host format to restrict specific users from specific hosts. The processing order is critical: DenyUsers is evaluated first, so if a user appears in both DenyUsers and AllowUsers, the denial takes precedence. Match blocks in sshd_config apply directives only to subsequent connections matching the condition; ensure DenyUsers is placed outside Match blocks if it should apply globally. Some systems use AllowUsers as a whitelist instead of DenyUsers as a blacklist—if both are present, the user must satisfy both conditions. On systems with PAM (Pluggable Authentication Modules), ensure /etc/pam.d/sshd is also configured correctly, as PAM may apply additional restrictions after sshd_config directives.

Frequently asked questions

What does "User user from hostname not allowed because listed in DenyUsers" mean?
The SSH daemon (sshd) evaluates access control directives in a specific order: DenyUsers has the highest priority, followed by AllowUsers, DenyGroups, and AllowGroups. When a login attempt matches a pattern in DenyUsers, the SSH server immediately rejects the connection with this error message. This is a security feature that prevents specific users or user@host combinations from accessing the system via SSH, regardless of whether they are listed in AllowUsers.
How do I fix "User user from hostname not allowed because listed in DenyUsers"?
This SSH error occurs when a user is explicitly blocked by the DenyUsers directive in sshd_config. Remove the user from the DenyUsers list and restart the SSH service to restore access.
What causes "User user from hostname not allowed because listed in DenyUsers"?
The user is explicitly listed in the DenyUsers directive in /etc/ssh/sshd_config A wildcard pattern in DenyUsers matches the user (e.g., "bad*" matches "baduser") A user@host pattern matches both the username and connecting hostname/IP
Is the "User user from hostname not allowed because listed in DenyUsers" error serious?
Yes. This is a high-severity error that usually blocks work until it is fixed, but the steps above resolve it.

Official resources & further reading