How to Disable Root Login on Linux

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: root

If 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 sshd

Keep 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 root

This 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 line

For 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

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.