This error occurs when sshd_config restricts SSH login to specific users via the AllowUsers directive. Fix it by adding your username to the AllowUsers list in sshd_config and restarting the SSH service.
The SSH daemon (sshd) has access control rules configured in /etc/ssh/sshd_config that explicitly whitelist which users are allowed to authenticate. The AllowUsers directive creates a list of permitted user accounts—if it is set, only users in that list can log in via SSH. When a user attempts to connect and is not in the AllowUsers list, the connection is rejected with this error message. This is a security feature that restricts SSH access to specific accounts, preventing unauthorized users from attempting login. However, if configured incorrectly, it can accidentally lock out legitimate users, including administrative accounts.
Open the sshd_config file and view the AllowUsers directive:
grep -i allowusers /etc/ssh/sshd_configIf the line is commented out (starts with #) or missing, AllowUsers is not active and this is not the issue. If the line exists and your username is not listed, proceed to the next step.
Edit the SSH configuration file with sudo:
sudo nano /etc/ssh/sshd_configFind the line starting with AllowUsers. If multiple users need access, add them space-separated on the same line:
AllowUsers user1 user2 user3Or add the user to an existing AllowUsers line:
AllowUsers admin developerIf the line does not exist, add it. Use Tab (not spaces) between "AllowUsers" and the usernames for proper parsing.
If you need root-level SSH access, add root to the AllowUsers list:
AllowUsers root admin user1Without root in AllowUsers, you cannot SSH as root, even with valid credentials. This is why the root user should almost always be included if AllowUsers is set.
Before restarting sshd, test that your configuration file is valid:
sudo sshd -tIf the command returns nothing, the syntax is correct. If there is an error, fix the issue in sshd_config and test again.
Apply the changes by restarting sshd:
sudo systemctl restart sshdOr on older systems:
sudo service ssh restartAlways keep an existing SSH session open until you verify the new connection works, in case you need to roll back the configuration.
Open a new terminal or SSH session and attempt to log in:
ssh user@hostnameIf the connection succeeds, the error is resolved. If it still fails, check /var/log/auth.log for additional error details:
tail -f /var/log/auth.log | grep sshdWhen both AllowUsers and AllowGroups are set in sshd_config, a user must satisfy BOTH conditions: they must be listed in AllowUsers AND belong to a group in AllowGroups. If using AllowGroups, ensure your user is in one of the specified groups.
On Windows systems running OpenSSH, AllowUsers/AllowGroups directives may not work correctly with domain users without additional configuration. A workaround is to create a local group and nest the domain group within it, then use AllowGroups to reference the local group.
For security, SSH access as root is discouraged. Instead, create a dedicated admin user, add it to the AllowUsers list, and use sudo for administrative tasks.
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