Reseller Hosting Handover on Ubuntu 24.04 for Agencies

What you are setting up

A reseller hosting handover is the point where an agency or support team takes over a live hosting environment, checks access, and confirms clients can be supported without lockouts or missing DNS records. This tutorial uses Ubuntu Server 24.04 as the operating system track and focuses on a safe, production-ready handover on a new server. If you manage customer sites on Hostperl VPS hosting or on a regional dedicated platform, the same handover discipline applies: verify access first, move services next, and cut over only after tests pass.

You will create a non-root sudo user, harden SSH, confirm firewall rules, check DNS and mail-related records, and validate the handover with command-based checks. For agencies, that is the difference between a clean client transfer and a late-night support ticket. If you are migrating from another platform, keep the source system intact until the final verification is complete. For a related production migration pattern, see WHM migrations on RHEL 9 for managed hosting.

Before you start

Supported platform: Ubuntu Server 24.04 LTS. This procedure uses apt, systemd, UFW, and AppArmor conventions that match Ubuntu. If your handover target is AlmaLinux or Rocky Linux, the account and firewall commands differ, so do not copy these instructions blindly.

Scenario: you received a new Hostperl server for agency client accounts, and you need to make the server support-ready before handing it to your team or customer. Use the reserved documentation IP 203.0.113.10 below, then replace it with the real public IP assigned to your server.

Connect to the server and identify the OS

On your local computer, connect as root first. Keep this session open until the new sudo user is confirmed.

ssh root@203.0.113.10

203.0.113.10 is a documentation example. Replace it with your server's real public IP address.

If your provider gives you a default non-root account, the first login may look like this instead:

ssh deploy@203.0.113.10

After you log in, identify the operating system before you change anything.

On the VPS as root, run:

cat /etc/os-release

You should see Ubuntu 24.04 details such as VERSION_ID="24.04". If you do not, stop here and follow the matching distribution path for the server you actually received.

Create the non-root admin for the reseller hosting handover

A reseller hosting handover should not depend on root login alone. Create a sudo user named deploy, add SSH keys, and confirm that the account works before you touch authentication settings.

On the VPS as root, create the user and add it to the sudo group:

adduser deploy

Set a strong password when prompted. Then grant sudo access:

usermod -aG sudo deploy

Now prepare the SSH directory and permissions for that account:

mkdir -p /home/deploy/.ssh
chmod 700 /home/deploy/.ssh
cp /root/.ssh/authorized_keys /home/deploy/.ssh/authorized_keys 2>/dev/null || true
chown -R deploy:deploy /home/deploy/.ssh
chmod 600 /home/deploy/.ssh/authorized_keys

If you do not already have a root authorized key, copy your public key from your local computer with ssh-copy-id in a second terminal. The file permissions above keep the SSH daemon happy and avoid a login failure.

Check the account and group membership:

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

You should see sudo in the group list and tight permissions on the SSH directory and key file.

Test the new login before making root changes

On your local computer, open a second terminal and log in as the new user while keeping the original root session open.

ssh deploy@203.0.113.10

Then confirm sudo works.

On the VPS as the non-root sudo user, run:

sudo -v
sudo whoami
pwd

The first command should prompt for your password or use cached credentials. The second should return root. If it does not, fix the group membership before continuing.

Update packages and install handover essentials

Fresh handovers should start from a patched base. Update the package index and install the tools you will use for validation.

On the VPS as root, run:

apt update
apt -y upgrade
apt -y install ufw curl ca-certificates chrony jq

On Ubuntu 24.04, chrony gives stable time sync for certificate validation, logs, and backups. curl and jq help with smoke tests and API checks. Verify the packages installed cleanly:

apt policy ufw chrony curl jq
systemctl status chrony --no-pager

You should see active (running) for Chrony.

Set hostname, time sync, and a safe support baseline

A handover is easier to support when the server identifies itself clearly. Set the hostname to match a support-friendly label such as server.example.com, then confirm time sync is active.

On the VPS as root, run:

hostnamectl set-hostname server.example.com
hostnamectl
chronyc tracking

server.example.com is the example hostname. Replace it with the actual server name your team uses. The tracking output should show a current reference source and a small time offset.

Open only the ports you need

For a handover, open SSH first, then add application or panel ports later if needed. This avoids lockouts during the first round of access changes.

On the VPS as root, enable UFW and allow SSH:

ufw allow OpenSSH
ufw enable
ufw status verbose

You should see SSH allowed and the firewall active. If the server will host web services, add those rules only after you know the service ports. For example, a control panel or web stack might later need 80 and 443, but do not open them unless they are actually in use.

Harden SSH without locking yourself out

Once the non-root login is verified, harden SSH. Do not disable root or password login until you have a working second session and a rollback path.

On the VPS as root, edit the SSH daemon configuration:

nano /etc/ssh/sshd_config

Add or adjust these lines in the file:

PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes
AllowUsers deploy

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

Before reloading SSH, test the syntax:

sshd -t

No output means the configuration parsed correctly. Now reload SSH safely:

systemctl reload ssh

Keep the original root session open until you confirm the new login still works in the second terminal.

Check AppArmor and system services

Ubuntu uses AppArmor, so confirm the service is active if your handover includes web or database software later. This does not replace application-specific hardening, but it gives you a quick baseline.

On the VPS as root, run:

systemctl status apparmor --no-pager
apparmor_status

You should see AppArmor loaded and running. If it is not active, note it for the final support handover record.

Validate DNS records and customer-facing identity

Agencies often inherit zones, mail records, and website hostnames during a handover. Check the obvious records before clients notice delays or failed mail flow. If your handover includes DNS work, the details in DNS records for email deliverability in 2026 explain why SPF, DKIM, and DMARC need to be aligned before a client goes live.

On the VPS as the non-root sudo user, run basic resolution tests:

dig +short server.example.com
nslookup server.example.com
curl -I http://server.example.com

Replace server.example.com with the real hostname for your handover. If the name does not resolve or points to the wrong IP, fix the DNS zone before you move on. The curl check should return an HTTP response if a web service is already present; if not, the command will fail, which is still useful because it confirms the name is not silently blackholed.

Prepare a rollback path before cutover

A handover is safer when rollback is documented. Before you notify the customer or agency team, make a note of the current SSH settings and firewall rules so you can restore them if a mistake appears later.

On the VPS as root, save the current SSH config and firewall state:

cp /etc/ssh/sshd_config /root/sshd_config.backup.$(date +%F)
ufw status numbered > /root/ufw-status.backup.$(date +%F).txt

If you need to roll back, restore the file and reload SSH after syntax checking:

cp /root/sshd_config.backup.2026-01-01 /etc/ssh/sshd_config
sshd -t
systemctl reload ssh

Replace the backup filename with the actual date-stamped file you created. Keep the old root session open until the restored settings are confirmed.

Final verification from server and client

Your handover is not finished until you prove three things: the new user can log in, the firewall is active, and the server answers where it should.

On the VPS as the non-root sudo user, run:

sudo systemctl status ssh --no-pager
sudo ufw status verbose
sudo ss -tulpn

You should see SSH listening on port 22 and UFW active. Then test from your local computer again:

ssh deploy@203.0.113.10

If the login works from a fresh terminal, the handover is ready. If the server will host a customer website or control panel later, confirm the service-specific ports after the application is installed.

Common failures and how to fix them

1. SSH login fails after hardening. Diagnose from the server with:

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

If sshd -t reports an error, fix the config file and reload SSH. If the logs show Permission denied, check ~/.ssh ownership and permissions.

2. The new user cannot sudo. Check group membership with:

id deploy
grep '^%sudo' /etc/sudoers

If the user is missing from the group, run usermod -aG sudo deploy again, then log out and back in.

3. DNS still points to the old server. Diagnose with:

dig +short server.example.com
resolvectl status

If the record is stale, update the authoritative DNS zone and wait for propagation before cutover.

4. UFW blocked a needed service. Check numbered rules:

ufw status numbered

Then add the required port with a new allow rule before removing anything old. For example: ufw allow 443/tcp.

How this helps agencies and support teams

A proper reseller hosting handover is less about one command and more about reducing uncertainty. Your team gets a known administrator account, validated SSH access, firewall boundaries, and a server identity that can be supported without guesswork. That makes onboarding cleaner for client accounts, whether you are moving a small business site or inheriting multiple properties during a managed hosting transfer.

FAQ

Should I disable root SSH immediately?

No. Keep root open until the new sudo user has logged in from a second terminal and sudo has been tested successfully.

Can I use this process for a managed hosting handover?

Yes, as long as the underlying server is Ubuntu 24.04 and you are responsible for account access, SSH keys, and firewall verification. The same access discipline applies whether the customer uses a panel or a custom stack.

What if my server uses a different firewall?

Follow the same sequencing, but use the native firewall tool for that distribution. On Ubuntu, this tutorial uses UFW. On RHEL-family systems, you would usually use firewalld instead.

Do I need to check email records during a handover?

If the server sends mail or hosts DNS for client domains, yes. SPF, DKIM, and DMARC should be checked before a customer is told the handover is complete.

What should I record for the support team?

Document the hostname, public IP, sudo user, SSH key owner, firewall rules, and any DNS records that point to the server. That short record saves time when a client calls later.