Protocols

What “supported” means

sortOfRemoteNG distinguishes four kinds of protocol surface. This matters because a backend crate, an importer mapping, or a settings form does not by itself make a usable connection tab.

The executable contract is src/utils/session/protocolAvailability.ts. The session manager consults it before creating a direct session, and the regression test tests/session/protocolAvailability.test.ts checks every persisted protocol and every protocol advertised by the primary editor.

Saved connection protocols

ARD and Apple Account authentication

ARD presents three distinct authentication paths, not three interchangeable password formats. A portable profile can keep the macOS-only handoff and one embedded fallback together while preserving that separation:

1. An embedded session can authenticate with an account authorized by the remote Mac, including an eligible local or directory-backed account.
2. An embedded VNC-compatible session can use the dedicated password configured for VNC viewers on the remote Mac. That password must be unique and must not reuse an Apple Account password, a local-user password, or a Remote Desktop administrator password.
3. An Apple Account connection is a macOS-only external handoff. sortOfRemoteNG saves the non-secret Apple Account identifier, opens Screen Sharing.app, and leaves password entry, two-factor authentication, connection approval, and the remote session inside Apple’s process. On Windows, Linux, or a Mac where the native handoff is unavailable, a portable profile resolves to its explicitly selected embedded fallback; without a valid fallback it fails closed.

Sign in with Apple identity tokens are scoped to the application or web service requesting them; they are not ARD/RFB credentials. Apple app-specific passwords likewise do not authenticate ARD/RFB. Apple documents entering an Apple Account in Screen Sharing.app, but does not document a public URL scheme or API for pre-filling an Apple Account connection, so the handoff does not attempt to automate Apple’s authentication UI.

Credential-bearing, full-fidelity JSON exports preserve the saved identifier, fallback selection, and embedded credentials according to the selected storage/export policy. Credential-free JSON exports retain the non-secret fallback selection but omit the Apple Account identifier and generic username/password, so setup may be required after import. Neither JSON export path can contain an Apple Account password or two-factor authentication code because sortOfRemoteNG never receives those values.

Embedded ARD connects directly to the saved host and port. A system VPN can supply reachability, but the protocol does not manage that VPN and rejects app proxy, SSH-hop, and tunnel-chain routing rather than silently bypassing it.

See Apple Screen Sharing and portable ARD access for setup, security boundaries, and the supporting Apple documentation.

Import mappings versus runtime support

The native and vendor importers normalize recognized names into saved connection protocols. For example, RAW variants map to raw, RLogin maps to rlogin, and PowerShell-like entries map to winrm. The shared persistence boundary also maps the legacy postgres alias to canonical postgresql. Those destinations now have interactive clients, but conversion can preserve only fields represented by the source format. Review transport, authentication, trust, and protocol-specific settings after import.

Recognizing a protocol during import still does not widen its runtime capabilities: imported FTP remains passive/EPSV and direct-route only, imported SCP retains its explicit host-key policy and direct-route boundary, and recognizing VNC does not add a raw-TCP RFB bridge. Imported AnyDesk and RustDesk entries still require their installed native clients. See Import, Export & Clone for the review workflow.

Provider and hardware entries

The following persisted values are management identities, not interchangeable terminal or desktop protocols. None currently has a saved-connection panel host, so the active protocol picker does not offer them and a legacy or imported record fails closed with an explicit unavailable message. They never pass through the old timer-based simulated connection path. Provider or hardware command crates and typed hooks are control-plane building blocks, not proof of a reachable application panel.

Service integrations use the separate integration:* descriptor contract and route through src/components/integrations/IntegrationPanelHost.tsx. Their support level belongs to each integration panel and is not inferred from this direct-session matrix.

Audited implementations not exposed as saved direct sessions

These implementations are included in the audit because their hooks, backend crates, or templates can otherwise look like finished protocols.

Verification boundaries

The protocol matrix is checked at three layers:

1. BuiltInConnectionProtocol is exhaustively mapped at compile time. Adding a persisted protocol without declaring its runtime truth fails TypeScript compilation.
2. tests/session/protocolAvailability.test.ts verifies that every primary editor option is client-owned, every built-in direct protocol appears exactly once, and all management-only identities remain absent from the picker.
3. tests/session/SessionViewer.test.tsx verifies that dedicated clients mount during connecting and reconnecting states, before any runtime can honestly report success.

Focused protocol tests cover the transport-specific behavior. FTP verifies native DTOs, redacted credential logging, lifecycle, direct file operations, and fail-closed routing/modes. SCP verifies host-key policy mapping, known_hosts handling, lifecycle, direct file/directory operations, and fail-closed routing. PostgreSQL verifies DTO construction, SSL validation, secret redaction, direct-route rejection, lifecycle/reconnect, typed native values, and command registration. SPICE, XDMCP, X2Go, and NoMachine verify exact native-process launch contracts, secret handling, fail-closed options/routes, reattach, polling, and final close without claiming remote readiness. Raw Socket and RLogin have native Rust end-to-end tests; Telnet verifies native connect/events/exact input; Serial verifies configuration, byte streaming, echo, controls, and cleanup; ARD verifies framebuffer/input and command parity; and PowerShell verifies PSRP over SSH and WSMan. Live WinRM, SSH, FTP/SCP, PostgreSQL, VNC, native-client, and hardware-backed Serial checks remain environment-dependent because they require reachable targets, credentials, local applications, devices, or drivers—an ignored live fixture is not counted as a passing connection.

Choosing a path

• Prefer SSH, RDP, ARD, or PowerShell Remoting for their intended interactive workloads.
• Prefer SFTP for the broadest in-app file-management surface; use FTP/FTPS or SCP when the target specifically requires them and the direct-route limits fit.
• Use PostgreSQL for an isolated native database workbench when a direct target and the configured SSL policy fit.
• Use VNC only when the endpoint is WebSocket-capable or a trusted WebSocket proxy is available.
• Treat AnyDesk and RustDesk as native application handoffs and install their clients first.
• Install virt-viewer, X2Go Client, or NoMachine Client before using SPICE, X2Go, or NX; use their native authentication prompts and treat app status as local-process status only.
• Use XDMCP only on a trusted isolated network after accepting its unauthenticated, unencrypted transport boundary and installing a supported local X server.
• Use Telnet and RLogin only when a legacy system requires them; both expose credentials and traffic unless the surrounding network supplies protection.
• Use Raw Socket only when you understand the target framing and security model.

For routing compatibility, continue to Network Paths. For source boundaries and backend layering, see Architecture.