Overview

Though SonicWall Cloud Secure Edge (CSE) allows security policies to be applied at the granularity of a single SSH Server, organizations often manage multiple SSH servers, sometimes thousands, at a time. While some SSH servers require a unique set of access restrictions, many of them require identical access restrictions. Rather than configure each SSH server individually, you can group them and configure via a single service definition.

CSE uses standards-compliant HTTP Connect Tunnelling to enable connectivity to multiple services via a single SSH service definition.

In the desktop app, the end user selects Connect, which adds an entry to the SSH config file with an SSH ProxyCommand to direct traffic to banyanproxy.

1. When the user runs ssh user@host, traffic is automatically sent by the SSH client to banyanproxy running in HTTP Connect mode.

2. banyanproxy initiates an MTLS connection with the CSE service on the Netagent side at sshcollection.example.com:8443. Netagent checks the device posture and identity and, if successful, establishes the MTLS session. banyanproxy then uses HTTP Connect to specify the actual destination of the SSH request.

3. Netagent checks the Service Backend configurations for the httpconnect and allow_pattern settings. If the connection request matches, Netagent makes the connection to the backend.

Once the connection is established, communication from the SSH client is as if it were directly connected to SSH server.

Prerequisites

• A registered Access Tier or Connector, behind which your SSH server exists
• A registered domain that resolves to this Access Tier

Steps

In this doc, we lay out how to secure access to a collection of SSH servers, using the following steps:

Step 1: Create a Role and a Policy
Step 2. Register a Service
Step 3. Connect to the service through Banyan's desktop app

Notes

Role-based Authorization

To enable role-based authorization for your SSH servers, review our SSH Certificate Authentication capability, which leverages SSH's native AuthorizedPrincipals capability.

Include & Exclude Backends in your Collection #

Advanced Use Cases with Complex Patterns

For advanced use cases that require complex patterns, you can create a custom Hosted Service JSON to specify CIDRs and IP Ranges in an "allow list" in the service spec. This lets you manage allow lists that include and exclude specific backends in your collection.

For example, you can define the pattern for the allowed backends using hostnames (via allow_patterns). In the example below, connections are allowed only the service destination is in the CIDR range 10.10.34.0/24.

"backend": {
  "target": {},
  "allow_patterns": [
    {
      "cidrs": [
        "10.10.34.0/24"
      ]
    }
  ]
}