PermitRootLogin

What PermitRootLogin accepts and its default

The sshd_config manual says the argument must be yes, prohibit-password, forced-commands-only or no, and that the default is prohibit-password. The older spelling without-password is listed there as a deprecated alias. A distribution or hosting image can ship a config file that sets another value, so the built-in default is not always what runs on your server.

• yes: root may authenticate with any enabled method, including a password.
• prohibit-password: password and keyboard-interactive login are disabled for root. In the OpenSSH source (auth_root_allowed in auth.c) only publickey, hostbased and gssapi-with-mic remain.
• forced-commands-only: a public key works only if its entry carries a command option; all other methods are disabled for root.
• no: root is refused whatever credentials are presented.

The directive governs logins through sshd only. It does not delete or lock the account, and su, sudo and your provider's console are not affected.

A minimal safe configuration and how to test it

Set the value in the file that actually wins (see the next section), and keep your current session open until a brand-new one has succeeded. First make sure a named administrator with sudo already works in another terminal. Then:

# /etc/ssh/sshd_config
PermitRootLogin no

sudo sshd -t
sudo sshd -T | grep -i '^permitrootlogin '
sudo systemctl reload ssh     # the unit is called sshd on some distributions
ssh -l root your-server       # from a second terminal: must be refused

Per the sshd(8) manual, -t checks the validity of the configuration file and -T prints the effective configuration. If you use Match blocks, add a connection specification such as -C user=root,addr=192.0.2.10,host=server so that matching blocks are applied before printing. If sshd -T still shows the old value, an earlier line or an included file is winning; fix that before reloading. Keep the provider console or rescue mode within reach in case the administrator account turns out to be broken.

Interactions and common mistakes

Per the manual, for each keyword the first obtained value is used. A PermitRootLogin line placed below an Include that already sets it, or below an earlier duplicate, is ignored. The directive is also allowed inside a Match block, and if several satisfied blocks set it, only the first instance applies. Read how this works in the sshd_config entry.

User lists are a separate gate. In the OpenSSH source, the checks behind AllowUsers and DenyUsers run independently of auth_root_allowed, so root must pass both. A refusal by this directive is logged as "ROOT LOGIN REFUSED FROM" followed by the address and port, which is a handy line to search for. With forced-commands-only, the command option lives in the key's entry in root's authorized_keys, so a plain key there does not let root in.

The most common mistake is assuming the default equals no. With prohibit-password, any key left in root's authorized_keys is still a working way in.

Where it fits in SSH hardening

Turning root login off removes the one account name that every automated scanner is guaranteed to try, and it forces each administrative action through a named account and sudo, which leaves a record of who did what. It is one layer, not a complete defence. Pair it with PasswordAuthentication set to no, a cap on guesses with MaxAuthTries, and an allow-list.

The step-by-step order is in our SSH hardening guide. Keep the sudo rules of the replacement account narrow, as described in users, sudo and least privilege, and add a second factor with the SSH two-factor guide. For the wider picture, see the root login entry and the primary sources: the sshd_config manual and the OpenSSH auth.c source.

Related terms: Root login, sshd_config, sudoers, Least privilege, AllowUsers.