Colocation Network Handoff Checklist for Debian Servers

Before you rack the server: what this handoff should prove

This colocation network handoff checklist is for a Debian 12 or Debian 13 server already in a data hall. It helps you verify the handoff from the facility to your team before you call the server production-ready.

If you bought the hardware yourself or placed it through Hostperl colocation, small mistakes become expensive fast. A port on the wrong VLAN, a loose uplink label, or a missing remote-hands note can delay launch by a full day. For planning around cabinet space, power draw, and carrier handoff points, review colocation power planning for rack growth in 2026 and colocation hosting: what businesses should check first first.

This tutorial starts on the server, then moves through switch validation, routing checks, and recovery steps. You will also finish with a short remote-hands handoff note you can reuse for later moves.

What you need before the first login

• Debian 12 or Debian 13 installed on the colocated server.
• Console or IPMI/KVM access from your data-center provider.
• The public IP, gateway, and netmask provided by the carrier.
• One working SSH key on your local computer.
• A second terminal for testing the new non-root login without closing the original root session.

Use the reserved documentation IP below as an example only. Replace 203.0.113.10 with the public IP assigned to your own server.

Connect as root and confirm the operating system

On your local computer

ssh root@203.0.113.10

203.0.113.10 is a documentation example. Replace it with the real public IP your colocation provider assigned.

On the VPS as root

cat /etc/os-release

This confirms you are on Debian and shows the exact release. You should see ID=debian and a 12.x or 13.x version string. If the server is not Debian, stop here and follow the matching distribution procedure for that platform.

Create the non-root admin account and keep root open

Do not disable root access yet. First create the admin account, verify sudo, and then tighten SSH. For this tutorial, the admin user is deploy.

On the VPS as root

adduser deploy

This creates the deploy account and prompts for a password. If you are using SSH keys only, set a strong temporary password now and disable password login later.

usermod -aG sudo deploy

This grants sudo access through Debian’s sudo group. Confirm the membership.

id deploy

You should see sudo in the group list.

Now create the SSH directory and copy your key. Replace the sample key below with your own public key.

install -d -m 700 -o deploy -g deploy /home/deploy/.ssh
cat > /home/deploy/.ssh/authorized_keys <<'EOF'
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIEexampleKeyReplaceWithYourOwnPublicKey comment@example.com
EOF
chown deploy:deploy /home/deploy/.ssh/authorized_keys
chmod 600 /home/deploy/.ssh/authorized_keys

This creates the key file with safe permissions. The SSH daemon rejects loose permissions, so keep them strict.

Test the new login before changing SSH rules

On your local computer

ssh deploy@203.0.113.10

You should land in the new account without a password prompt if your key is loaded locally. Then test sudo.

On the VPS as the non-root sudo user

sudo -v
sudo whoami
pwd

Successful output should end with root from sudo whoami. Keep the original root session open until this works.

Update the server, time sync, and base tools

Colocation machines often sit longer between maintenance windows, so update first. Debian uses apt, and the package set here stays intentionally small.

On the VPS as the non-root sudo user

sudo apt update
sudo apt full-upgrade -y
sudo apt install -y chrony nftables tcpdump ethtool openssh-server

chrony keeps logs and TLS validation accurate. nftables gives you a clean firewall baseline. tcpdump and ethtool help with switch and link troubleshooting in a cabinet environment.

systemctl enable --now chrony
systemctl status chrony --no-pager

You want to see active (running).

Verify the physical link and switch handoff

Before you blame routing, confirm the NIC has carrier and the expected speed. If you are on a remote console, these checks save time with remote hands.

On the VPS as the non-root sudo user

ip link show
ip addr show
sudo ethtool eth0

Replace eth0 with the real interface name if your hardware uses enp1s0, eno1, or another predictable name. Look for Link detected: yes, the negotiated speed, and the duplex mode.

If the link is down, open a remote-hands ticket with the exact port label and expected switch location. For a practical workflow on facility-side moves, see colocation remote hands workflow for FreeBSD VPS moves. Even though that guide uses FreeBSD, the handoff process and support notes are still useful.

Set the hostname, static IP, and default route

Most colocated servers use a static address. Confirm the host identity, then apply the network values your carrier provided.

On the VPS as the non-root sudo user

hostnamectl set-hostname server.example.com
hostnamectl status

server.example.com is the example hostname. Replace it with your real server name. The status output should show the new static hostname.

Debian on modern systems usually uses systemd-networkd or ifupdown, depending on how the server was installed. For a clean, predictable setup, this tutorial uses a NetworkManager-free /etc/network/interfaces example for a single NIC colocation server.

On the VPS as root

cat > /etc/network/interfaces.d/eth0 <<'EOF'
auto eth0
iface eth0 inet static
    address 203.0.113.10/24
    gateway 203.0.113.1
    dns-nameservers 1.1.1.1 9.9.9.9
EOF

Replace the example IPs with the values from your provider. The /24 prefix and gateway here are documentation values only.

Then validate the file and bring the interface back up carefully. If you are connected through a provider console, this is safe. If you are only on SSH, confirm you have console access before proceeding.

ifdown eth0 2>/dev/null || true
ifup eth0
ip addr show eth0
ip route

Successful output should show the configured address and a default route through the gateway.

Apply a tight firewall without locking yourself out

Open SSH before you activate the default-deny policy. Debian 12 and Debian 13 work well with nftables, and you can still allow remote hands access from a jump host if needed.

On the VPS as the non-root sudo user

sudo nft list ruleset

If the ruleset is empty or minimal, continue.

On the VPS as root

cat > /etc/nftables.conf <<'EOF'
flush ruleset

table inet filter {
  chain input {
    type filter hook input priority 0; policy drop;
    ct state established,related accept
    iif lo accept
    tcp dport 22 accept
    icmp type echo-request accept
    ip6 nexthdr icmpv6 accept
  }

  chain forward {
    type filter hook forward priority 0; policy drop;
  }

  chain output {
    type filter hook output priority 0; policy accept;
  }
}
EOF

This example allows SSH, loopback, established sessions, ping, and basic IPv6 control traffic. If you need additional services later, add them before changing the policy.

Check the syntax first.

nft -c -f /etc/nftables.conf

If the syntax is clean, load and enable it.

systemctl enable --now nftables
systemctl reload nftables
systemctl status nftables --no-pager

Open a second terminal and confirm SSH still works from your local machine before closing the root session.

Check IPv4, IPv6, and carrier reachability

Colocation often exposes routing or upstream filtering issues that never show up in a test VM. Verify both protocol families if your block includes them.

On the VPS as the non-root sudo user

ip -br addr
ip route show
ip -6 route show
ping -c 3 203.0.113.1
ping -c 3 1.1.1.1
ping -6 -c 3 2606:4700:4700::1111

Replace the gateway and IP test targets with values that match your environment. If IPv6 is not assigned, the ping -6 test will fail cleanly, which is expected.

For deeper port and route debugging on Debian, the command patterns in RHEL network diagnostics on a VPS: route and port checks translate well to Debian too, especially for traceroute-style checks and listening port validation.

Harden SSH for the colocation server

Once the new account works, restrict SSH and keep the original console available for recovery. Do not remove root access until you have tested the final login path from a separate terminal.

On the VPS as root

cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak
cat >> /etc/ssh/sshd_config <<'EOF'
PermitRootLogin no
PasswordAuthentication no
KbdInteractiveAuthentication no
PubkeyAuthentication yes
AllowUsers deploy
EOF

Check the configuration before reloading.

sshd -t

If there is no output, the syntax is valid.

Now reload SSH, not restart it, so existing sessions survive.

systemctl reload ssh
systemctl status ssh --no-pager

If your Debian image uses the service name ssh.service, that command is correct. Keep the original root console open until you confirm the new login still works.

Test the handoff like a customer would

This is the part many teams skip. Use the same checks your support desk would use after a server move or cabinet change.

On your local computer

ssh deploy@203.0.113.10
ssh deploy@203.0.113.10 'hostnamectl; ip route; sudo whoami'

The first command opens an interactive session. The second confirms remote command execution and sudo access in one line.

On the VPS as the non-root sudo user

systemctl --failed
ss -tulpn
journalctl -u ssh -n 20 --no-pager
journalctl -u nftables -n 20 --no-pager

You want no failed units, SSH listening on port 22, and clean logs for both services.

Rollback and incident recovery

If you lock yourself out, use the provider console or remote hands and restore the backup copies.

On the VPS as root via console

cp /etc/ssh/sshd_config.bak /etc/ssh/sshd_config
systemctl reload ssh

If the firewall blocks access, disable it temporarily from console, then correct the ruleset.

systemctl disable --now nftables

After recovery, fix the rules and enable it again with nft -c -f /etc/nftables.conf before reloading.

Leave the server ready for the rack

The final step is a simple paper trail. Save the active IP, gateway, interface name, switch port, and remote-hands contacts in your runbook. That record matters the next time a disk fails or a carrier cross-connect needs to be reseated.

If you are deciding whether your next machine should stay in colo or move to a managed platform, compare the operational effort with a Hostperl VPS or a dedicated server. For many customers, the right answer is to keep the hardware in colo only when they really need physical control, predictable power, or custom carrier diversity.

When the server is stable, you can hand it over with confidence. The network is verified, the login path is tested, and you have a recovery route if anything changes after the move.

FAQ

What should I check first on a newly racked colocation server?

Check link status, IP assignment, default route, SSH access, and the switch port label. Those five items catch most launch blockers before they turn into outages.

Why use nftables instead of waiting on a panel or external firewall?

On a bare Debian colocated server, nftables gives you a local control point even if upstream filtering changes. It also makes recovery easier from the console.

Do I need IPv6 on a colocation server?

Only if your provider allocated it or your application needs it. If it is present, test it and include it in your firewall and DNS records.

What if SSH breaks after hardening?

Use the provider console, restore /etc/ssh/sshd_config.bak, and reload ssh. Always test a second login session before closing root access.

How does this help a support team?

It creates a repeatable checklist for remote hands, carrier faults, and launch readiness. That reduces ticket back-and-forth and shortens recovery time.