Disable root login by password
Why root login by password is dangerous, how PermitRootLogin options differ, and how to disable it without losing access to the machine.
Updated August 23, 2026
Everyone knows the root name: it exists on every machine and has full permissions. A brute-forcer only has one thing left to guess — the password. Disabling password login for root removes an entire class of attacks with a single parameter.
Preparation
First the fallback, then the ban. The order is the reverse of what you feel like doing.
- Create a user with sudo — users and sudo.
- Add your SSH key to it and verify login in a separate terminal window.
- Make sure
sudo -iworks. - Only now change the setting.
ssh artem@<address>
sudo whoami
If the second command returned root, you have a fallback.
Configuration options
In the file /etc/ssh/sshd_config.d/99-hardening.conf:
| Value | What it means |
|---|---|
PermitRootLogin yes | Everything is allowed, including the password. Nobody leaves it like this |
PermitRootLogin prohibit-password | The key works, the password is rejected. A sensible minimum |
PermitRootLogin forced-commands-only | Only pre-defined commands, for automation |
PermitRootLogin no | Root cannot log in over SSH at all. The strictest option |
Recommended combination:
PermitRootLogin prohibit-password
PasswordAuthentication no
The second parameter closes password login for all users at once, not just root. For more details, see SSH hardening.
Apply and verify
sudo sshd -t
sudo systemctl restart ssh
sudo sshd -T | grep -i permitrootlogin
From another window, check that root no longer accepts a password and that your user logs in with the key:
ssh root@<address>
ssh artem@<address>
Restarting sshd does not drop the current session — keep it open until you finish checking.
What stays available
The change affects SSH only. The root password is still needed and still works:
- in the machine console, both tabs — the text one and “Screen”;
- when logging in via the recovery disk;
- for the
su -command inside the system.
The password itself is stored encrypted and is revealed by a button on the “Access” tab of the panel at /hosting/vds/m/<id>. This is your emergency path, and you should not lose it — see backup keys and passwords.
Common mistakes
| Mistake | Consequence | Solution |
|---|---|---|
| You disabled root but never created a user with sudo | Nobody can manage the machine | Use the panel console and create a user |
| The key exists only for root | The new user cannot log in | Copy authorized_keys and fix the permissions |
| The setting is overridden by another file | The rule has no effect | Check sshd -T, not the file |
| Expecting the ban to apply to the console | A false sense of complete lockdown | The console always works, by design |
Never disable root login without verifying the alternative login in a neighboring window. The check takes ten seconds; recovery through the console takes far longer.