WHM Reseller Account Provisioning on Ubuntu Server 24.04

What you are building

WHM reseller account provisioning is the process of turning a fresh Ubuntu Server 24.04 VPS into a controlled hosting node for new cPanel/WHM customers. That means a non-root administrator, verified SSH access, basic hardening, and a clean handoff to WHM for account creation. This tutorial covers the first safe step support teams usually need: preparing the server so reseller onboarding does not begin with an insecure root-only login.

If you run client hosting on Hostperl VPS, this is where setup discipline matters. A rushed reseller build tends to create problems later: locked accounts, broken DNS zones, or a server only one person can access. For a production-ready starting point, begin with a managed baseline on Hostperl VPS, then work through the steps below.

Focus keyword: WHM reseller account provisioning
Primary intent: secure initial server setup for reseller hosting operations on Ubuntu Server 24.04

Scenario and layout

You have a new VPS, a WHM license-ready workload, and a support goal: create a standard administrator account named deploy, confirm sudo access, keep root available until the new login is proven, then harden SSH and prepare the server for WHM-based customer onboarding. This guide assumes Ubuntu Server 24.04, which matches the least-covered OS track for this run and supports apt, systemd, UFW, AppArmor, and netplan.

This is not a comparison article. It is the operational sequence your team would use before handing the server to a reseller, agency, or migration customer. If your business also handles migrations, the rehearsal pattern in WordPress migration rehearsal for safer 2026 cutovers is a useful mindset: verify access and rollback before you cut over anything important.

1) Connect as root and identify the OS

On your local computer, open the first SSH session with the reserved documentation IP below. Replace 203.0.113.10 with the real public IP assigned by your hosting provider.

ssh root@203.0.113.10

If your provider gives you a default non-root account, connect with that account instead using the same server IP. Keep the original root session open during the entire setup.

On the VPS as root, confirm the operating system before you make any changes.

cat /etc/os-release

You should see Ubuntu 24.04 details. If you do not, stop and follow the correct OS-specific procedure for that system.

2) Update packages and confirm time sync

Before creating accounts or touching SSH settings, bring the base system current. That lowers the risk of carrying old package bugs into a customer-facing setup.

apt update

apt -y full-upgrade

Then confirm system time is synchronized, because WHM, TLS, and logging all depend on correct time.

timedatectl status

Look for System clock synchronized: yes and a sane timezone. If the clock is wrong, fix it before moving on.

3) Create the non-root administrator

Use a named admin account for repeatable support work. Here the account is deploy. This is the account your team can document, rotate, and audit.

On the VPS as root, create the user and grant sudo access on Ubuntu.

adduser deploy

usermod -aG sudo deploy

adduser prompts for a password and profile details. Use a strong temporary password if you plan to keep password login enabled during the transition. The sudo group gives the account administrative rights.

Now create the SSH directory and set permissions.

install -d -m 700 -o deploy -g deploy /home/deploy/.ssh

If you already have a public key on your local computer, append it into the authorized keys file. The safest path is to copy the key from your workstation rather than pasting private material over the wire.

On your local computer, copy your public key to the server. Replace ~/.ssh/id_ed25519.pub with your real public key path if needed.

ssh-copy-id -i ~/.ssh/id_ed25519.pub deploy@203.0.113.10

When prompted, enter the temporary password for deploy. Then verify ownership and permissions on the server.

ls -ld /home/deploy /home/deploy/.ssh
ls -l /home/deploy/.ssh/authorized_keys

You want 700 on .ssh and 600 on authorized_keys, with deploy:deploy ownership.

4) Open a second terminal and test the new login

Do not close the root session yet. The new login must work before you change SSH policy.

On your local computer, open a second terminal and connect as the new account.

ssh deploy@203.0.113.10

After login, prove sudo works.

sudo -v
sudo whoami

The second command should print root. If it asks for the password and succeeds, your new admin path is ready.

5) Harden SSH without locking yourself out

Now that you have a verified fallback, tighten SSH. Keep the root session open, add any firewall rule first, test the new path, then disable risky login modes.

Ubuntu 24.04 uses OpenSSH service management through systemd. Open the SSH daemon configuration file.

On the VPS as root, edit the server configuration.

nano /etc/ssh/sshd_config

Set or confirm these lines. Add them if they are missing, and make sure you keep at least one valid login path before disabling password-based access.

PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes
AllowUsers deploy

Save and exit nano with Ctrl+O, Enter, then Ctrl+X.

Before reloading SSH, test the configuration syntax.

sshd -t

If the command returns no output, the syntax is valid. Then reload the service rather than restarting it, so active sessions stay open.

systemctl reload ssh

Leave the original root shell open until you confirm the new policy works from a fresh terminal. If you lose access, use the still-open root session to restore the previous SSH settings.

6) Enable the firewall for WHM prep

WHM itself is usually accessed on ports such as 2087, but you should not expose panel ports until you know exactly which services will be reachable. Start with SSH only, then add panel and mail-related rules when the panel install is complete.

On the VPS as root, install and enable UFW if it is not already present.

apt -y install ufw

ufw allow OpenSSH
ufw enable
ufw status verbose

The status should show OpenSSH allowed and the firewall active. After WHM is installed, you can add the panel ports you actually need rather than exposing everything by default.

For teams planning a larger panel rollout, the operational flow in WHM backup restore drill on AlmaLinux for safer migrations is a good reference for safe recovery habits.

7) Prepare the server for WHM onboarding

At this point, the machine is ready for WHM/cPanel installation or for handoff to your panel deployment process. This tutorial stops short of running the installer because the support-critical outcome here is secure server provisioning, not a generic package dump.

Still, you should confirm the basics that WHM support staff care about: hostname, disk space, and network reachability.

hostnamectl
free -h
df -h /
ip addr show

Set a proper hostname if needed before panel work begins. A server hostname such as server.example.com is a documentation example only; use the real fully qualified domain name assigned to your server.

If you manage DNS for reseller customers, keep the record plan aligned with your nameserver and certificate strategy. The guide DNSSEC and email authentication on Ubuntu Server 24.04 is relevant when you later publish the panel hostname, nameservers, and mail records.

8) Add a safe rollback path

Every support-ready setup needs a simple undo path. Before you make any stronger restrictions, back up the SSH configuration and note the current firewall state.

On the VPS as root, save copies of the files you changed.

cp /etc/ssh/sshd_config /root/sshd_config.backup
ufw status numbered > /root/ufw-status-before-whm.txt

If SSH ever fails after a future change, you can restore the file and reload the service from the existing root session or provider console.

9) Verify from both sides

Now test the result from the server and from a client shell. This is the part that separates a working onboarding from a paper checklist.

On the VPS as root, check the SSH service and listening ports.

systemctl status ssh --no-pager
ss -tulpn | grep sshd

You should see active (running) and port 22 listening on the expected addresses.

On your local computer, confirm the new login still works after hardening.

ssh deploy@203.0.113.10

Then prove sudo is still functional.

sudo whoami

Expected output is root. If SSH fails here, use the root session or console access and check the SSH logs.

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

Troubleshooting the most common failures

SSH login fails after hardening. Run journalctl -u ssh -n 50 --no-pager on the server. Look for Permission denied or Authentication refused. If you disabled password login before adding a key, restore PasswordAuthentication yes from the root session, reload SSH, then retest.

UFW blocks access unexpectedly. Check the current rules with ufw status verbose. If the SSH rule is missing, add it back with ufw allow OpenSSH. If you later enable WHM ports, add them before closing the root console session.

The SSH config test fails. Run sshd -t and read the exact line number. Fix the file in /etc/ssh/sshd_config, then run systemctl reload ssh again. Do not restart first if you still need the open session.

The deploy user cannot sudo. Check group membership with id deploy. If sudo is missing, run usermod -aG sudo deploy, log out, and log in again so the new group list is applied.

Why this setup works for real reseller operations

WHM reseller account provisioning is not just about one panel login. It is about repeatable access, controlled privilege, and a clean support handoff. A verified non-root admin account, locked-down SSH, and a known rollback path make later migrations less risky and help your support team respond faster when a customer opens a ticket.

Hostperl clients who need a predictable launch path often start with a managed VPS and move into panel work after the base OS is stable. If you are planning that type of rollout, a managed VPS hosting plan gives you enough room for WHM, backups, and staging without squeezing the server on day one.

FAQ

Should I disable root SSH immediately?
Not until you have tested the new sudo user from a second terminal and confirmed you still have console access.

Can I use password login for WHM provisioning?
Only during the transition. After the deploy user works with SSH keys, disable password authentication.

What port does WHM use?
WHM normally listens on 2087, but you should only open it after the panel is installed and validated.

How do I recover if I lock myself out?
Use the provider console or an existing root session, restore /etc/ssh/sshd_config from backup, and reload ssh.

What should I check before handing the server to a reseller customer?
Confirm hostname, disk space, firewall rules, SSH access, time sync, and the first panel login path.