RustDesk Session Consent
When a technician opens a RustDesk session to a managed machine, Athena can require the person sitting at that computer to allow the session first. This is a server-side consent gate you control centrally: turn it on for the whole fleet, then override it per machine where you need different behavior. If the person declines, nobody answers, or the computer can’t show a prompt, the session is refused before the technician sees anything.
This page covers the consent gate for the RustDesk path. The built-in WebRTC technician screen-share already asks for on-screen approval by default; whether that path prompts is controlled separately by Unattended Access. The two settings are independent.
Why RustDesk needs its own consent gate#
RustDesk has its own approval mode, but in an Athena deployment it usually doesn’t prompt anyone. With Approval Mode set to a password (the default) and every managed machine carrying an Athena-provisioned RustDesk password, RustDesk simply accepts the password and connects — so its built-in prompt never fires. Athena’s consent gate closes that gap: it makes the server ask the person at the machine before the RustDesk session is brokered, regardless of RustDesk’s own approval mode. It is a policy enforced by the server and is never pushed to the endpoint as a RustDesk option.
Requiring consent fleet-wide#
Go to Settings → Agents → Remotes and open the RustDesk security section. The checkbox labelled “Ask the person at the computer first” is the fleet-wide default. Turn it on to require consent for every RustDesk session across the fleet, or off to connect without asking. The change takes effect for the next session — there is nothing to restart and nothing to install on the endpoints.
This fleet-wide value is the default: individual machines can be set to always ask or never ask regardless of it (see Per-machine override below).
Older agents can’t answer the prompt. Consent works only with agent builds new enough to raise the on-screen prompt. If you switch the fleet-wide requirement on while some machines are still on older builds, sessions to those machines will be refused because they can’t show a prompt. Leave the fleet-wide requirement off until your agents are up to date, and use the per-machine override to switch it on selectively in the meantime.
Per-machine override#
Each machine can override the fleet-wide default in either direction. Open the target machine from the fleet list, go to its RustDesk section, and use the “Ask before connecting” selector. It has three choices:
| Choice | What it does |
|---|---|
| Inherit the fleet setting (default) | Follow the fleet-wide requirement. The option label shows what inheriting currently means — asking or not asking — so you don’t have to open Settings to check. |
| Always ask on this computer | Require consent for this machine even if the fleet-wide default is off. |
| Never ask on this computer | Skip the prompt for this machine even if the fleet-wide default is on. |
The per-machine choice always wins over the fleet-wide default. Choosing Inherit clears the override so the machine follows the fleet again. “Inherit” and “Never ask” are deliberately different: inherit tracks whatever the fleet setting is, while never ask is a fixed decision for that one machine.
The per-machine selector is shown to Operators and Admins. Deciding whether a person is asked before their screen is viewed is a management action, so it requires the same permission as the REST call behind it.
What the person at the machine sees#
When consent is required, the server asks the target machine to display a prompt naming the technician, and waits for an answer. The session is brokered only if the person explicitly allows it. Every other result refuses the session, and the technician is shown a plain-language reason next to the Connect button:
| Outcome | Result | What the technician is told |
|---|---|---|
| Allowed | Session proceeds. | — |
| Declined | Refused. | The person at that computer declined the session. |
| No answer | Refused after the prompt times out. | Nobody answered the prompt on that computer, so the session was not started. |
| Unreachable | Refused — the machine couldn’t be asked (offline, or the request failed). | That computer could not be asked for permission, so the session was not started. |
| Can’t prompt | Refused — the machine was reached but couldn’t raise a prompt (nobody signed in, or an agent too old to show one). | That computer could not show a permission prompt — there may be nobody signed in. The session was not started. |
The prompt waits about 25 seconds for an answer before it counts as no answer and the session is refused.
Consent fails closed. If consent is required but the server can’t determine the machine’s override for any reason, it errs on the side of asking rather than skipping. A transient problem never becomes a way around a consent requirement.
Reconnecting during a live session#
Once someone has allowed a session, a brief network blip that drops and re-establishes the same live session doesn’t re-prompt them every time. A single grant can cover a small number of automatic reconnects of that same session (up to three) before consent must be sought again, so a flaky link doesn’t nag the user — while a genuinely new session still requires a fresh yes.
REST API#
The per-machine override is also available over the REST API, so you can set
it in bulk (for example, always-ask across every workstation) instead of clicking through each machine.
It requires the Operator or Admin role and returns 404
when the agent ID isn’t found. On success it returns the updated agent.
| Action | Endpoint | Role |
|---|---|---|
| Set (or clear) a machine’s consent override | POST api/agents/{id}/rustdesk-consent | Operator / Admin |
The request body is the tri-state requireConsent field:
# Always ask on this machine
POST /api/agents/550e8400-e29b-41d4-a716-446655440000/rustdesk-consent
{ "requireConsent": true }
# Never ask on this machine
POST /api/agents/550e8400-e29b-41d4-a716-446655440000/rustdesk-consent
{ "requireConsent": false }
# Inherit the fleet setting (clear the override)
POST /api/agents/550e8400-e29b-41d4-a716-446655440000/rustdesk-consent
{ "requireConsent": null }
The null value clears the override so the machine inherits the fleet-wide default again
— which is not the same as false (a fixed “never ask” for that machine).
Auditing#
Both changing the policy and enforcing it are recorded in the audit trail:
- Override changes — setting a machine to always ask, never ask, or inherit is audited with the operator who made the change and the target machine, so the setting has a clear history.
- Refused sessions — when a RustDesk session is refused for lack of consent, the audit record captures the specific reason (declined, no answer, unreachable, or couldn’t prompt), so a refusal is meaningful when you review it later.
Recommendations#
- Roll it out after your agents are current. Turn the fleet-wide requirement on only once your machines run agent builds that can show the prompt, or you’ll refuse sessions to older ones. Use the per-machine override to pilot on a few up-to-date machines first.
- Ask on user workstations, skip on unattended machines. Require consent where a person is present, and set Never ask on servers, kiosks, and signage that have nobody at the screen — a required prompt on an unmanned machine only produces a “couldn’t prompt” refusal.
- Pair it with recording where appropriate. Consent tells the user a session is starting; Session Recordings keeps a record of what happened during it.
- Remember it’s RustDesk-only. This gate governs RustDesk sessions. For the built-in WebRTC screen-share, whether a machine prompts is controlled by Unattended Access.
See also#
- RustDesk Remote Access — enabling and configuring the RustDesk integration.
- Unattended Access — the equivalent consent control for WebRTC screen-share.
- Remote Commands & Desktop — starting remote sessions.
- Session Recordings — recording sessions and the per-machine record policy.
- Agent Tags — grouping machines to apply the override in bulk.
- Audit & SIEM — where override changes and refused sessions are recorded.