WHM Account Creation and Sudo Access on FreeBSD

Why this workflow matters on a live server

WHM account creation is not just a licensing task or a panel click-through. On a busy server, you need a repeatable way to create a new administrator account, verify SSH access, and keep the original root session open until the new login works. This tutorial shows that workflow on FreeBSD, where the surrounding system tools are different from Linux and the recovery path matters.

Use this procedure when you are bringing up a new Hostperl server, onboarding an agency operator, or preparing a handover for managed hosting. If you are comparing platforms for a similar deployment, Hostperl’s dedicated server hosting and Hostperl VPS plans both fit account-operations work that depends on stable SSH access and predictable administration.

Because this run is on FreeBSD, you will use pkg, rc.conf, service, and pf concepts instead of Linux-specific tools. WHM itself runs as a web application on the server, but the account-operations pattern below is useful whenever you need safe operator onboarding around a FreeBSD host.

Start with the first SSH session and OS check

On your local computer, open the first SSH session as root:

ssh root@203.0.113.10

Replace 203.0.113.10 with the public IP assigned to your server. It is a documentation example only.

Once you are on the server, confirm the platform before you change anything else:

freebsd-version

That command should print the FreeBSD release, such as 14.2-RELEASE. You can now continue with the correct system commands for this OS.

Create the operator account for WHM access

On the VPS as root, create a dedicated non-root account named deploy. Keep the original root SSH session open while you do this.

pw useradd deploy -m -s /bin/sh -G wheel

This creates the home directory, sets the login shell, and adds the user to the wheel group for administrative access.

Set a password only if you expect interactive password logins. For key-based access, you can lock the password after the SSH key works.

passwd deploy

After the password prompt, continue by preparing the SSH directory and key permissions.

su - deploy -c 'mkdir -p ~/.ssh && chmod 700 ~/.ssh'

Now copy your public key into place. Replace the sample key content with your real public key from your workstation.

cat > /home/deploy/.ssh/authorized_keys <<'EOF'
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIExampleKeyForDocumentationOnly deploy@laptop
EOF
chown -R deploy:deploy /home/deploy/.ssh
chmod 600 /home/deploy/.ssh/authorized_keys

The account is now ready for a first login test. If your host uses a different operator name, use that consistently instead of deploy.

Test the new login before changing root access

On your local computer, open a second terminal and connect as the new user. Do not close the original root session yet.

ssh deploy@203.0.113.10

You should land in the deploy shell without a password prompt if your key is installed correctly. Run the following check to confirm the user context and privilege path:

id
su -
pwd

On FreeBSD, su - should prompt for the root password and then open a root shell. If you prefer sudo for controlled elevation, install it first and configure a minimal rule set.

Install sudo and allow the wheel group

On the VPS as root, install sudo from the FreeBSD package repository:

pkg update
pkg install -y sudo

Check that it installed correctly:

sudo -V | head -n 1

Now create a sudoers drop-in that lets members of wheel run administrative commands. Use visudo so the syntax is checked before save.

visudo -f /usr/local/etc/sudoers.d/wheel

Enter this content in the editor:

%wheel ALL=(ALL) ALL

Save and exit the editor. Then validate the file with a syntax check:

visudo -c

Expected result: no errors. If the command reports a parse problem, fix the file before proceeding.

Back in the non-root session, test sudo explicitly:

sudo id

You should see uid=0(root) in the output. If that works, you have a safer operational path for WHM administration and can keep root for emergency recovery only.

Harden SSH access without locking yourself out

On the VPS as root, add the new firewall rule before you remove anything. If you already use pf, keep your current SSH rule in place while you test the new operator login.

First, confirm SSH is listening on the default port and that the daemon is running:

service sshd status
sockstat -4 -6 | grep sshd

If SSH is not active, start it and enable it at boot:

sysrc sshd_enable="YES"
service sshd start

Next, prepare a conservative SSHD override. Open the file and paste the settings below.

ee /etc/ssh/sshd_config

PermitRootLogin prohibit-password
PasswordAuthentication no
PubkeyAuthentication yes
AllowUsers root deploy

Save the file, then check the syntax before reload:

sshd -t

If the command returns nothing, the configuration is valid. Reload SSH only after you have at least one confirmed working key login for deploy:

service sshd reload

Do not disable root login until the second terminal session proves that SSH and sudo both work. If you need a rollback, restore the previous /etc/ssh/sshd_config and reload again from the still-open root shell.

Set the WHM account ownership and service baseline

On FreeBSD, the account-operations side still depends on stable service state. Before you hand the server over, confirm that the core services you rely on are enabled and that timekeeping is correct.

service ntpd status
sysrc ntpd_enable="YES"
service ntpd start

If your build uses chrony instead, install and enable that package instead of ntpd. The goal is simple: logs, SSL, and WHM sessions all behave better when the clock is correct.

Set a meaningful hostname so support tickets and account records match the machine name. Replace the example name if your provider uses a different naming standard.

sysrc hostname="server.example.com"
service hostname restart

Check the result:

hostname
hostname -f

You should see the updated server name. In a managed hosting workflow, this makes migrations, handovers, and support notes much easier to track.

Firewall and access validation for panel work

If you use pf, confirm that the SSH rule is still present before you tighten the rest of the box. This is the safe point to open any extra management port you may need for WHM-related administration on a side channel.

pfctl -sr
pfctl -ss

For a quick connectivity test from your workstation, reconnect as deploy and prove that sudo still works after the SSH changes:

ssh deploy@203.0.113.10
sudo whoami

Expected output: root. If that fails, stop and fix the account or sudoers file before you touch any panel-side settings.

Rollback and recovery path

If something goes wrong, keep the root SSH session open and work backward in this order: restore SSH config, reload sshd, test the deploy login again, and only then change any firewall rules. For account cleanup, remove the user only after you confirm no services or automation depend on it.

pw userdel deploy -r

Use that command only when you are sure the account is disposable. It removes the home directory as well, so it is not a casual cleanup step.

For service rollback, you can reverse the last change quickly:

cp /etc/ssh/sshd_config.bak /etc/ssh/sshd_config
sshd -t
service sshd reload

Make a backup copy before you edit SSH on any production server. That saves time during an incident and avoids a lockout.

Final verification from server and client

On the VPS as root, confirm the baseline state one last time:

freebsd-version
service sshd status
service ntpd status
sockstat -4 -6 | egrep 'sshd|:22'
visudo -c

You want to see an active SSH daemon, a correct time service, and a clean sudoers check.

On your local computer, perform one final smoke test:

ssh deploy@203.0.113.10
sudo id

If that succeeds, the server is ready for WHM account administration and routine support work. The sequence is safe, repeatable, and easy to hand off to another operator.

For teams that need account-operations support on production servers, Hostperl’s dedicated server hosting and Hostperl VPS options give you room to keep root isolated while daily access stays on a controlled sudo path.

FAQ

Can I use password login for the deploy user?
Yes, but key-based SSH is safer. If you enable passwords temporarily, turn them off after you confirm the key login works.

Should I disable root SSH immediately?
No. Keep the root session open until the new account works from a second terminal and sudo passes its test.

What if visudo reports an error?
Fix the sudoers file and run visudo -c again. Do not reload SSH or close the root session until the error is gone.

Is this the same as a WHM license setup?
No. This tutorial is about account creation and safe operator access on FreeBSD, not license management.