How to Create a Non-Root Sudo User on Linux VPS

Start with root, then move to a safer login

Focus keyword: create a non-root sudo user. On a fresh VPS, the first hardening step is not a firewall tweak or a package upgrade. It is creating a named administrator account, testing it, and then reducing root exposure.

If you are launching a new site, a client VPS, or a staging box, this is where access becomes easier to manage. A named user with sudo access gives you a cleaner audit trail, simpler handoffs, and fewer lockout risks than daily root logins. If you are sizing a new server for production, Hostperl VPS hosting is a sensible starting point for this workflow.

First, connect as root from your local computer.

ssh root@203.0.113.10

203.0.113.10 is a reserved documentation example. Replace it with the real public IP assigned to your server. If your host provides a custom SSH port, use ssh -p 2222 root@203.0.113.10 instead.

Check the operating system before you change anything

On the VPS as root: identify the distro first so you use the correct package manager, group name, and firewall service.

cat /etc/os-release

You should see either Ubuntu/Debian or AlmaLinux/Rocky Linux. The commands below are split accordingly. Do not mix them.

Create the non-root sudo user on Ubuntu or Debian

On the VPS as root: create a login account named deploy, add it to the sudo group, and set up SSH access.

adduser deploy

This creates the home directory and prompts for a password. If you plan to use SSH keys only, the password can be temporary. Next, grant sudo rights.

usermod -aG sudo deploy

Now prepare the SSH directory and permissions.

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

Paste your public key into /home/deploy/.ssh/authorized_keys. If you already have the key on your local computer, you can append it with ssh-copy-id from a second terminal:

ssh-copy-id deploy@203.0.113.10

This copies your key to the new user. Enter the temporary password you set for deploy. You can also copy the key manually if you want full control over the file contents.

Open a second terminal and test the new login before closing root.

ssh deploy@203.0.113.10

Once logged in, confirm sudo works.

sudo whoami

The expected output is root. If that works, keep this session open and continue with patching and basic hardening.

Create the non-root sudo user on AlmaLinux or Rocky Linux

On the VPS as root: the flow is similar, but the administrative group is wheel and the package manager is dnf.

useradd -m -s /bin/bash deploy
passwd deploy
usermod -aG wheel deploy

Set the SSH directory and permissions exactly as below.

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

Then copy your public key from the local computer using a second terminal.

ssh-copy-id deploy@203.0.113.10

If ssh-copy-id is unavailable, paste the public key into /home/deploy/.ssh/authorized_keys manually. Test login in a new terminal and confirm sudo access with sudo whoami. The command should return root.

Update packages and set the server clock

On the VPS as the non-root sudo user: run package updates before you change SSH rules or services. This lowers the chance that you are hardening an already vulnerable system.

Ubuntu and Debian:

sudo apt update
sudo apt -y upgrade

AlmaLinux and Rocky Linux:

sudo dnf -y update

Next, make sure time sync is active. Correct time matters for SSH keys, logs, TLS certificates, and backups.

On Ubuntu and Debian:

timedatectl status
sudo timedatectl set-ntp true

On AlmaLinux and Rocky Linux:

timedatectl status
sudo systemctl enable --now chronyd

Check that the clock is synchronized. You should see NTP enabled or a synchronized state.

Lock down SSH without locking yourself out

On the VPS as the non-root sudo user: keep the root session open while you make changes. Add the new access path first, test it, and only then reduce old access.

Open the SSH daemon config file.

sudo nano /etc/ssh/sshd_config

Use these settings if they are not already present. Keep the file content simple and explicit.

PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes
AllowUsers deploy

Save and exit the editor. Before restarting SSH, test the configuration syntax.

sudo sshd -t

No output means the config is valid. Now reload the service, not a full restart, so active sessions are less likely to drop.

sudo systemctl reload sshd

On Ubuntu and Debian, the service is usually called ssh. If sshd reload fails, try:

sudo systemctl reload ssh

Open a fresh terminal and confirm password login is disabled while key login still works:

ssh deploy@203.0.113.10

When you are confident the new login works, you can close the root session. Do not do this earlier.

Open only the ports you actually need

On the VPS as the non-root sudo user: your firewall should allow SSH before you enable it. If you are using a web stack later, add HTTP and HTTPS as well.

Ubuntu and Debian with UFW:

sudo apt -y install ufw
sudo ufw allow OpenSSH
sudo ufw enable
sudo ufw status verbose

If you also plan to serve websites, add the web rules now:

sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw status numbered

AlmaLinux and Rocky Linux with firewalld:

sudo dnf -y install firewalld
sudo systemctl enable --now firewalld
sudo firewall-cmd --permanent --add-service=ssh
sudo firewall-cmd --permanent --add-service=http
sudo firewall-cmd --permanent --add-service=https
sudo firewall-cmd --reload
sudo firewall-cmd --list-all

On SELinux-enabled systems, keep the default SSH policy in place. Do not disable SELinux just to make a firewall rule work.

Add Fail2Ban for noisy login attempts

Fail2Ban is useful on exposed SSH services. It watches logs and blocks repeated failures. That helps on small VPS plans where every attack attempt matters.

Ubuntu and Debian:

sudo apt -y install fail2ban
sudo systemctl enable --now fail2ban
sudo systemctl status fail2ban --no-pager

AlmaLinux and Rocky Linux:

sudo dnf -y install epel-release
sudo dnf -y install fail2ban
sudo systemctl enable --now fail2ban
sudo systemctl status fail2ban --no-pager

Create a minimal jail override for SSH.

sudo nano /etc/fail2ban/jail.d/sshd.local

Use this content:

[sshd]
enabled = true
maxretry = 5
findtime = 10m
bantime = 1h

Save and exit, then validate the service by checking the jail status.

sudo fail2ban-client status sshd

You should see the SSH jail enabled. If not, check the syntax of the file and the system journal.

Check logs, service state, and open ports

On the VPS as the non-root sudo user: verify the server is in the state you expect.

systemctl status sshd --no-pager
ss -tulpn | grep -E ':22\b'
journalctl -u sshd -n 50 --no-pager

On Ubuntu and Debian, use ssh instead of sshd if that is the installed unit name.

If you enabled a firewall, confirm the SSH port is reachable from your client. A simple smoke test from your local computer is:

ssh -v deploy@203.0.113.10

The verbose output should show key-based authentication and a successful shell prompt.

Reboot once to confirm persistence

Many hosts look fine until the first reboot. That is when bad firewall rules, broken SSH hardening, or missing service enablement shows up.

On the VPS as the non-root sudo user:

sudo reboot

Wait one or two minutes, then reconnect from your local computer as deploy and confirm the expected services came back.

ssh deploy@203.0.113.10
sudo systemctl status fail2ban --no-pager
sudo ufw status verbose

On AlmaLinux and Rocky Linux, use sudo firewall-cmd --list-all instead of UFW.

Common problems and the fastest way to diagnose them

SSH login fails after hardening: run sudo sshd -t on the server console. If it reports an error, fix the config file and reload SSH. If the config is valid, check journalctl -u sshd -n 50 --no-pager for permission or authentication clues.

The deploy user cannot use sudo: run groups deploy. On Ubuntu and Debian, sudo must appear. On AlmaLinux and Rocky Linux, wheel must appear. If not, rerun the correct usermod -aG command and log out and back in.

Firewall blocks port 22: check sudo ufw status verbose or sudo firewall-cmd --list-all. Add the SSH rule before removing any old rule, then test from a second terminal before proceeding.

Useful follow-up reading

If you want to keep hardening the same server, these guides fit naturally after this tutorial:

• Initial VPS setup on Ubuntu and AlmaLinux for hostname, swap, and base package work.
• Set up SSH, UFW, and Fail2Ban for a more firewall-focused hardening path.
• DMARC, SPF, and DKIM for better email deliverability if the server will also send mail alerts or transactional email.
• Add swap on Ubuntu and AlmaLinux VPS if the instance is small and you expect memory pressure.

Final check

At this point, you should have a named administrator account, key-based SSH access, working sudo rights, updated packages, time sync, a live firewall, and Fail2Ban watching SSH. That is a solid baseline for a real hosting environment, not just a lab box. From here, you can safely move on to web server, database, or WordPress deployment work without building on a risky root-only login.

FAQ

Should I disable root SSH immediately?
No. Keep the root session open until the new non-root login works from a second terminal and sudo is confirmed.

Do I need a password for the deploy user?
Not for day-to-day work. A temporary password is fine during setup, but SSH keys should be the normal login method.

Is UFW required on every Linux VPS?
No. Use UFW on Ubuntu and Debian. Use firewalld on AlmaLinux and Rocky Linux.

What if my provider uses a different default user?
Some providers give you ubuntu, debian, or another non-root user. Test that account first, then use the same permissions flow shown here.

Can I skip Fail2Ban if I already use key-based SSH?
You can, but it is still useful. It cuts down log noise and blocks repeated scans against your SSH port.