Use a sudo user instead of root

Logging in as root means every typo runs with full power and every bot on the internet knows your username. A normal user with sudo fixes both. The order you do it in is what keeps you from locking yourself out.

Published 30 October 2026. Ubuntu 22.04 and later and Debian 12 and later, with OpenSSH server and the sudo package.

• Why not just use root
• Create the user and give it sudo
• Copy your SSH key
• Test it in a second session
• Turn off root logins
• Sudo without a password: the tradeoff
• Edit sudo rules with visudo

Why not just use root

Every SSH scanner tries root first, because it exists on every Linux server. A login name like maria has to be guessed as well. And with sudo, you only get full power when you ask for it, one command at a time, with a log of what ran.

The plan is simple: create the user, give it sudo, give it your SSH key, prove it works, and only then turn off root logins.

Create the user and give it sudo

As root on the server:

adduser maria

adduser asks for a password and creates /home/maria. Set a real password even if you'll log in with a key: it's what sudo asks for.

Then add the user to the sudo group. On Ubuntu and Debian, members of that group can run any command with sudo:

usermod -aG sudo maria

The -a matters. Without it, -G replaces the user's supplementary groups and removes them from every group you didn't list. The Debian way, adduser maria sudo, does the same thing as usermod -aG.

On a minimal Debian install where you set a root password, sudo may not be installed. Add it with apt install sudo first.

Copy your SSH key

If root logs in with a key, the simplest move is to copy root's authorized_keys to the new user, with the right owner and permissions:

install -d -m 700 -o maria -g maria /home/maria/.ssh
install -m 600 -o maria -g maria /root/.ssh/authorized_keys /home/maria/.ssh/authorized_keys

Check the file first. If other people's keys are in root's file, they get access to maria too. Remove any line that isn't yours.

If password logins are still on, you can instead run this from your own computer:

ssh-copy-id [email protected]

Either way, the .ssh folder and authorized_keys must not be writable by anyone but the user, or sshd can ignore them.

Test it in a second session

Keep your root session open. In a new terminal window:

ssh [email protected]
sudo whoami

sudo asks for maria's password and prints root. If it says the user is not in the sudoers file, the group change didn't take: group membership is read at login, so log out and in again, or recheck the usermod command.

Only move on when both work: the key login and sudo.

Turn off root logins

The OpenSSH default for PermitRootLogin is prohibit-password: root can't log in with a password but can still log in with a key. Set it to no to block root over SSH entirely. On Ubuntu and Debian, put it in a file under /etc/ssh/sshd_config.d/. Those files are included at the top of sshd_config, and OpenSSH uses the first value it finds, so they win over the main file:

echo 'PermitRootLogin no' | sudo tee /etc/ssh/sshd_config.d/10-no-root.conf
sudo sshd -t
sudo systemctl restart ssh

sshd -t checks the config and prints nothing if it's valid. Don't restart if it prints an error. Restarting the service doesn't drop sessions that are already open.

Sudo without a password: the tradeoff

You can let a user run sudo without typing a password. The Debian wiki calls this usually a bad idea: anyone who gets into that account, with a stolen key or through a hole in an app running as that user, becomes root right away. The password is a second lock behind the SSH key.

It does have a place for automation, such as a deploy account that runs one or two commands. In that case, limit it to those commands instead of ALL:

deploy ALL=(root) NOPASSWD: /usr/bin/systemctl restart myapp

For your own account, keep the password. sudo remembers it for 15 minutes by default, so you don't type it for every command.

Edit sudo rules with visudo

A syntax error in a sudoers file can break sudo for everyone. If root logins are already off, that can leave you without a way to fix it. visudo checks the syntax before it saves and, on an error, asks what to do: e to edit again, x to exit without saving. Avoid Q, which saves the broken file.

Put your own rules in a separate file under /etc/sudoers.d/ instead of the main file. The Debian wiki recommends this so package updates don't overwrite your changes:

sudo visudo -f /etc/sudoers.d/deploy

Use a file name without a dot or a trailing ~: sudo skips those files, so deploy.conf would be silently ignored. To check every file at once:

sudo visudo -c

Sources

1. Debian Wiki: sudo
2. Ubuntu manpage: usermod(8)
3. Ubuntu manpage: visudo(8)
4. Ubuntu Server docs: OpenSSH server
5. OpenBSD manual: sshd_config(5) (PermitRootLogin)