Remote access

View as Markdown Open in ChatGPT Open in Claude

Remote access lets a technician see and control an endpoint’s screen from the console, copy the clipboard and files in both directions, and open a shell on it. What a session is allowed to do is decided by the profiles that apply to the endpoint, not by the technician who connects. This page explains how a session works, the choices you make about it, and what differs by plan and operating system.

Remote desktop and the remote console

Outpost has two ways into an endpoint:

	Remote desktop	Remote console
What you get	The endpoint’s screen, with mouse and keyboard control	An interactive shell, such as PowerShell or bash
Where you start it	Connect in the endpoint’s page header, Remote > Overview > Connect, or the connect icon in the endpoint list	Terminal in the remote desktop viewer, or Commands > Console > Open terminal on the endpoint
Platforms	Windows, Linux with a display, macOS (Preview)	Windows, Linux, macOS (Preview), FreeBSD, OpenBSD
Permission	`remote:initiate` and the permission for the access mode	`command:execute`
Governed by the remote access settings on this page	Yes	No

Both open in a window of their own, so the endpoint’s screen or shell sits beside the ticket you are working. The remote desktop viewer also has a terminal drawer, so you can work in the screen and a shell side by side. On FreeBSD and OpenBSD, which have no remote desktop, Open terminal opens the viewer as a terminal-only window. The endpoint page header does the same on any endpoint that cannot share its screen, such as a Linux server without a display: its Connect button reads Open terminal. See Use the terminal in the remote viewer. For the standalone console window, see Live metrics and the remote console.

How a session works

Every remote desktop session runs through your Outpost. The endpoint sends its screen to your Outpost, and your Outpost forwards it to the technician’s browser. Keyboard and mouse input travels the same way in reverse. Your Outpost does not transcode the video, but because it sits in the path it can record the session and enforce policy on it.

When a technician selects Connect, your Outpost resolves the endpoint’s remote access policy from every profile that applies to it, then opens the session in the most permissive access mode that policy leaves. There is no mode picker. The endpoint’s Remote tab shows the mode a session will open in, before anyone connects.

The policy is resolved again whenever the person signed in at the endpoint changes during a session, so that person’s policy and consent apply to their desktop.

Access modes

An access mode decides what the person at the endpoint sees and whether anyone has to agree before the session starts. The console names them as follows:

Mode	What the person at the endpoint sees	Before the session starts
Unattended	No prompt and no banner.	Nothing.
Attended	A banner saying a session is in progress. They cannot stop it.	Nothing.
Consent required	A prompt asking permission, then the banner.	The person selects Allow. No answer within the consent timeout (120 seconds by default) denies it.
Escorted	A banner saying the session is supervised.	The technician sees the screen at once, but their input is held until enough escorts, other members of your team, are present.
No remote access	Nothing. No session opens.	Not applicable.

Modes are ordered from least to most restrictive. The setting remote_access.allowed_modes lists the modes allowed on an endpoint, and a session takes the first one allowed in the order above. Two profiles that disagree resolve to the stricter mode, so adding a profile can never widen access.

The CJIS, NIST 800-53, NIST 800-171, and CMMC Level 2 baselines remove Unattended from every endpoint they cover. See Compliance framework baselines.

Direct and relayed connections

A session has two network legs: from the endpoint to your Outpost, and from your Outpost to the technician’s browser. Each leg is a WebRTC connection that carries the video, the input, and the encrypted transfer channels.

Direct connection. The endpoint, or the browser, reaches your Outpost straight over the network, using UDP. WebRTC discovers the addresses to use with a public STUN server, which is how a direct connection crosses ordinary home and office NAT.
Relayed connection. When no direct path works, the leg is carried through a TURN relay server instead. A relay can carry the session over UDP, TCP, or TLS on port 443, which gets through strict NAT, firewalls that block outbound UDP, and guest or hotel networks that allow little more than web traffic. Your Outpost hands each session its own short-lived relay credentials, which expire a few minutes after the session’s authorized time runs out.

A session prefers the direct path and uses the relay only when the direct path fails, so a relay adds latency only where it was the one way through. The Transport row in the viewer’s Statistics panel shows which one the browser’s leg is using: Direct (local network), Direct (STUN), or Relayed.

Relayed connections are included in Enterprise and MSP. Home Lab and Essentials use direct connections only, so a session from or to a network that blocks direct WebRTC traffic does not connect. See Plans and limits.

Relays are available on the Outpost-hosted service. A self-hosted Outpost offers them only when relay servers are configured for it.

Security model

What travels in a session	End-to-end encrypted	Who can read it
Clipboard text, images, and files	Yes, between the technician’s browser and the endpoint	Only the browser and the endpoint. Your Outpost relays ciphertext and holds no key.
Screen video	No. Encrypted in transit on each leg.	Your Outpost, which forwards it and records it when recording is on.
Keyboard and mouse input	No. Encrypted in transit on each leg.	Your Outpost, which forwards it to the endpoint.

Clipboard and file transfers use a key agreement between the browser and the endpoint that your Outpost cannot complete on its own. The endpoint proves its identity with a key that never leaves it, and both ends show the same six-digit Secure transfer code, so a technician can confirm with the person at the endpoint that nothing sits in between. Every transfer is audited by name, size, and hash, according to your policy, without its content. See Clipboard and file transfer.

End-to-end encryption protects transfers from anyone who can read your Outpost’s storage, logs, or backups. It does not protect them from a modified Outpost, which already sees the screen and can send input. Every transfer is listed in the tray app on the endpoint and recorded as an audit event, so that kind of misuse is visible.

Other controls on every session:

Only a technician with remote:initiate and the permission for the session’s access mode can start a session. Your Outpost checks the endpoint’s policy and the technician’s permissions when the session opens and at each change of signed-in user, and records each refusal in the audit log.
Your Outpost signs the session’s mode, time limit, and transfer rules into a token that the agent checks before it shows anything.
Each session is logged with the technician, the person signed in at the endpoint, the mode, the result, and the length. See Start a remote desktop session.
Recordings are encrypted at rest with a key per recording. See Record remote sessions.

Support by operating system

Capability	Windows	Linux	macOS (Preview)	FreeBSD and OpenBSD
Remote desktop	Yes	Yes, on endpoints with a display	Yes	No
Screens you can choose	The console and each Remote Desktop (RDP) session	The console, and other X displays such as xrdp or a VNC server	The console, which is the login window when nobody is signed in	No
All screens on a multi-monitor endpoint	Yes	X11 sessions only	Yes	No
Mouse and keyboard	Yes	Yes. X11 sessions use the X server; Wayland, the sign-in screen, and text consoles need `/dev/uinput`.	Needs the Accessibility permission. Without it, the session is view only.	No
`Ctrl`+`Alt`+`Del`	Yes, except on Server Core	No	No	No
Clipboard sync	Text and images	X11 sessions only	Text and images	No
Type clipboard	Yes	Yes	Yes	No
File transfer	Yes	Yes, when a user is signed in	Yes, when a user is signed in	No
Remote console	Yes	Yes	Yes	Yes
Terminal in the viewer	Yes	Yes	Yes	Yes, in a terminal-only viewer
Terminal as the signed-in user	Yes	Yes	Yes	No

On macOS, remote desktop also needs the Screen Recording permission, which only someone at the Mac can grant. See macOS agent. For the versions each platform supports, see Supported platforms.

Permissions

Permission	What it allows
`remote:initiate`	Start a remote desktop session, list the screens on an endpoint, and see the endpoint’s access mode. A session also needs the permission for its mode.
`remote:unattended`	Open sessions in Unattended mode, and Consent required sessions to the sign-in screen.
`remote:attended`	Open sessions in Attended mode.
`remote:consent`	Open sessions in Consent required mode.
`remote:escorted`	Open sessions in Escorted mode.
`remote:ai_control`	Let Pioneer AI control a session you have open. See Let Pioneer AI control a session.
`remote:read`	Read an endpoint’s remote access history.
`remote:view_recordings`	Play back session recordings.
`remote:escort`	Join an escorted session as an escort.
`command:execute`	Open the terminal in the viewer. See Permissions for the terminal.
`terminal:layout:manage`	Save and clear an endpoint’s default terminal layout.

See Roles and permissions.

In this section

Content is licensed CC BY 4.0. Code samples are MIT. Outpost and the Outpost mark are trademarks of Outpost Business Solutions, PBC and are not covered by either license.