Remote Development Protocols

How SSH Powers CDEs

SSH (Secure Shell) provides the encrypted transport layer that most CDE platforms use for IDE-to-workspace communication. When a developer opens VS Code Remote SSH or connects via a terminal, the SSH protocol handles authentication, encryption, channel multiplexing, and data integrity verification.

The protocol operates over TCP port 22 by default, though CDE platforms commonly remap this to avoid conflicts. SSH version 2 (the only version still considered secure) negotiates encryption algorithms during the handshake, typically settling on AES-256-GCM or ChaCha20-Poly1305 for data confidentiality.

• Authentication: Public key, certificate-based, or SSO-bridged via ProxyCommand
• Channel multiplexing: Multiple logical channels over a single TCP connection
• Port forwarding: Local, remote, and dynamic (SOCKS5) forwarding for service access
• Keep-alive: ServerAliveInterval and ClientAliveInterval for connection resilience

SSH Configuration for CDEs

CDE platforms like Coder inject custom SSH configurations that route connections through their control plane. Instead of connecting directly to a workspace IP address, the SSH client uses a ProxyCommand that authenticates with the CDE API and establishes a tunneled connection to the correct workspace.

This approach has several advantages: workspaces do not need public IP addresses, the CDE platform handles identity verification through its own SSO integration, and connections can be audited at the control plane level before reaching the workspace.

# Typical CDE SSH config (auto-generated)
Host coder-workspace-*
    ProxyCommand coder ssh --stdio %h
    StrictHostKeyChecking no
    UserKnownHostsFile /dev/null
    LogLevel ERROR
    ServerAliveInterval 30
    ServerAliveCountMax 3
    Compression yes

The ProxyCommand pattern allows CDE platforms to inject authentication and routing without requiring developers to manage SSH keys manually.

Microsoft's proprietary protocol is the backbone of Windows-based CDE solutions like Microsoft Dev Box. RDP streams rendered UI from a remote Windows desktop, with optimizations for font smoothing, bitmap caching, and audio redirection. It uses TCP port 3389 by default and supports TLS encryption.

RDP's bandwidth requirements are significantly higher than protocol-level solutions like VS Code Remote SSH, typically consuming 1-5 Mbps for a smooth experience. However, it is the only option for .NET developers who need full Visual Studio (not VS Code) or other Windows-native GUI tools.

VNC uses the Remote Framebuffer (RFB) protocol to stream pixel updates from a remote desktop. Unlike RDP, VNC is platform-agnostic and works on Linux, macOS, and Windows. Coder supports VNC-based desktop access through noVNC, which wraps the VNC protocol in WebSocket for browser access.

VNC is less bandwidth-efficient than RDP because it sends raw pixel data (with optional compression). However, modern implementations like TigerVNC and TurboVNC include JPEG compression and adaptive encoding that bring bandwidth usage closer to RDP levels. VNC is commonly used for Linux desktop CDE workspaces.

Solutions like Apache Guacamole provide clientless remote desktop access by proxying RDP, VNC, and SSH connections through a web browser. Guacamole translates these protocols into its own Guacamole protocol, which is delivered over WebSocket to the browser where HTML5 Canvas renders the desktop.

This approach is particularly useful for CDE deployments where installing native RDP or VNC clients is not possible, such as managed Chromebooks or locked-down corporate laptops. The tradeoff is an additional protocol translation layer that adds 5-15ms of latency.