Debian Shared Hosting Account Setup for Production Launches

What this tutorial solves

This Debian shared hosting account setup guide takes you from your first SSH login to a production-ready account on a fresh Debian 12 or Debian 13 server. It is built for agencies, small businesses, and support teams that need a clean handoff, not just a root shell. You’ll create a non-root admin, tighten SSH access, update the base system, add a firewall, and confirm the server is ready for client work.

If you’re provisioning a new VPS for a client site, Hostperl VPS hosting gives you the control needed for this kind of setup, while keeping the launch path predictable for support teams and agency handovers.

Before you begin on Debian 12 or Debian 13

This procedure is for Debian only. It uses apt, systemd, and nftables through UFW, which fits Debian’s stable-release model well. Start with a fresh server and leave the root session open until the new admin login works.

• Supported OS: Debian 12 and Debian 13
• Goal: production-ready shared hosting admin account and baseline hardening
• Assumption: you have root access to the VPS

Connect to the server and check the OS

On your local computer, open your first SSH session with this exact command.

ssh root@203.0.113.10

Replace 203.0.113.10 with the real public IP assigned to your server. This is a documentation example address.

If your provider gives you a different default user, connect with that account instead, but keep the same example IP until you replace it with your own.

On the VPS as root, confirm the distribution before you change anything.

cat /etc/os-release

You should see Debian listed in the output. If you do not, stop here and use the matching procedure for that platform.

Create the shared hosting admin account

A shared hosting server should not be managed from root day to day. Create a named sudo user first, then verify that it can log in before you touch SSH restrictions.

On the VPS as root, create the deploy account and set a password for the initial console handoff.

adduser deploy

Enter a strong password when prompted. Debian will create the home directory automatically.

Now grant sudo access.

usermod -aG sudo deploy

Next, create the SSH directory and lock its permissions down before you add keys.

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

Copy your public key into the new account. Replace the sample key content with your actual public key.

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

This keeps the file readable only by deploy. That matters on a shared hosting box where multiple teams may later access logs, backups, or deployment directories.

Test the new account before changing SSH policy

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

ssh deploy@203.0.113.10

Once logged in, confirm the account and sudo path.

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

whoami
pwd
sudo -v

You should see deploy from whoami, a home-directory path from pwd, and no sudo errors after sudo -v. Keep the original root session open until this works.

Update Debian and install the baseline tools

Shared hosting servers need current package indexes, time sync, and a few operational tools before anything else. Do this from the sudo account so you are using the final access path you’ll rely on later.

On the VPS as the non-root sudo user, update the system and install the essentials.

sudo apt update
sudo apt -y full-upgrade
sudo apt -y install ca-certificates curl git gnupg lsb-release ufw chrony unattended-upgrades

full-upgrade is the safer choice on Debian for a production refresh because it handles dependency changes cleanly. chrony keeps the clock accurate, which helps logs, TLS, and support incident timelines.

Check the installed versions and service status.

apt-cache policy ufw chrony | sed -n '1,20p'
systemctl status chrony --no-pager

The clock service should be active. If it is not, start it with sudo systemctl enable --now chrony.

Set hostname, time sync, and a small swap file

A clear hostname helps support teams identify the server in ticket notes and monitoring dashboards. A modest swap file helps a small shared hosting node survive bursty PHP or database activity without immediate OOM kills.

On the VPS as the non-root sudo user, set a hostname that matches the server role.

sudo hostnamectl set-hostname server.example.com

Replace server.example.com with your own hostname. Then confirm it.

hostnamectl

If your VPS has no swap yet, add a 2 GiB file. This is conservative and fits many entry shared hosting plans.

sudo fallocate -l 2G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile
printf '/swapfile none swap sw 0 0\n' | sudo tee -a /etc/fstab
swapon --show

You should see /swapfile in the output. If your plan already includes swap, skip this step rather than doubling it blindly.

Enable the firewall without locking yourself out

UFW is a clean fit on Debian. Allow SSH first, then activate the firewall. That order prevents self-inflicted lockouts.

On the VPS as the non-root sudo user, allow SSH and common web traffic if this server will host customer sites.

sudo ufw allow OpenSSH
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable

Confirm the active rules.

sudo ufw status verbose

You should see OpenSSH, HTTP, and HTTPS allowed. If you manage only email or only a control panel on this server, adjust ports before you enable stricter policies.

Harden SSH access carefully

Only disable password logins after key-based access is verified. If you have a ticket queue or an agency team, this sequence protects launch-day access and reduces recovery risk.

On the VPS as the non-root sudo user, create a drop-in file for SSH hardening.

sudo nano /etc/ssh/sshd_config.d/99-hardening.conf

Paste this content into the editor:

PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes
KbdInteractiveAuthentication no
AllowUsers deploy

Save and exit the editor, then test the SSH daemon syntax before reloading.

sudo sshd -t

If the command returns no output, the configuration syntax is valid. Reload SSH now.

sudo systemctl reload ssh

Before closing your root session, test a fresh login from your local computer in a third terminal.

ssh deploy@203.0.113.10

If the login fails, restore the previous SSH behavior from your still-open root session by removing the drop-in file and reloading SSH:

rm /etc/ssh/sshd_config.d/99-hardening.conf
systemctl reload ssh

Turn on automatic security updates

For a shared hosting server, unattended security patches reduce the chance that a routine kernel or OpenSSL fix waits too long. Debian’s unattended-upgrades package is suitable for stable-security updates.

On the VPS as the non-root sudo user, enable the service and review the policy file.

sudo dpkg-reconfigure -plow unattended-upgrades
sudo systemctl status unattended-upgrades --no-pager

On Debian, the package configures the service to install security updates automatically. Keep manual maintenance windows for kernel changes and service restarts.

Shared hosting operations: what to place on this server

At this point the machine is ready for the common shared hosting stack: web server, PHP-FPM pools, database services, backup jobs, and account-level separation. The exact application mix depends on whether you are running a reseller environment, a managed client stack, or a regional launch for agency work.

For site owners who want a simpler hosted path, Hostperl shared hosting remains the lower-maintenance option. When you need more control for migrations, custom PHP versions, or account isolation, this Debian setup is the right handoff point.

If you run customer sites that rely on WordPress, the launch and rollback checks in WordPress staging and safe cutover for real stores are a useful companion, especially when multiple clients share the same server.

For teams planning repeatable deployments, Docker Compose release readiness for VPS launches is a practical follow-up if you later host apps alongside websites on the same Debian node.

Verify services, ports, and reboot persistence

Now check that the account, firewall, and core services persist after a reboot. These are the checks support teams care about when a client asks whether a server is truly launch-ready.

On the VPS as the non-root sudo user, confirm the key services and listening ports.

systemctl is-active ssh
systemctl is-active chrony
sudo ufw status verbose
ss -tulpn | grep -E ':(22|80|443)\b'

Then reboot and verify that SSH returns, which proves the new access path survives a restart.

sudo reboot

On your local computer, reconnect after the reboot finishes.

ssh deploy@203.0.113.10

On the VPS as the non-root sudo user, run a final smoke test.

whoami
sudo -v
uptime
hostnamectl

You should see the deploy account, valid sudo, a recent uptime, and the hostname you set earlier.

Troubleshooting the most likely failures

SSH hardening, sudo access, and firewall rules are the usual failure points. Use the commands below before you change more settings.

• Problem: SSH login fails after hardening.
  Diagnostic: sudo journalctl -u ssh -n 50 --no-pager
  Expected clue: a denied user, bad syntax, or key mismatch.
  Fix: restore the previous drop-in file or correct /etc/ssh/sshd_config.d/99-hardening.conf, then run sudo sshd -t and sudo systemctl reload ssh.
• Problem: sudo does not work for deploy.
  Diagnostic: id deploy
  Expected clue: missing sudo in the group list.
  Fix: sudo usermod -aG sudo deploy, then log out and back in.
• Problem: the server disappears after enabling UFW.
  Diagnostic: use the provider console or rescue access, then run sudo ufw status numbered
  Expected clue: SSH is missing.
  Fix: allow OpenSSH first with sudo ufw allow OpenSSH, then re-enable the firewall.
• Problem: the clock drifts or TLS errors appear later.
  Diagnostic: timedatectl
  Expected clue: time sync inactive or wrong timezone.
  Fix: sudo systemctl enable --now chrony and set the correct timezone with sudo timedatectl set-timezone Pacific/Auckland or your local zone.

Rollback and recovery path

If you need to back out the hardening, keep the root console session open until the new login is fully proven. That one habit saves a lot of unnecessary rescue-mode work.

On the VPS as root, these commands restore the earlier SSH posture and remove the firewall if needed during emergency troubleshooting.

rm -f /etc/ssh/sshd_config.d/99-hardening.conf
sshd -t && systemctl reload ssh
ufw disable

Use that rollback only while you are fixing access. Re-enable the firewall and SSH restrictions once the issue is resolved.

FAQ

Can I use this Debian setup for a reseller handoff?
Yes. The same account and SSH controls work well before you add customer sites, billing access, or control panel management.

Should I disable root login immediately?
No. Verify the new deploy login from a second terminal first, then remove root SSH access only after testing.

Do I need swap on every VPS?
Not always. It helps smaller shared hosting nodes, but you should size it to your workload and memory limits.

What should I check before a client launch?
Confirm SSH access, firewall rules, time sync, hostname, reboot recovery, and at least one live smoke test from a second machine.

Where do I go next after the base setup?
Typical next steps are web server installation, PHP-FPM tuning, account backups, and monitoring. Those layers sit cleanly on top of this Debian baseline.