How to Create a Sudo User and Disable Root SSH Login

Every automated attack on a Linux server starts by trying root. If root cannot log in over SSH at all, that whole class of attack fails before it begins — and with a personal account plus sudo, you lose nothing. Ten minutes, and the one rule is: do not close your working session until the new login is proven.

1. Create the user

adduser deploy

Choose any name; deploy, admin and your own first name are all common. adduser asks for a password and creates a home directory. On AlmaLinux/Rocky, adduser is an alias for useradd and does not prompt, so set the password separately:

useradd -m deploy
passwd deploy

2. Give it sudo

On Ubuntu and Debian the group is sudo; on AlmaLinux, Rocky and Fedora it is wheel:

usermod -aG sudo deploy      # Ubuntu / Debian
usermod -aG wheel deploy     # AlmaLinux / Rocky

Confirm the membership took:

id deploy
# uid=1001(deploy) gid=1001(deploy) groups=1001(deploy),27(sudo)

3. Test it — in a second terminal

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

ssh deploy@203.0.113.10
sudo whoami
# root

If that prints root, the account works. If it asks for a password and refuses, the group was not applied — log out of the deploy session and back in, because group changes only take effect on a new login.

4. Move your SSH key across

If you already log in as root with a key, copy it so deploy uses the same one:

mkdir -p /home/deploy/.ssh
cp /root/.ssh/authorized_keys /home/deploy/.ssh/
chown -R deploy:deploy /home/deploy/.ssh
chmod 700 /home/deploy/.ssh
chmod 600 /home/deploy/.ssh/authorized_keys

Or from your own machine, add it fresh:

ssh-copy-id deploy@203.0.113.10

Test the key login in that second terminal again before continuing. Setting up keys from scratch, and turning off passwords entirely, is in SSH keys and disabling password login.

5. Disable root over SSH

Edit the SSH server config:

sudo nano /etc/ssh/sshd_config

Find the line and set it:

PermitRootLogin no

On recent Ubuntu, a file in /etc/ssh/sshd_config.d/ can override this; check that nothing there sets it back to yes:

grep -r PermitRootLogin /etc/ssh/sshd_config.d/ 2>/dev/null

Validate the config before restarting — a typo here locks everyone out:

sudo sshd -t && sudo systemctl restart ssh    # 'sshd' on AlmaLinux / Rocky

6. Prove root is locked out

From your machine:

ssh root@203.0.113.10
# Permission denied (publickey).

Good. Only now close the original root session.

Optional: no password for sudo

Convenient on a server only you use, and safe if the account is key-only:

echo 'deploy ALL=(ALL) NOPASSWD:ALL' | sudo tee /etc/sudoers.d/deploy
sudo chmod 440 /etc/sudoers.d/deploy

Always use sudoers.d or visudo, never edit /etc/sudoers with a plain editor — visudo refuses to save a broken file, which is the difference between a typo and a locked server.

Recovering if you do lock yourself out

Every VPS provider has a console — a screen attached to the virtual machine that works regardless of SSH or the network. Log in there as root with the password, fix sshd_config, restart the service. On a VPSPioneer managed VPS you can also just open a ticket and we do it.

Why this matters more than a strong root password

A strong password protects against guessing; it does not protect against a leaked password, a keylogger on a laptop, or the next OpenSSH vulnerability that turns out to affect only root logins. Removing root from SSH removes the target. Combined with keys and Fail2ban, the log file that used to show ten thousand failed logins a day shows none.