---
title: "Remote access"
description: "See and control an endpoint's screen from the console, with the access mode, consent, recording, and transfer rules your profiles set."
url: "https://support.outpostplatform.com/remote-access/"
product: "depot"
type: "concept"
status: "draft"
ai_summary: "Outpost remote access: sessions relayed and optionally recorded by your Outpost. Access modes come from profiles. Direct connections on every plan; relayed (TURN) on Enterprise and MSP. Clipboard and files are end-to-end encrypted. The viewer has a terminal; FreeBSD and OpenBSD open it terminal only. Windows, Linux, macOS (Preview)."
availability:
  plans: ["home-lab", "essentials", "enterprise", "msp"]
  platforms: ["windows", "linux", "macos"]
  permission: "remote:initiate"
  preview: false
source: "https://gitlab.com/outpostplatform/docs/-/edit/main/src/content/docs/remote-access/index.md"
license: "CC BY 4.0"
---

# Remote access

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](/remote-access/terminal/). For the
standalone console window, see
[Live metrics and the remote console](/endpoints/live-and-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.

:::caution
With no profile restricting it, an endpoint allows every mode, so sessions open
**Unattended**: no prompt and no banner. If the people you support must be told
or asked, set `remote_access.allowed_modes` before you roll out the agent. See
[Configure access modes and consent](/remote-access/access-modes/).
:::

The CJIS, NIST 800-53, NIST 800-171, and CMMC Level 2 baselines remove
**Unattended** from every endpoint they cover. See
[Compliance framework baselines](/compliance/framework-baselines/).

## Direct and relayed connections {#direct-and-relayed}

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](/account/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](/remote-access/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](/remote-access/start-a-session/#verify).
- Recordings are encrypted at rest with a key per recording. See
  [Record remote sessions](/remote-access/session-recording/).

## 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 |
| <kbd>Ctrl</kbd>+<kbd>Alt</kbd>+<kbd>Del</kbd> | 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](/agent/macos/).
For the versions each platform supports, see
[Supported platforms](/get-started/platform-support/).

## 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-access/pioneer-control/). |
| `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](/remote-access/terminal/#permissions). |
| `terminal:layout:manage` | Save and clear an endpoint's default terminal layout. |

See [Roles and permissions](/depot/roles-and-permissions/).

## In this section

- [Start a remote desktop session](/remote-access/start-a-session/)
- [Use the terminal in the remote viewer](/remote-access/terminal/)
- [Configure access modes and consent](/remote-access/access-modes/)
- [Record remote sessions](/remote-access/session-recording/)
- [Clipboard and file transfer](/remote-access/clipboard-and-file-transfer/)
- [Let Pioneer AI control a session](/remote-access/pioneer-control/)
- [Remote access policy settings](/remote-access/policy-settings/)
- [Troubleshoot remote access](/remote-access/troubleshooting/)

## Related

- [Consent prompts and session notices](/tray/consent-and-notifications/)
- [Profiles and policies](/automation/profiles/)
- [Plans and limits](/account/plans-and-limits/)