Architecture Note: Using Vscodium Remote‑SSH for Secure Remote Development

Requirements

To use Vscodium’s Remote‑SSH feature you need a workstation that can run Vscodium (Linux, macOS or Windows) and a remote Linux host reachable via SSH. The remote host must provide:

• glibc ≥ 2.28 (the VS Code Server binary is built against this version)
• Node.js ≥ 14 (the server runs a Node process)
• At least 1 GB of free disk space for the server runtime and extension storage
• SSH daemon listening on port 22 or a custom port, with outbound access allowed from the workstation

On the workstation you only need Vcodium installed and the Remote‑SSH extension from the Open VSX Registry.

Smallest Suitable Design

The design consists of three components:

1. Local Vscodium UI – runs the editor, renders the UI, and forwards user actions (keystrokes, file edits) over an SSH tunnel.
2. SSH Tunnel – a standard SSH connection that multiplexes a channel for the Remote‑SSH protocol; no extra VPN or port‑forwarding is required.
3. VS Code Server – a lightweight headless instance of VS Code that executes on the remote host, provides language services, runs extensions, and serves the file system to the UI.

All source code, build tools, and runtime environments stay on the remote host; only UI events and file edits travel over the tunnel.

Trust and Data Boundaries

Trust is confined to the SSH channel:

• Authentication relies entirely on the user’s SSH key or password; Vscodium never stores credentials.
• The VS Code Server runs with the same privileges as the SSH user; compromising the server gives the attacker exactly what the SSH user can do on the remote host.
• No telemetry or proprietary Microsoft services are contacted; extension metadata is fetched from the Open VSX Registry over HTTPS.

Data boundaries: the remote host’s filesystem is exposed to the UI via the protocol; the UI never writes to the remote disk except through the user‑initiated edit actions.

Operational Checks

Before and during use, verify the following:

1. SSH connectivity – from a terminal run ssh -T user@host (replace user@host with your credentials). Expect a greeting or no output; a timeout or permission error indicates a network or credential issue.
2. Remote dependencies – after connecting, check ldd --version for glibc ≥ 2.28 and node --version for Node ≥ 14.
3. Disk space – run df -h ~/ on the remote host; ensure at least 1 GB free in the home directory or the directory where the server will be installed (~/.vscode-server by default).
4. Extension compatibility – install an extension that has native binaries (e.g., c++ or python linter) and verify it activates without errors in the Output panel (View → Output → Remote‑SSH Log).
5. Telemetry absence – optionally monitor outbound traffic with tcpdump -i any port 443 while using Remote‑SSH; you should see only TLS to the Open VSX Registry and SSH traffic, no requests to vscode.microsoft.com or similar endpoints.

Failure Modes

• SSH link loss – the extension detects a broken tunnel, shows a toast notification, and attempts automatic reconnection. If the tunnel cannot be restored, the UI reverts to a disconnected state and you must run Remote‑SSH: Connect to Host… again.
• VS Code Server crash – the server process may exit due to OOM or a segmentation fault. Vcodium displays an error banner offering to restart the server; the workspace state is preserved because the server stores unsaved edits in memory only until the next checkpoint.
• High latency – round‑trip times > 150 ms cause noticeable typing lag. The extension does not automatically fall back to local editing; you must manually disconnect and open the folder locally.
• Binary mismatch – installing an extension whose native binaries were built for a different libc or CPU architecture results in activation failures visible in the Extension Host log. The remedy is to either use a pure‑JS variant of the extension or rebuild the binary against the remote host’s toolchain.

Conditions That Would Change the Design

Consider revising the minimal design if any of the following become true:

• The remote host cannot run Node ≥ 14 or glibc ≥ 2.28 (e.g., an embedded appliance). In that case you would need to use a different remote‑development mechanism such as sshfs with local editing or a container‑based approach.
• Your organization prohibits outbound SSH (port 22) but allows HTTPS tunneling; you could encapsulate SSH inside an HTTPS proxy or use the Remote‑Tunnels feature (if available) to shift the trust boundary.
• You require GPU‑accelerated workloads on the remote host and the VS Code Server cannot forward graphics; you might then run the UI locally and offload only computation via SSH, or adopt a remote‑desktop solution.
• Policy mandates that no arbitrary code may be executed on the remote host beyond file edits; you would need to restrict the VS Code Server to a read‑only mode or use a language‑server‑only approach.

Practical Example: Adding a Host and Verifying the Server

1. Open Vcodium, press F1, type Remote‑SSH: Add New SSH Host…, and enter ssh -T user@host (replace with actual user and host).
2. When prompted, choose the SSH config file to update (usually ~/.ssh/config). Vcodium will append a block like:

   Host myremote
       HostName example.com
       User alice
       IdentityFile ~/.ssh/id_rsa
   

3. Again press F1, select Remote‑SSH: Connect to Host…, choose myremote, and open a folder.
4. In the lower‑left corner the window title should show [SSH: myremote].
5. On the remote host, run ps -ef | grep code-server; you should see a process similar to /home/alice/.vscode-server/bin/.../code-server --host 0.0.0.0 --port 0.
6. Edit a file, save, and confirm the change appears instantly on the remote disk via cat /path/to/file.
7. To test failure, disconnect the network or run pkill -f code-server on the remote host; Vcodium will show a reconnection banner and, after the network returns or the server restarts, restore the workspace.