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.
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.
SSH into the server with an administrative account or physical console access and check the SSH configuration file:
grep -n "DenyUsers" /etc/ssh/sshd_configThis shows all DenyUsers lines and their line numbers. Note the exact pattern matching your user.
Before editing, create a safety backup:
sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.backupThis allows you to quickly restore if something goes wrong.
Open the SSH configuration file with a text editor:
sudo nano /etc/ssh/sshd_configLocate 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 [email protected]/8 → DenyUsers user@*.example.com
Save the file (Ctrl+O, Enter, Ctrl+X in nano).
Before restarting SSH, verify the configuration file has no syntax errors:
sudo sshd -tIf this command produces no output, the configuration is valid. If you see errors, fix them before proceeding.
Apply the configuration changes by restarting the SSH daemon. The command depends on your init system:
For systemd (Ubuntu, Debian, RHEL 7+, CentOS 7+):
sudo systemctl restart sshdFor older systems with SysVinit:
sudo service ssh restartOr for Alpine Linux:
sudo rc-service sshd restartVerify the user can now log in. Open a new terminal or SSH session and attempt to connect:
ssh username@server_ipIf 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.
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.
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
How to fix SSH man-in-the-middle attack warning in SSH
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ WARNING: UNPROTECTED PRIVATE KEY FILE! @ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
How to fix "WARNING: UNPROTECTED PRIVATE KEY FILE!" in SSH
sign_and_send_pubkey: no mutual signature supported
How to fix "sign_and_send_pubkey: no mutual signature supported" in SSH
Bad owner or permissions on /home/user/.ssh/known_hosts
How to fix "Bad owner or permissions on known_hosts" in SSH
It is required that your private key files are NOT accessible by others.
How to fix "private key files are NOT accessible by others" in SSH