Skip to content
Avanet
My account
My account

Loading …
Customer portal Account settings

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 Access RDP agentlessly via Protected Browser and Access SSH agentlessly via Protected Browser. 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 a web 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 My Products > ZTNA, and policy objects and web policies under My Products > 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 Internal FQDN/IP address of the resource; External 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 posture: Grünes Windows
  • Application group: Agentenlose RDP-Gruppe or Agentenlose SSH-Gruppe
  • Web 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 My Products > ZTNA > Policies.
  2. Click Add policy.
  3. Under Add policy, select Agentless. Other ZTNA views also identify this as access without an agent. A prompt requesting an agent applies to the agent-based path; this policy does not require an agent.
  4. On New policy, enter a name such as Agentenloser Zugriff.
  5. Open Policy enforced and enable Policy is enforced.
  6. Click Save.

The Agent ZTNA policy type and its tunnels are outside this procedure. The global Agent tunnel inactivity timeout 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 Minimum time before device health triggers a rule setting.

Add RDP or SSH resource

Open My Products > ZTNA > Resources & Access and click Add Resource. Complete the form with the values for the required protocol.

RDP resource

  1. For example, enter Agentenloses RDP as Resource name. A description is optional.
  2. Choose the gateway that can reach rdp01.intern.example.
  3. Under Access method, select Agentless.
  4. Select the Agentenloser Zugriff policy.
  5. For Resource type, 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 Internal FQDN/IP address of the resource. An external FQDN cannot be added for this resource type.
  7. Under Assign User Groups, move only the required pilot group from the available groups to Assigned User Groups.
  8. Click Save.

SSH resource

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

  1. Resource name: for example Agentenloses SSH.
  2. Access method: Agentless.
  3. Policy: Agentenloser Zugriff.
  4. Resource type: SSH. Port 22 and access port type TCP are set automatically and cannot be changed.
  5. Internal FQDN/IP address of the resource: for example ssh01.intern.example; an external FQDN is not available.
  6. Assign User Groups: move only the intended pilot group to Assigned User Groups and then Save.

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 Agentless. If an additional device check is required, configure it in the Protected Browser web policy.

Limit Protected Browser access

Create optional device posture

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

  1. Open My Products > Protected Browser > Policy objects.
  2. Click Add object > Device posture.
  3. Enter Grünes Windows as the name.
  4. Under OS platform, select Windows.
  5. Under Endpoint Protection, select Check if device is protected by Sophos Endpoint, followed by the Green health status.
  6. Click Save.

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 My Products > Protected Browser > Policy objects.
  2. Click Add object > Application group.
  3. Enter a unique name, such as Agentenlose RDP-Gruppe.
  4. Expand ZTNA resources.
  5. Under Available, select the resource created earlier and move it to Assigned.
  6. Click Save.

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

Add web policy

  1. Open My Products > Protected Browser > Web policy and select the Policies tab.
  2. Click Add policy.
  3. Enter a unique name, such as Agentenloser RDP-Zugriff von Windows-Systemen mit grüner Integrität.
  4. Make sure Allow is selected.
  5. If used, select the device posture Grünes Windows.
  6. Select the Agentenlose RDP-Gruppe application group.
  7. Click Save.

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 + New 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 Connect.

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 the SSH icon in the toolbar.
  2. Select + New 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 Connect.

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 File Transfer > Upload for the upload. To download, use the download symbol for the desired entry.
  • SSH: Open the control at the bottom and select File Transfer > Upload To Folder 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 File scanned successfully 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 + New 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 Assign User Groups?
  3. Is the correct ZTNA resource in the application group under Assigned?
  4. Does the web policy that permits access use this exact application group?
  5. Does the test device meet the optional device posture, specifically Windows, Sophos Endpoint and Health status Green?

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 for gateway instance token for the affected instance under Gateway > Gateway Details, and share it only for a specific case with a deliberately short expiry.

Access only fails with activated device posture

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 web policy without a device posture, while keeping the user group narrowly restricted.

File is not uploaded

An upload only takes place after a successful scan. If the message File scanned successfully 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 My Products > ZTNA > Policies. On the Policy enforced tab, bypass the dedicated policy. 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 Policy is enforced 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 web policy. The respective owner then removes the assignments and objects in dependency order. Without an approved, product-specific deletion procedure, 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 web 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.