Create a Non-Root Admin User on Ubuntu and AlmaLinux

What you need before you begin

This guide shows you how to create a non-root admin user on a fresh VPS, confirm sudo access, and then decide whether to restrict root login. It is written for Hostperl customers who want a safer first login on Ubuntu, Debian, AlmaLinux, or Rocky Linux.

Use these placeholders throughout the tutorial: SERVER_IP is your VPS address, for example 203.0.113.10; DOMAIN_NAME is optional and only needed if you later add hostnames or TLS; ADMIN_USER is the new account name, for example hostadmin.

If you are still choosing a plan, a Hostperl VPS gives you the control this procedure assumes. If you are migrating a small business site later, our shared hosting and VPS options cover different launch paths.

Before you change anything, open two terminal windows. Keep the original root session open until the new login works.

ssh root@SERVER_IP

Run that from your local computer. If your provider gave you a default non-root account instead, use that account name in place of root. A successful login drops you into the server shell.

cat /etc/os-release

Run this on the VPS as root. It confirms whether you are on Ubuntu, Debian, AlmaLinux, or Rocky Linux before you use distribution-specific commands.

Create the non-root admin user

The next step is to create the admin account, add it to the sudo-capable group, and prepare SSH access. Do this as root in the first session.

Ubuntu and Debian

adduser ADMIN_USER

Replace ADMIN_USER with your chosen name, such as hostadmin. The system prompts you for a password and optional profile details. You can leave the profile fields blank.

usermod -aG sudo ADMIN_USER

This adds the account to the sudo group. You should see no output if it succeeds.

AlmaLinux and Rocky Linux

useradd -m -s /bin/bash ADMIN_USER

This creates a home directory and sets Bash as the login shell.

passwd ADMIN_USER

Set a strong password if you want password login as a backup. If you plan to rely only on SSH keys, you can still set one for emergency console access.

usermod -aG wheel ADMIN_USER

This is the standard sudo-equivalent group on RHEL-compatible systems. Again, success is usually silent.

Install your SSH key safely

Open a second terminal on your local computer and copy your public key to the new account. If you already have a key, use it. If not, create one first.

ssh-keygen -t ed25519 -a 64 -C "yourname@example.com"

Run that locally if you need a key pair. Accept the default file path unless you already use another key. A passphrase is recommended.

ssh-copy-id ADMIN_USER@SERVER_IP

Run this from your local computer. Replace ADMIN_USER and SERVER_IP with your values. If your shell cannot find ssh-copy-id, create the file manually on the server.

Manual key install when ssh-copy-id is unavailable

sudo -iu ADMIN_USER
mkdir -p ~/.ssh
chmod 700 ~/.ssh
nano ~/.ssh/authorized_keys

Paste your public key into the editor, save the file, then exit. The exact save keys depend on the editor; with Nano, use Ctrl+O, Enter, then Ctrl+X.

chmod 600 ~/.ssh/authorized_keys
chown -R ADMIN_USER:ADMIN_USER ~/.ssh

These permissions matter. SSH will ignore the key if the directory or file is too open.

Test the new login before changing root access

Now switch to your second terminal and test the new account directly. Keep the original root session open.

ssh ADMIN_USER@SERVER_IP

You should log in without a password prompt if your key is installed correctly. If the server still asks for a password, verify the key placement and permissions.

sudo -v

Run this after logging in as the new user. It checks that the account can elevate privileges. On Ubuntu and Debian, membership in sudo should allow it. On AlmaLinux and Rocky Linux, membership in wheel should do the same.

whoami
id
sudo whoami

These commands confirm the login identity and sudo access. The final command should print root.

Harden SSH after the new account works

Only after the new login is verified should you reduce root exposure. Change one thing at a time. Never remove root access before you have confirmed the fallback path.

Ubuntu and Debian SSH hardening

sudo nano /etc/ssh/sshd_config

Add or edit these lines in the file. Keep the original root session open until the service restarts cleanly.

PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes
AllowUsers ADMIN_USER

Replace ADMIN_USER with your account name. Then test the syntax before reloading SSH.

sudo sshd -t

No output means the configuration syntax is valid.

sudo systemctl reload ssh

On Ubuntu and Debian, the SSH service is usually named ssh. If the reload fails, use the original root session to reverse the edit.

AlmaLinux and Rocky Linux SSH hardening

sudo nano /etc/ssh/sshd_config

Add the same lines, then validate the config.

sudo sshd -t

On RHEL-compatible systems, the service name is usually sshd.

sudo systemctl reload sshd

If you rely on password login temporarily, do not disable it yet. Confirm key-based login from a fresh terminal first.

Enable the firewall without locking yourself out

A non-root admin user is safer when SSH is protected by a firewall. Open port 22 first, then adjust SSH settings.

Ubuntu and Debian with UFW

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

Run these on the VPS as the non-root sudo user. The status output should show SSH allowed before the firewall becomes active.

AlmaLinux and Rocky Linux with firewalld

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

These commands install and enable the firewall, then allow SSH before the reload. You should see the SSH service listed in the active zone.

Check logs and confirm the account is healthy

Use logs to confirm the login sequence is clean. This is the kind of check our support team asks for during a migration or first-boot issue.

journalctl -u ssh -n 50 --no-pager

On Ubuntu and Debian, this shows the most recent SSH messages. On AlmaLinux and Rocky Linux, use journalctl -u sshd -n 50 --no-pager instead.

sudo last -a | head

This gives you recent successful logins and the source addresses. You should see your own SSH test from the local machine.

Useful follow-up steps for a fresh VPS

Once the new administrator is in place, finish the basics. These are the same first-week tasks Hostperl customers usually complete after provisioning a server.

sudo apt update && sudo apt upgrade -y

Run the Ubuntu and Debian update path on those systems. On AlmaLinux and Rocky Linux, use sudo dnf upgrade -y instead. Patch the server before installing applications.

sudo timedatectl set-timezone Pacific/Auckland
sudo timedatectl status

Choose your timezone if the server serves New Zealand customers or your team operates there. The status output should show the new zone and synchronized time.

sudo hostnamectl set-hostname server1.example.com
hostnamectl

Replace server1.example.com with a hostname that matches your DNS plan. This helps with mail, logs, and support tickets.

If you are building a production site after this, our initial VPS setup guide covers the next steps like package updates, time sync, and hostname cleanup. For people planning WordPress or agency sites, our WordPress VPS setup is the natural next read.

Troubleshooting the most common failures

SSH key login still asks for a password

Check permissions and ownership on the server:

sudo -iu ADMIN_USER
ls -ld ~/.ssh
ls -l ~/.ssh/authorized_keys

The directory should usually be 700 and the key file 600. Fix them with:

chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
chown -R ADMIN_USER:ADMIN_USER ~/.ssh

Sudo says the user is not allowed to run commands

Confirm group membership:

id ADMIN_USER

Ubuntu and Debian should show sudo; AlmaLinux and Rocky Linux should show wheel. If the group is missing, add it again with the relevant usermod command.

SSH reload fails after editing sshd_config

Use the syntax test to get the exact error line:

sudo sshd -t

If you see an error, restore the original file from your open root session, then run the test again. Only reload when the command returns no output.

FAQ

Should I disable root login immediately?

No. Keep the root session open until the new admin user can log in with SSH keys and run sudo whoami successfully.

Can I use the same steps on Ubuntu and Debian?

Yes, with the Ubuntu/Debian command set shown above. The package manager, sudo group, and SSH service name are the main differences.

Do AlmaLinux and Rocky Linux use sudo or wheel?

They use the wheel group for administrative sudo access.

What if I lose SSH access after hardening?

Use your provider console or recovery access, then restore the SSH configuration from the open root session or rescue environment.