DPTCloud
Back to articles
Technology Insight

Building a Zero Trust VPS for Remote Teams: A Practical Guide with Teleport, Tailscale, and Cloudflare Tunnel

May 19, 2026

Introduction: The Imperative for Zero Trust in Remote Work

The shift to remote and hybrid work models has fundamentally altered the security landscape for organizations worldwide. Traditional perimeter-based security, which assumed trust for anyone inside the corporate network, is obsolete when your team is distributed across cities, countries, and continents. This reality demands a new paradigm: Zero Trust. The core principle is simple yet powerful: never trust, always verify. Every access request, whether from inside or outside the perceived network, must be authenticated, authorized, and encrypted.

For teams managing their own infrastructure, such as a Virtual Private Server (VPS), implementing Zero Trust is not just a best practice; it's a critical necessity. A VPS exposed to the public internet with only password-based SSH is a prime target. This guide provides a practical, step-by-step framework for building a "Zero Trust VPS"—a secure bastion for your remote team's development, databases, and internal tools. We will architect this using three powerful, complementary tools: Teleport for privileged access management, Tailscale for a seamless private network, and Cloudflare Tunnel for secure, inboundless web service exposure.

Understanding the Zero Trust Architecture for a VPS

Before diving into implementation, it's essential to understand the security model we are building. A traditional setup might open SSH port 22 to the world (or a limited IP range) and use port forwarding for internal web apps. Our Zero Trust model dismantles this.

  • No Open Inbound Ports: The VPS firewall denies all unsolicited inbound connections. There is no public SSH port (22) or application port (e.g., 3000, 8080) listening on the internet.
  • Identity-Centric Access: Access to any resource (SSH, database, web app) is gated by strong, cryptographically verifiable identity. This replaces IP-based allowlists.
  • Least Privilege Enforcement: Users and services receive only the minimum permissions necessary to perform their tasks.
  • Encrypted Tunnels Everywhere: All communication, both for management and application traffic, occurs over encrypted tunnels established by trusted clients.

This architecture significantly reduces the attack surface, moving your critical infrastructure from a publicly addressable target to a hidden resource accessible only to explicitly authorized entities.

Phase 1: Foundational VPS Setup and Hardening

Begin with a clean VPS instance from a provider like DigitalOcean, Linode, AWS Lightsail, or Hetzner. Choose a modern Linux distribution such as Ubuntu 22.04 LTS or Rocky Linux 9.

Initial Security Hardening

After first login via your provider's console or temporary SSH key, immediately implement baseline hardening.

  1. Create a Sudo User: Avoid using the root account. Create a dedicated administrative user and add it to the sudo group.
    adduser deployer && usermod -aG sudo deployer
  2. Configure SSH Key Authentication: Disable password authentication for SSH. Copy the public keys of all team members to the new user's ~/.ssh/authorized_keys file. This is a temporary measure until Teleport is fully deployed.
    In /etc/ssh/sshd_config, set:
    PasswordAuthentication no
    PubkeyAuthentication yes
  3. Set Up a Basic Firewall: Use ufw (Uncomplicated Firewall) to deny all incoming traffic by default. We will not open ports for SSH or apps here.
    sudo ufw default deny incoming
    sudo ufw default allow outgoing
    sudo ufw enable
  4. Automatic Security Updates: Enable unattended security patches.
    sudo apt install unattended-upgrades && sudo dpkg-reconfigure --priority=low unattended-upgrades

At this stage, your VPS is accessible only via SSH key to the 'deployer' user. The next phases will replace this SSH access with a more robust system and lock down the firewall completely.

Phase 2: Implementing Teleport for Privileged Access and SSH

Teleport is a unified access plane for SSH, Kubernetes, databases, and web applications. It provides certificate-based authentication, session recording, and granular access controls. For our VPS, it will become the only way to obtain SSH access.

Installing and Configuring the Teleport Node

First, install the Teleport server component (the "Node") on your VPS. You will also need a Teleport cluster. For simplicity, we will use Teleport Team's free cloud-hosted cluster as the "Auth Server," but you can also self-host.

  1. Follow the official instructions to install the Teleport binary on your VPS.
  2. Join your VPS to your Teleport Team cluster. This command, provided in the Teleport Team web console, will look like:
    sudo teleport node join --token=<join-token> --auth-server=teleport.example.com:443
  3. Once joined, the Teleport service will start. It creates a reverse tunnel to the cloud cluster. Your VPS no longer needs a public SSH port.

Accessing the VPS via Teleport

Team members install the tsh CLI tool and log in to the Teleport cluster (tsh login --proxy=teleport.example.com). They can then access the VPS via:
tsh ssh deployer@<vps-teleport-node-name>

Key Benefits: Access is now gated by your Identity Provider (like Google Workspace or GitHub). Sessions are recorded and auditable. You can define RBAC roles (e.g., "developer" can SSH, "admin" can sudo). The VPS's own SSH daemon is now only listening on localhost, accessible solely via the Teleport tunnel.

Phase 3: Building a Private Mesh Network with Tailscale

While Teleport handles SSH, your team likely needs to access other services: a PostgreSQL database (port 5432), a Redis cache (port 6379), or a staging web app (port 3000). Opening these ports is not an option. This is where Tailscale excels.

Tailscale creates a secure WireGuard-based mesh network between all your devices and servers. Each entity gets a private, static IP address (like 100.x.y.z). Traffic between them is encrypted end-to-end.

Integrating Tailscale with the VPS

  1. Install Tailscale on the VPS using its package manager.
  2. Authenticate the VPS to your Tailscale network:
    sudo tailscale up --authkey=<tskey-auth-...> (Generate a reusable auth key from the Tailscale admin console).
  3. The VPS will appear in your Tailscale admin console. You can apply ACLs (Access Control Lists) to define which users or devices can talk to which ports on the VPS.

Practical Application

Now, a developer can run a local application that connects to the VPS's PostgreSQL database using the Tailscale IP (postgresql://[email protected]:5432/dbname). The connection is direct, encrypted, and invisible to the public internet. You can configure the VPS firewall to only allow traffic from the Tailscale interface (tailscale0).

Tailscale effectively makes your VPS a part of a private, software-defined network that spans all your team's laptops and cloud resources, enforcing identity-based access at the network layer.

Phase 4: Securely Exposing Web Services with Cloudflare Tunnel

What about internal web applications (like GitLab, Metabase, or a custom admin panel) that need to be accessed via a browser? We could use Tailscale, but browser access requires the Tailscale client. Cloudflare Tunnel (part of Cloudflare Zero Trust) offers a more elegant, inboundless solution for web traffic.

A Cloudflare Tunnel creates an outbound-only connection from your VPS to Cloudflare's global edge. There is no need to open a public port on your VPS. Traffic from users to Cloudflare is secured by Cloudflare's proxy, and then routed through the tunnel to your internal service.

Setting Up a Tunnel to Your Web App

  1. Install the cloudflared daemon on your VPS.
  2. Authenticate it with your Cloudflare account (cloudflared tunnel login).
  3. Create a tunnel and route it to a local service, for example, a web app running on port 8080:
    cloudflared tunnel create my-tunnel
    cloudflared tunnel route dns my-tunnel app.internal.yourdomain.com
    cloudflared tunnel run my-tunnel     (Configured to proxy to localhost:8080).

Now, when a user visits https://app.internal.yourdomain.com, the request hits Cloudflare. You can then place Cloudflare Access rules in front of it, requiring SSO login via your company's IdP, multi-factor authentication, or device posture checks. Only after passing these Zero Trust checks is the request sent through the encrypted tunnel to your VPS.

Phase 5: Integration and Final Security Lockdown

The final step is to weave these components together and achieve the promised "zero open ports" state.

Firewall Final Configuration

Update your VPS firewall (ufw) rules. The only allowed inbound traffic should be:

  • From the Tailscale interface (sudo ufw allow in on tailscale0). This allows internal service traffic.
  • The outbound connections initiated by Teleport and Cloudflare Tunnel do not require inbound rules.

Explicitly deny all other inbound traffic. You can now close the standard SSH port 22 on the public interface, as all SSH access flows through Teleport's tunnel.

Architecture Summary

  • SSH Access: User → Teleport Cloud (Auth) → Teleport Tunnel → VPS (Local SSH).
  • Private Service Access (DB, Redis): User/Device → Tailscale Network (WireGuard) → VPS (Tailscale IP).
  • Web Application Access: User → Cloudflare Edge (Access Policies) → Cloudflare Tunnel → VPS (Local Web App).

The VPS itself has no public listening ports. It only makes outbound connections to Teleport and Cloudflare, and accepts inbound connections on its private Tailscale interface.

Operational Considerations and Best Practices

Implementing this architecture requires ongoing management.

  1. User Onboarding/Offboarding: Leverage your Identity Provider. Removing a user from the company Google Group should automatically revoke their access in Teleport, Tailscale, and Cloudflare Access.
  2. Backup and Recovery: Ensure you have a secure, automated backup process for VPS data. The backup destination should also be protected by Zero Trust principles (e.g., an S3 bucket with object lock, accessed via IAM roles).
  3. Monitoring and Logging: Centralize logs from Teleport (audit events), VPS (system logs), and application logs. Use the monitoring features of each tool to detect anomalous access patterns.
  4. Cost Management: The tools mentioned have free tiers suitable for small teams. Monitor usage as you scale to anticipate costs for Teleport Team, Tailscale, and Cloudflare Zero Trust.

Conclusion: Embracing a Secure Future for Remote Infrastructure

Building a Zero Trust VPS is an investment in your team's security posture and operational resilience. By combining Teleport for privileged access, Tailscale for private networking, and Cloudflare Tunnel for secure web publishing, you create a defense-in-depth architecture that neutralizes common attack vectors like exposed SSH ports and vulnerable web applications.

This model aligns perfectly with the reality of modern, distributed work. Security is no longer bound to a physical office network; it follows identity and context. While the initial setup requires careful planning, the long-term benefits—reduced risk, improved auditability, and a seamless experience for your remote team—are substantial. Begin by implementing one component at a time, starting with Teleport to secure SSH, and gradually evolve your VPS into a truly Zero Trust stronghold for your digital operations.