I'm hardening a Linux server and keep seeing advice to disable direct SSH login for root. If root authentication is restricted to SSH keys, how much safer is it to use a named account with sudo instead? The alternative account name may also be predictable, and I need passwordless sudo for some automation. Is the main benefit simply reducing brute-force attempts, or are auditability, limiting privileges, and defense in depth more important?
4 Answers
Key-only root SSH is not automatically unsafe if access is limited to a protected management network and the key is carefully secured. It can be useful for tightly controlled tools such as provisioning or backups. For people, though, a named account is generally preferable because it provides an audit trail and lets you apply different permissions to different administrators. Keep root SSH disabled unless there is a specific operational reason to permit it.
The biggest advantage of using a named account is accountability. SSH and sudo logs can show which person or automation account connected and which commands were run. If everyone connects directly as root, the logs only show that root did something, which makes investigations and separation of duties much harder. Disabling root SSH also removes a known username from the login surface, but that is a secondary benefit rather than the main reason.
The usual recommendation is defense in depth: disable direct root login, disable password authentication for SSH, use unique named accounts, and restrict SSH through a firewall, VPN, jump host, or other trusted network where feasible. Enable reliable centralized logging and auditing as well. Changing the SSH port may reduce scanner noise, but it does not provide meaningful security by itself. Also remember that anyone with unrestricted sudo can usually become root, so the distinction is about control and traceability, not an absolute security boundary.
For human administration, use a normal account with SSH keys and require a password or another authentication factor for sudo when possible. You can restrict sudo to specific commands or use tightly scoped automation accounts for jobs that genuinely need passwordless elevation. Passwordless sudo effectively means that compromising that account may lead to full system compromise, so treat it as a high-privilege credential rather than a regular user.
Automation is the usual exception. A dedicated account with a command-restricted sudo rule, a separate key, and access limited to a management network is much safer than giving a general-purpose user unrestricted passwordless sudo.