Agency Handover on Managed Hosting: A Practical Ubuntu Guide

What this handover solves

This guide walks you through an agency handover on managed hosting for a new Ubuntu Server customer without locking yourself out or leaving the server in an unfinished state. The aim is straightforward: create a clean admin path for the agency, verify access, document the changes, and keep a rollback route if the client needs to step back.

This is written for Hostperl customers who launch sites, move client accounts, and need support-ready servers that can move between teams. If you are choosing hosting for agency work in 2026, Hostperl VPS hosting is a better fit than trying to squeeze a shared plan into a multi-user workflow: Hostperl VPS.

Before you start on Ubuntu Server

This tutorial assumes Ubuntu Server 24.04 LTS or a newer supported release. It uses apt, systemd, ufw, and standard OpenSSH tooling. The same handover pattern also works well when a managed site moves onto a VPS and needs a predictable admin model instead of shared credentials passed around by hand.

Open two terminal windows on your local computer. Keep the first SSH session open until you confirm the new agency login from the second terminal.

ssh root@203.0.113.10

203.0.113.10 is a reserved documentation address. Replace it with the real public IP assigned to your server. If your provider uses a non-root entry account, use that same real IP with the correct username instead.

Check the operating system and update the server

On the VPS as root, confirm the OS before you change package or firewall settings.

cat /etc/os-release

You should see Ubuntu listed, along with the release name and version. If the system is not Ubuntu Server, stop here and follow the matching distro procedure for your environment.

Now refresh package lists and install the base tools you need for a controlled handover.

apt update
apt -y upgrade
apt -y install sudo openssh-server ufw curl ca-certificates

This brings the server current, installs the sudo path for the new admin, and makes sure SSH and UFW are ready for the next steps. Reboot later if the kernel or OpenSSH package requires it.

Create the agency admin account

On the VPS as root, create a non-root account named deploy, then add it to the sudo group.

adduser deploy
usermod -aG sudo deploy

The deploy user now has a normal login and can elevate with sudo. Keep root access available until you prove the new account works.

Lock the password if you plan to use SSH keys only. This is safer for handovers because it removes password-based local login while leaving SSH key access intact.

passwd -l deploy

Next, create the SSH directory and set permissions. Replace the example key with the agency public key you want to trust.

install -d -m 700 -o deploy -g deploy /home/deploy/.ssh
cat > /home/deploy/.ssh/authorized_keys <<'EOF'
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIExampleAgencyPublicKeyValue replace-this-with-your-real-key agency@example.com
EOF
chown deploy:deploy /home/deploy/.ssh/authorized_keys
chmod 600 /home/deploy/.ssh/authorized_keys

Only paste a real agency public key into authorized_keys. The permissions above should leave the file readable only by deploy.

Test the new login before you change SSH policy

On your local computer, open the second terminal and log in as the new user.

ssh deploy@203.0.113.10

Use the same IP you received from Hostperl. If the key is installed correctly, the login should complete without a password prompt.

On the VPS as the non-root sudo user, confirm sudo works and the account can perform admin tasks.

sudo -i
whoami
id

You should see root from whoami after privilege escalation, and deploy should appear in the group list. Leave both sessions open.

Harden SSH for agency handover on managed hosting

Now that the new login works, adjust SSH so the server accepts key-based access and stops allowing root password logins. On Ubuntu, the cleanest approach is to drop a file into /etc/ssh/sshd_config.d/ rather than edit the main config directly.

On the VPS as root, create the hardening file.

cat > /etc/ssh/sshd_config.d/99-agency-handover.conf <<'EOF'
PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes
EOF

Test the SSH configuration before you reload anything.

sshd -t

If that command returns no output, the syntax is valid. Reload SSH only after the test passes.

systemctl reload ssh

Do not close the original root session yet. OpenSSH reloads are usually safe, but you want a fallback if the agency key was mistyped.

Set up the firewall without cutting off SSH

On the VPS as root, allow SSH first, then enable UFW. This avoids a lockout if the firewall is currently inactive.

ufw allow OpenSSH
ufw allow 80/tcp
ufw allow 443/tcp
ufw enable
ufw status verbose

You should see SSH, HTTP, and HTTPS allowed. If the agency handover includes a reverse proxy or public website, the web ports are ready now. For customers running managed web workloads, this is the same perimeter you would expect on a properly prepared Hostperl VPS or managed server: managed VPS hosting.

Document what the agency receives

Good handovers fail when the next admin has to guess what changed. Capture the account, SSH, and service state before you hand over the keys.

On the VPS as root, record the account and listening services.

getent passwd deploy
id deploy
ss -tulpn | head -n 20
systemctl --failed

You want to confirm that deploy exists, has sudo access, and that the server does not already carry a failed service from a previous deployment.

If the handover includes a managed site or panel account, link your internal notes to the operational guidance you already use for migrations and account moves. Hostperl’s managed hosting and agency workflow guidance can help when you need clear support boundaries: managed hosting handover checklist for agencies.

Verify service health and reboot persistence

Before you declare the server ready, verify that SSH, firewall, and any customer service survive a reboot.

systemctl status ssh --no-pager
systemctl status ufw --no-pager
reboot

After the reboot, reconnect first as deploy from your local computer.

ssh deploy@203.0.113.10

Then test sudo again.

sudo -i
whoami

If those commands work after a reboot, the handover is durable, not just temporarily functional. If your server also hosts a website, check the HTTP endpoint from your local machine.

curl -I http://203.0.113.10

A valid response will be a 200, 301, or another intentional status from your application or reverse proxy.

Rollback if something goes wrong

If the agency key is wrong or SSH hardening blocks access, use the original root session or your provider console to recover.

On the VPS as root, remove the hardening file and reload SSH.

rm -f /etc/ssh/sshd_config.d/99-agency-handover.conf
sshd -t
systemctl reload ssh

If the firewall caused the problem, disable it only long enough to regain access.

ufw disable

Once access is restored, reapply the rules carefully and test each step again. Keep the root session open until the new login is verified twice: once before the SSH policy change and once after reboot.

Common failures and how to diagnose them

Permission denied with the new key

ls -ld /home/deploy /home/deploy/.ssh /home/deploy/.ssh/authorized_keys
journalctl -u ssh -n 50 --no-pager

Look for wrong ownership or file mode values. Fix them with chown deploy:deploy and chmod 700/chmod 600.

Sudo says the user is not in the sudoers file

id deploy
grep -E '^sudo:' /etc/group

If needed, add the account again with usermod -aG sudo deploy and log out, then log back in.

SSH reload fails

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

The syntax test usually points straight to the bad line. Fix the config, rerun sshd -t, then reload again.

FAQ

Should I disable root login immediately?

No. Keep root available until the new deploy login works from a second terminal, has sudo access, and survives a reboot.

Can I use password login for the agency?

You can, but SSH keys are safer for handover work. If you must use passwords, keep PermitRootLogin no and review access after the transition.

What if I manage more than one client on the server?

Use separate admin accounts, separate SSH keys, and a written list of which services belong to which client. That makes support escalation much cleaner.

Is this the right model for managed hosting?

Yes. It gives the agency control without sacrificing traceability or recovery. That is usually the right balance for client launches and ongoing support.

What should I save after the handover?

Save the admin username, key fingerprint, firewall rules, SSH policy file, and the exact verification commands you ran. Those notes speed up future support.