Quick wins for a faster PC:
Repair Windows errors before they cause bigger problemsFix Now →Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →Clear out junk files and repair common Windows errorsFree Scan →iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Need a server to try this on? Antihost offers Linux VPS plans with NVMe storage, full root access and a 14-day free trial.
For routine administration, do not SSH directly as root. Create a named account, authenticate it with an SSH public key, grant only the sudo privileges it needs, test that account in a second session, and then set PermitRootLogin no. Root-level work remains available through sudo after login; disabling root SSH does not disable sudo or su.
The sequence matters. Keep your original provider or root session open until the new account has successfully logged in and elevated privileges. Changing the SSH policy first is how administrators lock themselves out.
Recommended Free Tools
Why direct root SSH is a poor default
The root account can change or delete virtually anything on the server: system files, user accounts, services, firewall rules, logs and data. A direct root login therefore combines authentication and unrestricted authority in one account. It is also a predictable username, so every exposed SSH service presents the same high-value target.
A named account separates identity from privilege. The SSH log records which administrator connected, while sudo records and controls individual administrative actions. If an account is compromised, its effective rights can be limited, its key can be removed without changing other administrators’ access, and the account can be disabled independently.
#1 Best Overall
This is a risk-reduction design, not a guarantee of security. A user with unrestricted sudo can still become root, so key protection, patching, least-privilege sudo rules, network controls and monitoring remain important. The benefit is that routine sessions do not begin with the most powerful identity and that access can be attributed to a person or service account.
What PermitRootLogin actually controls
PermitRootLogin is an OpenSSH server setting. It controls whether the root account may authenticate through SSH; it does not control whether root exists locally or whether an already authenticated user may use sudo or su. OpenSSH’s manual states that when the option is set to no, root is not allowed to log in.
Outdated Drivers Are Slowing You Down
One free scan finds every outdated or missing driver and matches the right update for your exact hardware.Free scan · exact hardware matchWindows Errors? Fix Them Before They Spread
Repair common Windows errors and clear accumulated junk for a smoother, more stable PC - no reinstall needed.Free scan · no reinstall| Setting | Root SSH behavior | Appropriate use |
|---|---|---|
no |
Rejects root authentication through SSH, including interactive sessions and file-transfer logins made as root. | Normal administration on a VPS after a tested named account is ready. |
prohibit-password |
Rejects root password and keyboard-interactive authentication but may still permit root public-key authentication. | A transitional or automation policy when a narrowly controlled root key is genuinely required. It is not equivalent to disabling root SSH. |
forced-commands-only |
Allows root public-key authentication only when the key specifies a forced command. Interactive root sessions are not allowed. | Tightly constrained automation such as a backup key that must run one server-side command. |
yes |
Allows root SSH according to the other authentication rules. | Generally unsuitable for routine Internet-facing administration. |
Defaults are distribution-dependent. Debian’s current sshd_config manual documents prohibit-password as its default, which can still allow root public-key login. Ubuntu documents that the administrative root account is disabled by default. Do not assume a tutorial’s default applies to your image; inspect the effective configuration on the target VPS.
Password, keyboard-interactive and key authentication are different
Disabling a root password does not remove a public key from /root/.ssh/authorized_keys. Likewise, a policy that blocks password authentication can still permit a previously installed root key. Check both the account’s authentication state and the SSH daemon’s effective policy.
What happens when you set PermitRootLogin no
- New SSH authentication attempts for the root account fail.
- Root access through SSH, SCP and SFTP is blocked because each uses the SSH daemon.
- An administrator who logs in as a permitted user can still run
sudo command, open a root shell withsudo -i, or usesuwhen the local policy allows it. - Provider recovery consoles, serial consoles and out-of-band rescue environments are separate access paths and may still provide recovery, subject to the provider’s controls.
- Existing SSH sessions are not normally terminated by changing the setting and reloading the daemon. Keep one open while testing the replacement account.
Disabling root SSH is therefore not the same as disabling the root account. It changes the remote entry path while preserving an administrative escalation path for an already authenticated operator.
Safer setup: Ubuntu Server 22.04 or 24.04 example
The commands below target a Debian-family Ubuntu Server image using the standard sudo group and the ssh systemd service. Confirm your release with cat /etc/os-release. RHEL-family images commonly use the wheel group and may name the service sshd; use that distribution’s documented group, service and configuration paths instead of copying these commands blindly.
1. Keep a recovery channel open
Connect through the provider console or your current root SSH session and leave it open. Do not close it, reboot, or replace its terminal until a separate terminal has completed every test below. A provider recovery console is especially valuable if a syntax error prevents the SSH daemon from reloading.
2. Create an individual administrative account
Choose a unique account name that identifies its owner or purpose. In the root session, run:
adduser --disabled-password --gecos '' vpsadmin
usermod -aG sudo vpsadminThe first command creates the account without setting a password. The second grants membership in Ubuntu’s administrative sudo group. If your organization requires a password as a second factor or for console recovery, set one according to its policy rather than assuming a disabled password is appropriate.
3. Generate or select a key on your workstation
Use a separate key for this VPS or account so it can be revoked without affecting unrelated systems. An Ed25519 key is a common current choice:
ssh-keygen -t ed25519 -f ~/.ssh/vps_admin_ed25519Protect the private key with a strong passphrase and keep it off the server. The file ending in .pub is the public key that belongs in the account’s authorized_keys file. Never paste the private-key file into a server or ticket.
4. Install the public key for the named account
While still connected through the trusted root or provider session, create the directory and edit the account’s key file:
Rank #3
install -d -m 700 -o vpsadmin -g vpsadmin /home/vpsadmin/.ssh
sudoedit /home/vpsadmin/.ssh/authorized_keys
chown vpsadmin:vpsadmin /home/vpsadmin/.ssh/authorized_keys
chmod 600 /home/vpsadmin/.ssh/authorized_keysPaste the complete single-line public key from your workstation into the editor, save it, and ensure there are no accidental line breaks or extra characters. If the home directory was created somewhere other than /home/vpsadmin, use the path shown by getent passwd vpsadmin.
SSH also checks ownership and permissions above the key file. The account’s home directory should not be writable by unrelated users, the .ssh directory should be mode 700, and authorized_keys should be mode 600 and owned by the account.
5. Test key login in a second terminal
Open a new terminal; do not reuse the root connection. Connect with the new identity:
ssh -i ~/.ssh/vps_admin_ed25519 vpsadmin@VPS_IPReplace VPS_IP with the server address in your local command; do not change the server’s configuration based on the example text. After login, verify the account and sudo path:
id
sudo -v
sudo id -uThe first command should show vpsadmin as the user. sudo -v validates the sudo policy and may ask for the account password if one is configured. The final command should print 0, proving that this account can perform a root-level operation. If you intend to use a restricted sudo policy, test every command the operator actually needs rather than granting full access by habit.
6. Inspect and validate the effective SSH configuration
Edit the daemon configuration in the root session:
sudoedit /etc/ssh/sshd_configAdd or change an uncommented line to:
PermitRootLogin noUbuntu images can also load files from /etc/ssh/sshd_config.d/. Look for another active PermitRootLogin directive there, because a drop-in or an earlier setting can affect the result. Validate syntax before reloading:
Rank #4
- Made in USA - Proudly produced in Ohio by a Veteran-owned business
- This BookFactory log book is for security guards in any sector or business. You can report location, circumstances and report number.
- There are spaces to log the individual's names address, description and other identifying information. There are also spaces to note others involved, notes, and vehicle information if one was involved
- Wire-O, 100 Pages, Dimensions 3.5" x 5.25"
- Reorder SKU: LOG-100-M3CW-PP(Security-Report)
sudo sshd -t
sudo sshd -T | grep '^permitrootlogin'The first command should return no output and status 0. The second displays the daemon’s effective value; confirm it reports permitrootlogin no. If validation reports an error, fix it while the recovery session is open and do not reload the service.
7. Reload SSH, then test again
On Ubuntu, reload the service without needlessly terminating existing connections:
sudo systemctl reload sshFrom the second terminal, open another fresh connection as vpsadmin and repeat sudo -v and sudo id -u. Only after those tests succeed should you test that root SSH is rejected:
Free tools Windows power users keep installed
One-click scans. No signup required.
ssh -i ~/.ssh/vps_admin_ed25519 root@VPS_IPThe root attempt should fail authentication. Keep the named-account session and provider recovery path available; a failed root test is expected, while a failed named-user test indicates a configuration or key problem that must be corrected before closing the original session.
Choosing the right root-login policy
| Policy choice | Security posture | Operational consequence | Use when |
|---|---|---|---|
Named user plus PermitRootLogin no |
Best separation of identity and privilege; no direct root SSH target. | Administrators log in with their own keys and elevate with sudo. | Routine human administration. |
Root with prohibit-password |
Password and keyboard-interactive root access are blocked, but root keys may work. | Any installed root key remains an SSH entry path. | Only when a documented automation or recovery requirement exists and keys are tightly controlled. |
Root with forced-commands-only |
Restricts a root key to a forced server-side command. | The key cannot provide an interactive root shell, but a command design error can still be serious. | Constrained jobs such as backups, with separate keys and a reviewed forced command. |
Root with yes |
Leaves the most powerful account exposed to SSH authentication attempts. | Simple initial access but weak identity separation and greater blast radius. | Temporary provider recovery only, not a routine policy. |
If an automated job truly needs root, prefer a dedicated key with a forced command, source restrictions and a documented rotation or revocation process. Do not retain unrestricted interactive root keys merely because an old script happens to use root.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Least privilege after the SSH change
Membership in Ubuntu’s sudo group commonly grants broad administrative power. That is safer than direct root SSH for accountability and access control, but it is not least privilege in the strict sense. For an operator who needs only a few tasks, create a sudoers rule for specific commands and validate it with visudo. Avoid editing /etc/sudoers with a normal text editor; a syntax error can remove the only escalation path.
Best Value
- Made in USA - Proudly produced in Ohio by a Veteran-owned business
- Comprehensive Coverage: This BookFactory log book includes essential fields such as post/shift, time of change, date, weather conditions, and a designated space for detailed notes. This ensures that all relevant information is captured and easily accessible.
- Sturdy Cover: The trans-lux cover protects the log book from wear and tear, ensuring its longevity and maintaining the integrity of your recorded data.
- Essential Security Tool: This log book is an indispensable tool for any organization that values security and accountability. It helps to prevent misunderstandings, improve communication, and ensure a smooth transition between shifts.
- Wire-O with Trans-lux cover, 100 Pages, Dimensions 8.5" x 11" - (Security-Pass-Down) Reorder SKU: LOG-100-7CW-PP(Security-Pass-Down)
Separate human accounts rather than sharing one administrator login. Remove a departing user’s key from that user’s authorized_keys, disable the account when appropriate, and preserve another tested administrator path before making changes. Service accounts should normally have no interactive shell and should not reuse a human’s private key.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Common lockout causes and recovery
The new account cannot authenticate
- Confirm the username, server address and private-key path in the client command.
- Check that the public key is one uninterrupted line in the correct user’s
authorized_keys. - Verify ownership and modes with
namei -l /home/vpsadmin/.ssh/authorized_keys. - Inspect the SSH authentication log through the provider console. The exact log location varies by distribution.
- Check that an SSH
AllowUsers,AllowGroupsor firewall rule is not excluding the account.
Sudo fails after login
Confirm that the account is in the intended administrative group and start a new login session so group membership is refreshed. Run id and inspect the sudo policy. If sudo requires a password, use the account password or change the policy deliberately; do not work around the failure by reopening root SSH.
Reload fails or SSH stops accepting connections
Use the still-open root or provider console session. Run sshd -t to identify syntax errors, restore the last known-good configuration, and restart or reload the service using the distribution’s documented service name. A rescue console is the recovery path if the daemon cannot start or the network firewall also changed.
Root login still works
Inspect the effective value with sshd -T, not just the line you edited. A drop-in file, a Match block, or a different SSH daemon instance may be supplying another value. Also confirm that you are testing a new connection: an existing root session can remain open after the policy is changed.
Operational checklist
- Keep a provider or root recovery session open.
- Create a named account for each administrator or automation role.
- Install a public key on that account and verify ownership and permissions.
- Log in from a second terminal using the corresponding private key.
- Confirm the required sudo commands and that
sudo id -ureturns0. - Inspect the effective SSH configuration and validate it with
sshd -t. - Set
PermitRootLogin noand reload the daemon only after validation. - Open another fresh named-user session, then confirm a root SSH attempt is rejected.
- Document the provider console, administrator accounts, key owners and emergency recovery procedure.
- Rotate or revoke keys and remove obsolete root keys instead of leaving dormant access paths.
Bottom line
Use SSH as an individual, key-authenticated non-root account and elevate with sudo. After that account works in a separate session and you have a tested recovery channel, set PermitRootLogin no. This blocks root authentication through SSH while preserving root-level administration after login, giving you better accountability and a smaller, more controllable remote attack surface.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
