FreeBSD Regional Hosting Handover for Agencies

Use case and what you will set up

This tutorial walks you through a regional hosting handover on a FreeBSD server for an agency client, with no shortcuts. The aim is straightforward: create a secure admin account, confirm the FreeBSD release, prepare access, set a sensible firewall baseline with pf, verify DNS and service readiness, and leave the server in a state your support team can manage.

It suits agencies moving a client into a regional Hostperl environment, managed hosting teams taking over a server from another provider, or operations staff who need a repeatable handoff process. If you are planning a wider move, this guide pairs well with Hostperl's managed hosting handover checklist for agencies in 2026 and with regional placement decisions covered in regional hosting for agencies.

This guide assumes a fresh FreeBSD server on Hostperl or a similar provider. It uses the reserved example IP 203.0.113.10; replace it with the real public IP assigned to your server.

First login and OS detection

On your local computer, connect as root first so you can complete the initial setup safely. Keep this session open until you have tested the new non-root account.

ssh root@203.0.113.10

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

After login, confirm the operating system before you run any FreeBSD-specific commands.

freebsd-version

You should see a FreeBSD release such as 14.2-RELEASE or similar. That confirms this tutorial matches the platform. If you are not on FreeBSD, stop here and use the correct tutorial for that system.

Create the non-root administrator

FreeBSD handovers should not stay on root. Create a named admin account, add it to wheel, and prepare SSH access before you change any root login rules.

On the VPS as root, create the account and set a password:

adduser

When the interactive prompt appears, use these values as a practical baseline:

• Username: deploy
• Full name: Deploy Admin
• Login group: press Enter for the default
• Invite user into other groups: wheel
• Login class: press Enter
• Shell: /bin/sh or /bin/tcsh
• Password: choose a strong password you can retire later

Next, create the SSH directory and permissions for the new account.

mkdir -p /home/deploy/.ssh
chmod 700 /home/deploy/.ssh
chown deploy:deploy /home/deploy/.ssh

Now place the public key in authorized_keys. If you already have the key on your local computer, copy it securely with ssh-copy-id or paste it manually through an SSH session. A manual path is shown below for clarity.

cat > /home/deploy/.ssh/authorized_keys <<'EOF'
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIEXAMPLEKEYFORHOSTPERLTUTORIAL deploy@example.com
EOF
chmod 600 /home/deploy/.ssh/authorized_keys
chown deploy:deploy /home/deploy/.ssh/authorized_keys

Replace the sample key with your real public key. The permissions matter: SSH will ignore the file if it is too open.

Test the new login before locking down root

Open a second terminal on your local computer and test the new account. Do not close the original root session yet.

ssh deploy@203.0.113.10

Once logged in, confirm you have the expected identity and sudo-style access path through wheel.

whoami
id
su -

Enter the account password when prompted by su -. You should become root after authentication. If that works, the account is ready for operational use. If it fails, fix group membership or the password before you continue.

When you have confirmed access, return to the root session and verify the account is in wheel.

pw group show wheel
id deploy

You should see deploy listed in the wheel group.

Harden SSH access without locking yourself out

Now that the new administrator works, harden SSH. The safe sequence is: add the new key, test the new login, then tighten SSH rules. Do not disable root access until you are confident the new account can recover the server.

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

vi /etc/ssh/sshd_config

Use the following baseline settings. If the file already contains these directives, update the values instead of duplicating them.

Port 22
PermitRootLogin prohibit-password
PasswordAuthentication no
PubkeyAuthentication yes
AllowUsers deploy

Save and exit vi with :wq.

Before you reload SSH, test the configuration syntax.

sshd -t

If there is no output, the syntax is valid. If you see an error, correct the file first. Then reload SSH safely:

service sshd reload

Keep the root session open and test a fresh SSH login from your local computer in another terminal. Make sure the key-based login still works before you proceed.

Set up a pf firewall for the regional hosting handover

FreeBSD uses pf rather than UFW or firewalld. For a hosting handover, allow SSH first, then enable rules that match your live services. In this example, the rules stay simple: SSH and standard web ports.

On the VPS as root, create or replace /etc/pf.conf.

cat > /etc/pf.conf <<'EOF'
set skip on lo
scrub in all
block in all
pass out all keep state
pass in on egress proto tcp from any to any port { 22, 80, 443 } keep state
EOF

This rule set blocks unsolicited inbound traffic, keeps loopback open, and allows SSH plus web traffic. If your service uses a different port, add it here before enabling the firewall.

Check the syntax before loading the rules.

pfctl -nf /etc/pf.conf

If the syntax is valid, load the rules and enable the firewall at boot.

service pf enable
service pf start

Verify that the rules are active:

pfctl -sr
service pf status

You should see the pass rules you defined. If SSH stops working, you still have the original root session open, which is why the sequence matters.

Confirm the machine is ready for client cutover

Before you tell an agency client that the handover is done, validate the operational basics. This is where many support tickets begin if you skip the checks.

On the VPS as root, confirm hostname, time, and network identity.

hostname
uname -a
sockstat -4 -6 | head

Then confirm the network path and DNS resolution from the server side.

drill example.com
ping -c 3 1.1.1.1

If drill is not installed, add the lightweight DNS tools package first:

pkg update
pkg install -y ldns-utils

Next, check the service states you actually need for the handover. If this server is only acting as a secure jump point or account host, you may not need a web stack. If it does serve sites, verify the active listener and logs.

service sshd status
sockstat -4 -l
less /var/log/auth.log

For a web-facing handover, a simple HTTP smoke test from the server itself can confirm the loopback path after you install your application stack.

fetch -o - http://127.0.0.1/

Replace the URL with your actual local service endpoint if needed. The expected result is a valid response body or page source, not a connection refusal.

Apply a rollback plan before finalizing

Every handover needs a way back. On FreeBSD, that usually means keeping the root session available, retaining console access, and knowing how to disable a bad firewall rule set if a change goes wrong.

If SSH is blocked after a firewall change, use the root console or provider rescue access and run:

service pf stop
cp /etc/pf.conf /etc/pf.conf.bad
cat > /etc/pf.conf <<'EOF'
set skip on lo
pass out all keep state
EOF
pfctl -nf /etc/pf.conf
service pf start

This temporary recovery file leaves outbound access open and removes inbound restrictions until you can reapply a corrected rule set. After recovery, restore the intended policy and test again from a second terminal.

Optional packages for managed account work

Some agency handovers need account transfer utilities, backup tools, or remote diagnostics. Install only what the workflow requires. FreeBSD keeps that clean and predictable.

pkg update
pkg install -y vim git bash curl rsync

Those packages help with editing, deployment pulls, and backup transfer checks. If your agency workflow depends on a specific stack, install it now and document the exact versions in the handover notes.

Final verification from server and client

From the server, confirm the new administrator can maintain the machine and that the firewall is active.

su - deploy
id
pfctl -sr
service sshd status

From your local computer, open one more fresh SSH session as the non-root user. This is the proof that matters for a real handover.

ssh deploy@203.0.113.10

Then run a simple remote command to confirm the session is working end to end:

ssh deploy@203.0.113.10 'whoami && hostname && freebsd-version'

If the command returns the expected username, host name, and FreeBSD version, the handover is ready for client use.

Troubleshooting

SSH login fails after hardening. Diagnose with:

sshd -t
service sshd status
sockstat -4 -l | grep :22

If syntax is broken, fix /etc/ssh/sshd_config and reload sshd. If port 22 is closed, use console access and confirm the firewall rules.

pf blocks the server after reload. Check the active rules:

pfctl -sr
pfctl -si

If the SSH pass rule is missing, restore the temporary recovery config shown above, then reapply a corrected rule set.

DNS lookups fail from the server. Test resolution and routing:

drill example.com
netstat -rn
ping -c 3 1.1.1.1

If DNS fails but raw IP ping works, fix the resolver settings before you hand the server to the client.

FAQ

Why use a non-root account first?
Because you need a tested recovery path before you remove root convenience. A verified admin account prevents lockout during SSH hardening.

Can I use this same process on Linux?
The workflow is similar, but the commands differ. FreeBSD uses pf, pkg, service, and freebsd-version, so Linux instructions do not apply directly.

Should I disable password logins immediately?
Only after key-based login works in a second terminal and you have console access. Test first, then tighten access.

What should I document for the client?
Record the admin username, service ports, firewall policy, SSH key location, contact path, backup state, and any provider-specific access notes.