Skip to content
Avanet

Agentless RDP and SSH access with Sophos Protected Browser

Sophos Workspace Protection

Sophos Protected Browser provides access to internal RDP and SSH hosts without a ZTNA agent on the user device. Sophos lists these two use cases under Agentenlose RDP-Anwendungen and Agentenlose SSH-Anwendungen. Access remains limited to Protected Browser: a connection created as an agentless RDP or SSH resource cannot be opened with a standard RDP or SSH client.

The secure process is the same for both protocols. First, establish identity, gateway and connectivity. Then create an agentless ZTNA policy and one resource for each host. Add that resource to an application group in Protected Browser and permit it with an internet policy. Test only after these steps, using a small user group.

Requirements, license and roles

The following points must be met before configuration:

  • The Protected Browser is installed on a supported Windows or macOS device. The example below uses a Windows device with a green health status.
  • Users and groups are synchronised, an identity provider is set up, and a ZTNA gateway is operational.
  • The gateway can reach the internal RDP or SSH host. This connection is checked before the resource is created.
  • The smallest possible user group exists for the resource. A shared object for all employees is unsuitable for administrative access.
  • The person carrying out the procedure can manage policies and resources under Meine Produkte > ZTNA, and policy objects and internet policies under Meine Produkte > Protected Browser.

The product information approved for this procedure does not specify a role name or a separate licence SKU. Do not assume that a visible menu proves authorisation, and do not grant broad super-admin rights. Before making changes, confirm in your tenant that ZTNA and Protected Browser are available and that the administrator account can create the required objects. If a page or button is missing, ask the tenant’s licence or role owner to investigate before continuing.

Local Gateway and Sophos Cloud Gateway are possible ZTNA deployment modes. Their provisioning, user and identity synchronization, domains, certificates and DNS are part of the common ZTNA foundation. The correct order is explained Setting up Sophos ZTNA. This guide intentionally does not repeat these common procedures.

Confirm DNS and certificates first

The gateway domain, certificate, and required public and internal DNS resolution must already be working. The ZTNA owner sets up this common basis in accordance with the linked ZTNA instructions; it is neither duplicated nor changed here.

The RDP and SSH resources described here use a dedicated form: enter the address in Interner FQDN/IP-Adresse der Ressource; Externen FQDN is not available. Do not copy general DNS examples for ZTNA web applications into this field. The ZTNA owner must prepare the domains and certificates before the RDP or SSH resource is created.

Prepare example values

The following names make related objects recognizable. They are not a product specification and must be adapted to your own naming convention:

  • ZTNA policy: Agentenloser Zugriff
  • RDP resource: Agentenloses RDP
  • SSH resource: Agentenloses SSH
  • Device status: Grünes Windows
  • Application group: Agentenlose RDP-Gruppe or Agentenlose SSH-Gruppe
  • Internet policy: Agentenloser RDP-Zugriff von Windows-Systemen mit grüner Integrität or the SSH variant
  • Internal host: for example rdp01.intern.example or ssh01.intern.example

An FQDN is easier to manage than a changing IP address, but it must resolve correctly from the gateway. When testing both protocols, create separate resources and application groups so that assignments, validation and later decommissioning remain traceable.

Add agentless ZTNA policy

An existing agentless policy can be reused if its scope is appropriate. A dedicated pilot policy, however, reduces the risk of unintentionally affecting production resources.

  1. Open Meine Produkte > ZTNA > Richtlinien.
  2. Click Richtlinie hinzufügen.
  3. Under Richtlinie hinzufügen, select Agentenlos. Other ZTNA views call this type Ohne Agent. The Agent anfordern prompt applies to the agent-based path; this policy does not require an agent.
  4. On Neue Richtlinie, enter a name such as Agentenloser Zugriff.
  5. Open Richtlinie durchgesetzt and enable Richtlinie wird durchgesetzt.
  6. Click Speichern.

The Agent ZTNA policy type and its tunnels are outside this procedure. The global Zeitüberschreitung wegen Inaktivität des Agent-Tunnels setting applies to the agent tunnel; it is not an RDP or SSH session timer for Protected Browser. If the wider environment uses device health, the ZTNA owner should still be aware of the global Mindestzeit, bevor die Geräte-Integrität eine Regel auslöst setting.

Add RDP or SSH resource

Open Meine Produkte > ZTNA > Ressourcen und Zugriff and click Ressource hinzufügen. Complete the form with the values for the required protocol.

RDP resource

  1. For example, enter Agentenloses RDP as Ressourcenname. A description is optional.
  2. Choose the gateway that can reach rdp01.intern.example.
  3. Under Zugriffsmethode, select Agentenlos.
  4. Select the Agentenloser Zugriff policy.
  5. For Ressourcentyp, select RDP. Port 3389 and access port type TCP are set automatically and cannot be changed in this form.
  6. Enter the internal host in Interner FQDN/IP-Adresse der Ressource. An external FQDN cannot be added for this resource type.
  7. Under Benutzergruppen zuweisen, move only the required pilot group from Verfügbar to Zugewiesen.
  8. Click Speichern.

SSH resource

For SSH use the same flow with these protocol specific values:

  1. Ressourcenname: for example Agentenloses SSH.
  2. Zugriffsmethode: Agentenlos.
  3. Richtlinie: Agentenloser Zugriff.
  4. Ressourcentyp: SSH. Port 22 and access port type TCP are set automatically and cannot be changed.
  5. Interner FQDN/IP-Adresse der Ressource: for example ssh01.intern.example; an external FQDN is not available.
  6. Benutzergruppen zuweisen: move only the intended pilot group to Zugewiesen and then Speichern.

Agent-based resources and web apps provide other capabilities. For example, the agent can evaluate device health in the ZTNA access policy and control local apps. In this procedure, the resource remains Ohne Agent. If an additional device check is required, configure it in the Protected Browser internet policy.

Limit Protected Browser access

Create optional device status

Adding a device status is optional. Without this object, the pilot group should be particularly narrow. For the documented example with managed Windows devices:

  1. Open Meine Produkte > Protected Browser > Richtlinienobjekte.
  2. Click Objekt hinzufügen > Gerätestatus.
  3. Enter Grünes Windows as the name.
  4. Under OS-Plattform, select Windows.
  5. Under Endpoint Protection, select Prüfen, ob Gerät durch Sophos Endpoint geschützt ist, followed by the Grün health status.
  6. Click Speichern.

Additional checks increase security, but can also exclude more devices. Each additional condition is therefore first tested with the pilot group.

Create application group

  1. Remain in Meine Produkte > Protected Browser > Richtlinienobjekte.
  2. Click Objekt hinzufügen > Anwendungsgruppe.
  3. Enter a unique name, such as Agentenlose RDP-Gruppe.
  4. Expand ZTNA-Ressourcen.
  5. Under Verfügbar, select the resource created earlier and move it to Zugewiesen.
  6. Click Speichern.

For SSH, create Agentenlose SSH-Gruppe and assign Agentenloses SSH. Separate groups prevent a later SSH access change from inadvertently affecting RDP access.

Add internet policy

  1. Open Meine Produkte > Protected Browser > Internetrichtlinie and select the Richtlinien tab.
  2. Click Richtlinie hinzufügen.
  3. Enter a unique name, such as Agentenloser RDP-Zugriff von Windows-Systemen mit grüner Integrität.
  4. Make sure Zulassen is selected.
  5. If used, select the device status Grünes Windows.
  6. Select the Agentenlose RDP-Gruppe application group.
  7. Click Speichern.

For SSH, create the corresponding policy with the SSH application group. This makes the protocol and device condition covered by each access grant clear.

Check connection and expected result

Begin with exactly one authorised user and a device that meets the selected device condition.

Test RDP

  1. Start Sophos Protected Browser and sign in.
  2. In the top toolbar, click the Remote Desktop Connection icon, then click + Neuer Host.
  3. Assign a display name and, under Host, enter the same internal FQDN or IP address used by the ZTNA resource. Port 3389 is set automatically.
  4. Enter the user name and password of the target system and click on Verbinden.

The test is successful if the remote desktop session is opened in the Protected Browser. A normal RDP client is not a valid cross-check because agentless RDP resources are only accessible via the Protected Browser.

Test SSH

  1. Start Protected Browser, sign in and click SSH-Symbol in the toolbar.
  2. Select + Neuer Host, assign a display name and enter the SSH resource value under Host. Port 22 is set automatically.
  3. Enter the user name and password of the target system and click on Verbinden.

The test succeeds when the SSH session opens in the browser. Then perform a negative test with a user outside the assigned group and confirm that access is denied.

Verify file transfer

Once the connection has been established, different controls are used depending on the protocol:

  • RDP: Expand the top menu and select Dateiübertragung > Hochladen for the upload. To download, use the download symbol for the desired entry.
  • SSH: Open the control at the bottom and select Dateiübertragung > In Ordner hochladen to upload a file. Use the download icon to download a file.

During the pilot, use only a harmless test file that contains no confidential data. Uploaded files are scanned and transferred only if they are clean. An upload succeeds when Datei erfolgreich gescannt appears, followed by the upload confirmation. Test downloads separately: the selected file must arrive intact on the test device and open successfully.

Troubleshoot by symptom

RDP/SSH action is missing or a manually created host does not connect

Check the following in order:

  1. Was + Neuer Host selected using the RDP or SSH symbol and the exact internal FQDN or the IP address of the associated resource entered under Host?
  2. Is the test user a member of the group selected under Benutzergruppen zuweisen?
  3. Is the correct ZTNA resource in the application group under Zugewiesen?
  4. Does the internet policy that permits access use this exact application group?
  5. Does the test device meet the optional device status, specifically Windows, Sophos Endpoint Protection and Health status Grün?

Changes to a ZTNA user group can take up to an hour to become visible on the gateway. Do not create new objects immediately while the group change is still pending.

If the manually entered host is correct, check whether the selected gateway can reach the target host. RDP always uses TCP 3389, and SSH always uses TCP 22; a service on any other port is incompatible with these resource types.

If the error persists, escalate the investigation to the ZTNA owner. Configure support-token expiry in the global ZTNA settings. Create the Sophos-Support für Gateway-Instanz token for the affected instance under Gateway > Gateway-Einstellungen, and share it only for a specific case with a deliberately short expiry.

Access only fails with activated device status

Do not remove the device condition from a production policy without control. First compare the pilot device’s platform, endpoint protection and reported health status with the Grünes Windows object. For an isolated comparison, use a separate pilot internet policy without a device status, while keeping the user group narrowly restricted.

File is not uploaded

An upload only takes place after a successful scan. If the message Datei erfolgreich gescannt is missing or the file is not rated as clean, the upload is not considered successful. Instead of bypassing the scan, use a harmless test file and escalate the failed scan with time, user, target host and file name.

Safe rollback and offboarding

The approved product information does not document a complete deletion procedure for every Protected Browser object involved. Therefore, do not treat deletion of the gateway, DNS, certificates or shared policies as a rollback.

For an immediate, reversible access stop, open a dedicated ZTNA policy under Meine Produkte > ZTNA > Richtlinien. On the Richtlinie durchgesetzt tab, set it to Richtlinie umgangen. In this state, users cannot access the resources managed by this policy.

Before making the change, confirm that only the intended RDP or SSH resources are assigned to the policy. Then use the pilot account to verify that the connection can no longer be established. To restore access, return the same dedicated policy to Richtlinie wird durchgesetzt and repeat the connection test. If other resources use the policy, stop before changing it and hand the task to the ZTNA owner.

To permanently decommission, first document the resource, gateway, policy, user groups, application group and Internet policy. The respective owner then removes the assignments and objects in dependency order. Without a shared, product-specific deletion flow, the safe limit is reached before shared ZTNA, DNS, or certificate objects are deleted.

Operation and lifecycle

At least each time there is a change to user groups, gateways, internal hostnames or device conditions, a positive and negative test is repeated. In addition, the owner should regularly check:

  • whether the RDP and SSH hosts are reachable from the gateway’s perspective;
  • whether only required groups are assigned;
  • whether resources, application groups and Internet policies still clearly belong together;
  • whether domains and certificates are valid and assigned to the correct gateway;
  • whether the global minimum time for device health rules matches the desired behaviour;
  • whether every generated support token has expired or been removed as soon as it is no longer needed.

Agentless RDP and SSH resources remain a separate access path. Changes to agent tunnel timeouts or agent-based rollout therefore do not replace a new check in the Protected Browser. Likewise, this guide does not imply any transition, retirement or end-of-life dates. After a product change, the owner must check the settings currently visible in the tenant and run the pilot procedure again.