Operations
Agent-routed remote access
Open a shell on a device in inventory without standing VPN privileges or a master key on a jump host. Remote access is coming soon for general availability.
Coming soon: open interactive SSH and experimental desktop sessions through the same edge agents you use for monitoring—short-lived certificates, RBAC, and targets from inventory policy instead of freeform bastion keys.
Same edge path as monitoring
Interactive sessions ride the topology you already operate for discovery and telemetry: browser to ServiceRadar to agent-gateway to edge agent to the target. There is no parallel remote-access plane that security has to review twice.
- SSH to Linux hosts and VMs through the assigned edge agent
- SSH-backed Proxmox VE host shells on the same path
- Targets come from inventory and policy, not freeform host fields
- Agents only need reach to the devices they already manage
Short-lived certificates, not standing keys
The enterprise model is short-lived OpenSSH user certificates backed by your identity provider, ServiceRadar RBAC, and an edge agent that can reach the target. Sign in with SSO, get policy-checked, receive a certificate for one session.
- OIDC or SAML SSO required for certificate issuance
- Signer issues certificates with principals, target restrictions, and TTL
- CA private key stays in the control-plane signer boundary—not on agents or browsers
- Prefer certificates over agent-local reusable SSH private keys
RBAC decides who can open what
Viewing a device does not grant a shell. Remote access uses dedicated permissions so helpdesk, operators, and admins see only the actions they are allowed to take.
- devices.remote_access.ssh.open for generic SSH
- devices.console.open for Proxmox-style console entry points
- Separate grants for experimental desktop/RDP when enabled
- Session tickets are short-lived, single-use, and audited
Desktop and RDP as a separate track
Graphical desktop access uses the same remote-access plane but a dedicated media path for screen updates. RDP is experimental and optional: base agents stay the default fleet install, and RDP-capable artifacts are only deployed where desktop sessions should be offered.
- Registered Windows targets with fixed upstream and agent scope
- Control plane policy for TLS/NLA, credential mode, and redirection
- Credentials stay out of browser storage and persisted session metadata
- Not generally available until connector readiness criteria are met
What is foundation vs still coming
Treat broad enterprise remote access as coming soon for general availability. SSH and Proxmox host-shell foundations are the current product path; native Proxmox guest consoles, SFTP, database, Kubernetes, and application access are follow-ups.
- Foundation: agent-routed SSH and host shells with certificate model
- Experimental: optional RDP/desktop with feature flags and special agents
- Later: native guest consoles and broader access protocols
- Enablement is deployment-specific and feature-flagged
FAQs
Is remote access generally available today?
Treat it as coming soon for broad GA. SSH and Proxmox host-shell foundations exist as product paths; RDP remains experimental until readiness criteria are met. Enablement is feature-flagged per deployment.
Can users type any IP and open a session?
No. Targets are registered and bound to agents that can reach them. The browser does not choose upstream host, port, credential secret, or route at launch.
Where do long-lived SSH private keys live?
Prefer not to use them. Certificates are issued per session from a CA held in the signer boundary. Transitional brokered keys stay encrypted centrally and release only for one approved session.
Is RDP the same feature as SSH?
Same plane, different workflow. RDP uses a dedicated desktop media path, optional agent artifacts, and separate RBAC. It is experimental and not generally available yet.
Where are the deep technical docs?
Operator checklists, SSH CA setup, credential models, and target policy live in the Remote Access docs .