3.4 SSH Proxy, No-Decrypt Policy & Decryption Exclusions

3.4 SSH Proxy, No-Decrypt Policy & Decryption Exclusions

Why the Blueprint Names Four Decryption Dispositions

Blueprint task 1.3 asks you to "explain the use of decryption on Strata and SASE products" and then enumerates exactly four dispositions: SSL Forward Proxy, SSL Inbound Inspection, SSH Proxy, and no decrypt. Sections 3.1 through 3.3 covered the two SSL proxies. This section closes the remaining two, and they are the ones candidates skip. SSH Proxy is the only decryption type that needs no certificate infrastructure at all, and "no decrypt" is not the absence of policy — it is an explicit, loggable, enforceable rule action with its own profile controls.

---

SSH Proxy Architecture

SSH Proxy decryption places the firewall between an SSH client and an SSH server so that attackers cannot use Secure Shell to tunnel unwanted applications and content past inspection.

The Key Difference: No Certificates

SSH Proxy requires no certificate configuration whatsoever. The firewall automatically generates the key used for SSH decryption when the firewall boots up. That single key serves every virtual system configured on the firewall, and it is used for all SSH version 2 sessions. There is no Forward Trust CA to build, no PKI to distribute, and no private key to import.

   Client                         Firewall (SSH Proxy)                    Server
      |                                   |                                 |
      |--- 1. SSH connection request ---->|                                 |
      |                                   |--- 2. Firewall opens its own -->|
      |                                   |       SSH session to server     |
      |<-- 4. Firewall inserts its own ---|<-- 3. Server key response ------|
      |       auto-generated SSH key      |                                 |
      |                                   |                                 |
      |==== SESSION A (client<->FW) ======|==== SESSION B (FW<->server) ====|
      |                                   |                                 |
      |     Firewall inspects the CHANNEL TYPE of every channel it sees     |

Two separate, independently encrypted SSH sessions exist. The firewall terminates one and originates the other, which is precisely what lets it read channel metadata in the middle.

Channel-Type Inspection Is the Enforcement Mechanism

When an SSH Decryption profile is applied, the firewall examines the App-ID of the traffic for each channel in the connection and identifies the channel type:

Tunneling channels are blocked, and the remaining traffic is restricted according to the configured Security policy. In App-ID terms this is the difference between ssh and ssh-tunnel: SSH Proxy is what allows PAN-OS to tell one from the other reliably rather than inferring it from port or volume heuristics.

Exam Trap Alert: The firewall cannot decrypt traffic inside an SSH tunnel. It does not read the tunnelled HTTP, RDP, or database payload and then apply Content-ID to it. It identifies the channel as tunneling and blocks the channel. Any answer claiming that SSH Proxy gives you threat inspection of port-forwarded payloads is wrong.

The Public-Key Authentication Side Effect

This is the single most operationally disruptive property of SSH Proxy, and it is prime exam material. After you enable SSH decryption, authenticating to hosts that use certificate/public-key authentication fails. Because the firewall terminates and re-originates the session, the SSH client no longer performs public-key based authentication directly against the real server, so the server cannot use a public key that the client decrypts with its private key to complete the handshake.

The remediation is not "turn off SSH Proxy globally." It is to configure the SSH Decryption policy rule to exclude the systems that require public key authentication — for example, automation jump hosts, Git servers, and CI/CD runners that authenticate with key pairs, while still proxying interactive administrator SSH to production network devices.

Other Documented SSH Proxy Constraints

• Interfaces: decryption is only performed on virtual wire, Layer 2, or Layer 3 interfaces. Tap and HA interfaces cannot decrypt.
• SSH version: the supported SSH version is SSH version 2. Legacy SSHv1 is treated as an unsupported version.
• QoS: when SSH Proxy is configured, the proxied traffic does not support DSCP code points or QoS. If a design depends on DSCP marking preservation for SSH, SSH Proxy will break it.
• High availability: the firewall does not HA-sync decrypted SSL sessions, and decrypted SSL Forward Proxy, SSL Inbound Inspection, and SSH Proxy sessions do not resume after a failover. Administrators reconnect.

---

Configuring SSH Proxy

Policies > Decryption > Add
  Source / Destination / User / Service    -> define the SSH traffic to proxy
  Options tab:
      Action = Decrypt
      Type   = SSH Proxy
      Decryption Profile = <profile>   (optional, but a best practice)
  Commit

1. Verify that the relevant interfaces are virtual wire, Layer 2, or Layer 3 under Network > Interfaces > Ethernet.
2. Create the Decryption policy rule that defines which traffic to decrypt.
3. Set the rule Action to Decrypt and the rule Type to SSH Proxy.
4. Attach a Decryption profile. Profiles are technically optional, but the documented best practice is to attach one to every Decryption rule so that weak, vulnerable protocols and algorithms cannot carry questionable traffic through your network.
5. Commit, then add Decryption Exclusions for anything that must not be proxied.

The SSH Proxy Tab of a Decryption Profile

Note the design asymmetry: the SSH Proxy tab has no certificate checks, because there are no certificates. Everything it can enforce is a protocol-hygiene or resource-exhaustion decision.

---

The "No Decrypt" Disposition

A rule with Action = No Decrypt is a deliberate, auditable statement that a class of traffic will traverse the firewall encrypted. Enterprises use it for three categories of reason:

1. Legal and regulatory — works councils, banking secrecy, and healthcare privacy regimes that forbid inspecting employee financial, medical, or legal traffic.
2. Technical — applications that break when proxied because they use certificate pinning or mutual (client) certificate authentication. PAN-OS publishes a "List of Applications Excluded from SSL Decryption" for exactly this class.
3. Performance and risk-based scoping — decrypting everything indiscriminately is resource intensive. A common design decrypts high- and medium-risk URL categories and traffic to critical servers first, and applies No Decrypt to low-risk, high-volume categories.

No Decrypt Is Still Enforceable

Placing traffic in a No Decrypt rule does not mean the firewall is blind to it:

• Server certificate verification for undecrypted traffic can still be applied through the Decryption profile's No Decryption tab, blocking sessions whose server certificate is expired or whose issuer is untrusted. The firewall reads the certificate during the handshake even when it never decrypts the body.
• SNI, certificate subject, cipher suite, and TLS version remain visible, so App-ID can still classify the session as ssl plus, where possible, a specific application, and URL filtering can still act on the domain.
• Decryption logs are still generated. Enabling Log Successful SSL Handshakes and Log Unsuccessful SSL Handshakes in the Decryption policy rule gives you the visibility needed to audit what is being excluded and why.

Exam Trap Alert: "No decrypt" and "no Decryption rule matched" are not equivalent in every respect. Both leave the payload encrypted, but only an explicit No Decrypt rule can carry a Decryption profile that enforces certificate checks and consistent handshake logging. Design guidance is to write explicit No Decrypt rules rather than relying on the absence of a match.

---

Decryption Exclusions

PAN-OS supports two complementary exclusion mechanisms, and confusing them is a classic error.

The predefined list is applied globally by hostname before policy evaluation and is refreshed by content updates, so it self-heals as vendors change their pinning behaviour. A No Decrypt policy rule is the right tool when the exclusion is driven by who or what category rather than by a specific breaking hostname — for example "do not decrypt the financial-services and health-and-medicine URL categories for any user."

---

Putting the Four Dispositions Together

A realistic enterprise decryption rulebase reads top to bottom:

1. No Decrypt   : URL category financial-services, health-and-medicine  (privacy)
2. No Decrypt   : source group = executives, category legal             (works council)
3. SSH Proxy    : source = admin-jump-net, destination = network-mgmt-zone
                  EXCLUDE hosts requiring public-key auth (rule 3a above it)
4. SSL Inbound  : destination = dmz-web-servers  (certificate + key imported)
5. SSL Forward  : source = trust zone, destination = any (catch-all)

Rule order matters exactly as it does in Security policy: more specific rules must precede general ones, because Decryption policy rules are compared against traffic in sequence and the first match wins.