Direct root login is the account every attacker tries first, and it leaves no record of who did what. Disabling it means two things: block root over SSH with PermitRootLogin no in sshd_config, and lock the root password with passwd -l root so console and su access close too. You then log in as a normal user and elevate with sudo. Before you disable root, make sure you have a working sudo-capable account, or you will lock yourself out.
Step 0: confirm you have a way back in
Before disabling root login, confirm a normal account can become root. Run sudo whoami as that user:
# As your normal user, prove sudo works BEFORE disabling root:
sudo whoami # should print: rootIf that prints root, you are safe to proceed. If it does not, grant sudo first and re-test.
Disable root login over SSH
This is the one that matters most, because SSH is the internet-facing door. In /etc/ssh/sshd_config (or a drop-in under /etc/ssh/sshd_config.d/):
PermitRootLogin no
Check and reload without dropping your session:
sudo sshd -t # validate config
sudo systemctl reload ssh # or: reload sshdKeep your current session open and confirm a fresh ssh youruser@server still works before closing it. (On Debian and Ubuntu the service unit is ssh; on RHEL and Fedora it is sshd.) PermitRootLogin takes four values: no blocks root entirely, prohibit-password blocks root password logins but still allows a root SSH key (useful for some automation), forced-commands-only allows a root key only to run a pre-set command, and yes is the permissive setting you are removing.
Lock the root password (console too)
Disabling SSH root login does not touch console or su access. To stop anyone from su - into root with a password, lock the root password:
sudo passwd -l rootThis puts a ! in the hash so no password matches. You still become root through sudo (which does not use the root password), so your day-to-day workflow keeps working. To check: sudo passwd -S root shows L.
There is one real caveat, and it is the one people get bitten by. Locking the root password changes how emergency recovery behaves. If the box later fails to boot and drops into rescue or emergency mode, systemd runs sulogin, which asks for the root password, and a locked password makes it refuse outright:
Cannot open access to console, the root account is locked.
See sulogin(8) man page for more details.
You are not stuck, but you have to plan the way back in before you need it. Either keep a recovery path that does not go through sulogin (interrupt the bootloader and boot with init=/bin/bash, or rd.break, or a rescue ISO), or tell systemd to hand out a passwordless rescue shell:
sudo systemctl edit rescue.service # add under [Service]:
# Environment=SYSTEMD_SULOGIN_FORCE=1
sudo systemctl edit emergency.service # same lineFor a one-off you can pass it on the kernel command line instead: add systemd.setenv=SYSTEMD_SULOGIN_FORCE=1 (with rescue) at the bootloader. That option trades the lockout for a passwordless root shell at the physical console, so only set it on machines whose console is physically protected.
What you do NOT want
Do not delete the root account or set its shell to nologin blindly: many system tools and recovery paths expect root to exist. Locking the password and disabling SSH root login achieves the security goal while keeping the account intact for sudo. Just remember the recovery caveat above: a locked root password also locks the default sulogin rescue prompt, so set up an alternative recovery path (or SYSTEMD_SULOGIN_FORCE=1) before you rely on it.
FAQ
Only if you have no other way to become root. Before disabling it, confirm a normal account can sudo whoami and get root. Keep your current session open while you reload sshd and test a fresh login. With a working sudo account, you are safe.
no blocks all root logins over SSH. prohibit-password blocks root password logins but still allows root via an SSH key, which some automation needs. For most servers, no plus a sudo-capable user is the right choice.
Yes, with sudo passwd -l root. Disabling SSH root login does not stop console or su access with the root password. Locking the password closes those while leaving the account usable through sudo, which does not rely on the root password.
It changes it, and this is the part people miss. If the system drops into rescue or emergency mode, systemd runs sulogin, which asks for the root password, and a locked password makes it refuse with Cannot open access to console, the root account is locked.
You can still recover. Pick one of these before you lock the password, not during an outage:
- Interrupt the bootloader and boot with
init=/bin/bashorrd.break. - Boot from a rescue ISO.
- Set
SYSTEMD_SULOGIN_FORCE=1onrescue.serviceandemergency.serviceso systemd hands out a passwordless root shell at the console. Only do this on machines whose console is physically protected.
That is PAM's pam_access rule file, and it is a good complementary control. It restricts which accounts may log in and from where (tty, host, network), independent of the SSH config or the password lock.
Disabling SSH root login plus locking the password covers the common case. Reach for access.conf when you want finer rules, like allowing a given account only from the console or a specific subnet.
Skip it on a modern system. /etc/securetty and pam_securetty were the old way to limit root to specific terminals, but the model is largely obsolete: Red Hat disabled securetty by default in RHEL 8, and on current Debian and Ubuntu the file is usually absent (you will see Couldn't open /etc/securetty if something still references it). Use PermitRootLogin no for SSH, lock the password to close console and su, and reach for access.conf if you need per-tty rules.
See also
- How to give a user sudo access: set up the account that replaces root login. Do this first.
- Harden sshd: disable password authentication: the other half of locking down SSH.
- Lock and unlock a user account: the passwd -l mechanics.
- Run a command as another user (sudo -u): elevate deliberately instead of living as root.
- encrypt the disk with LUKS: protect the data at rest, not just the login.
- block rogue USB with USBGuard: another physical-access defense.
Sources
Authoritative references this article was fact-checked against.
