2026-10-18

SSH and RDP to Customer Servers: Step by Step for MSPs

A managed service provider can administer remote servers over SSH and RDP without opening inbound firewall ports at customer sites. Using prialo WireGuard tunnels, an on-site Linux router advertises the local subnet, which becomes accessible only after explicit administrator approval and per-device route acceptance on technician workstations.

The operational risks of exposing SSH and RDP ports to the Internet

Opening TCP port 22 for SSH or TCP port 3389 for RDP on perimeter firewalls exposes customer networks to automated credential stuffing and port scanners. Maintaining port forwarding rules across multiple customer offices requires dedicated static public IP addresses and intricate NAT rules that quickly become unmanageable for growing service providers.

Centralised hub-and-spoke virtual private networks add unwanted latency by routing internal management traffic through a distant cloud concentrator. Evaluating a private mesh network vs traditional VPN reveals how direct peer-to-peer tunnels allow administrators to connect directly to target systems while maintaining strict cryptographic boundaries.

Prialo mesh architecture and cryptographic connection negotiation

Every device enrolled in prialo maintains its own WireGuard key pair, eliminating shared passwords and usernames across the data transport plane. Each node is assigned a single immutable IP address inside the 100.64.0.0/10 block reserved under RFC 6598, preventing address overlap with conventional 192.168.x.x or 10.x.x.x client subnets.

Direct peer-to-peer connectivity is negotiated via STUN over UDP port 3478 on the control plane using NAT hole punching. When carrier-grade NAT, symmetric firewalls, or intermediate VPNs prevent direct communication, traffic falls back to an encrypted relay listening on TCP port 4430 that blindly forwards packets without possessing the keys to decrypt them.

Control plane orchestration runs over gRPC on TCP port 50051 protected by strict TLS certificate pinning against an SPKI fingerprint formatted as sha256:... Client daemons immediately drop connections to servers that fail to present the exact pinned key, removing certificate authorities from the security model.

4 steps to establish subnet routing and administrative device approval

To administer an entire client subnet without installing software on every target server, the MSP designates a single Linux machine on that LAN as an internal router:

• Enrolling the Linux gateway: the technician provisions the gateway using a one-time enrolment key and the SHA-256 control plane certificate pin.
• Advertising the customer LAN: the gateway executes the route advertisement command specifying the target internal IPv4 CIDR block.
• Administering route approval: an MSP administrator approves the advertised CIDR range explicitly on the control plane for that specific gateway node.
• Accepting routes on technician endpoints: the technician workstation enables route acceptance to route RDP and SSH traffic directly to customer private IPs.

sudo PRIALO_AUTH_KEY='<enrolment key>' prialo install --server=control.example.com:50051 --relay=control.example.com:4430 --tls-pin=sha256:<fingerprint>
prialo up --advertise-routes=192.168.50.0/24
prialo node routes <router> --approve 192.168.50.0/24

Executing prialo status confirms the active connection with 'Control: tls, pinned' and reports the allocated 100.64.0.0/10 IP address. Subnets are never routed automatically across the mesh. Only Linux hosts can act as subnet routers in prialo, and mobile devices or Windows workstations do not yet accept incoming subnet routes.

Comparison of remote management architectures for service providers

Managed service providers evaluate modern mesh networking tools across control plane deployment options, tunneling protocols, and fallback mechanisms:

Self-hosted deployment and data sovereignty for technical teams

Prialo is developed by Sinergia, an independent software company located in Barcelona, Spain, providing compliant invoices under Spanish law. The complete self-hosted package, obtainable from the self-hosted server for Linux, bundles three Docker Compose containers: the gRPC and STUN coordination server, the TCP relay daemon, and a PostgreSQL database.

A standard server with 2 vCPUs and 2 GB of RAM running Docker Engine 24 or newer with Compose v2 on Linux x86_64 or arm64 is sufficient to coordinate hundreds of managed nodes. The administrative API on port 8080 is never published directly to the Internet and must be reached through an SSH tunnel, keeping audit records and credentials strictly private.

Regarding regulatory context, European standards such as the NIS2 Directive (Directive EU 2022/2555), GDPR (Regulation EU 2016/679), and Spain's Esquema Nacional de Seguridad (Real Decreto 311/2022) demand rigorous auditability and data isolation. While prialo holds no certifications under these frameworks, its self-hosted architecture ensures keys and telemetry stay entirely on the customer's hardware.

As of 17 October 2026, the self-hosted server and command-line clients run in production on Linux and macOS, with an early unsupported build available for Windows without installer or signature. Dedicated Mac and iPhone applications are currently in Apple's review queue, while an Android client remains in development.

Would you rather run your own server? Guide to the self-hosted prialo package

← All news