ExamFinch.com My Study

Study guide

3.4 SSH Proxy, No-Decrypt Policy & Decryption Exclusions

Practice this exam

Palo Alto Networks Certified Network Security Professional Exam

Track your progress as you read

Finished sections get a check mark.

1 Chapter 1: PAN-OS Architecture, Interfaces & Routing

1.1 Security Zones, Virtual Routers & Interface Types 1.2 Advanced Routing Engine, Logical Routers & Dynamic Routing 1.3 High Availability Architecture, Links & Failover Mechanics

2 Chapter 2: PAN-OS Core Policy, App-ID & NAT

2.1 App-ID Classification Engine & Application Management 2.2 User-ID Architecture, Identity Mapping & Group Enforcement 2.3 Security Policy Enforcement & NAT Architecture

3 Chapter 3: SSL/TLS Decryption Architecture & Policy

3.1 SSL Forward Proxy Architecture & Enterprise PKI 3.2 SSL Inbound Inspection, Server Certificates & TLS 1.3 3.3 Decryption Policy, Decryption Profiles & Decryption Broker 3.4 SSH Proxy, No-Decrypt Policy & Decryption Exclusions

4 Chapter 4: Cloud-Delivered Security Services (CDSS) & Threat Prevention

4.1 Advanced Threat Prevention & Security Profiles 4.2 Advanced WildFire & Inline Machine Learning Models 4.3 Advanced URL Filtering & DNS Security 4.4 Device Security (IoT), Device-ID & IoMT Visibility 4.5 Enterprise SaaS Security: Discovered Apps, Data Security & SSPM

5 Chapter 5: Prisma Access Infrastructure & Network Onboarding

5.1 Prisma Access Cloud Architecture & Multi-Tenant Fabric 5.2 Remote Networks (RN) Onboarding & Branch Routing 5.3 Mobile Users (MU) Architecture, Locations & Dedicated IPs

6 Chapter 6: ZTNA 2.0, Cloud Identity & Digital Experience

6.1 ZTNA Connector Architecture & Private Application Publishing 6.2 Cloud Identity Engine (CIE) & Modern Authentication 6.3 Autonomous Digital Experience Management (ADEM) & Enterprise DLP

7 Chapter 7: Strata Cloud Manager (SCM) & AI-Driven Management

7.1 Strata Cloud Manager (SCM) Architecture & Cloud Control Plane 7.2 Unified Policy Hierarchy, Folders & Snippets 7.3 Configuration Push Preview, Validation & Migration Pathways 7.4 Strata Copilot & AIOps for NGFW

8 Chapter 8: Prisma SD-WAN & Branch Edge Architecture

8.1 Prisma SD-WAN ION Devices & Branch Topologies 8.2 Application-Defined Fabric (AppFabric) & Path Policies 8.3 Prisma SD-WAN & Prisma Access CloudBlade Integration 8.4 PAN-OS SD-WAN Subscription, Link Tags & Path Quality

9 Chapter 9: GlobalProtect, Cloud NGFW & AI Runtime Security

9.1 GlobalProtect Remote Access Architecture & Gateways 9.2 Host Information Profile (HIP) & Dynamic Split Tunneling 9.3 Cloud NGFW & Virtual Firewall Architecture (AWS, Azure & Containers) 9.4 AI Runtime Security & Generative AI Protection 9.5 Explicit Proxy, Prisma Access Browser & Remote Browser Isolation

10 Chapter 10: Packet Processing Architecture & System Troubleshooting

10.1 PAN-OS Single-Pass Parallel Processing (SP3) Architecture & Packet Flow 10.2 Operational Troubleshooting CLI Commands & Packet Diagnostics 10.3 High Availability Troubleshooting, System Maintenance & Log Forwarding

11 Chapter 11: Panorama, Subscriptions, Digital Trust & Quantum Readiness

11.1 Panorama Architecture, Device Groups & Template Stacks 11.2 CDSS Subscriptions, Premium GlobalProtect & License Lifecycle 11.3 Next-Generation Trust Security (NGTS) & Certificate Lifecycle 11.4 Quantum Security Risks & Post-Quantum Readiness

3.4 SSH Proxy, No-Decrypt Policy & Decryption Exclusions

Key Takeaways Explain This Topic AI

SSH Proxy requires no certificates: the firewall automatically generates the SSH decryption key at boot, and that key serves every virtual system and all SSH version 2 sessions.

SSH Proxy enforces by channel type — session channels are treated as allowed SSH such as SFTP or SCP, while X11, forwarded-tcpip, and direct-tcpip channels are identified as tunneling and blocked; the firewall cannot decrypt traffic inside an SSH tunnel.

Enabling SSH decryption breaks public-key authentication, so hosts that require key-based SSH login must be excluded in the Decryption policy rule rather than disabling SSH Proxy entirely.

An explicit No Decrypt rule still supports server certificate verification for undecrypted traffic, blocking expired certificates and untrusted issuers, and still writes decryption logs when successful and unsuccessful SSL handshake logging is enabled.

Decryption is only supported on virtual wire, Layer 2, and Layer 3 interfaces, SSH-proxied traffic loses DSCP and QoS support, and decrypted sessions are not HA-synchronized and do not resume after failover.

Last updated: September 2026

  • 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.

Disposition Direction Certificates required What the firewall sees Primary purpose

SSL Forward Proxy Outbound (internal client → internet server) Forward Trust and Forward Untrust CA certificates Full plaintext of the session Inspect user traffic to the internet

SSL Inbound Inspection Inbound (internet client → your server) A copy of the server's certificate and private key Full plaintext of the session Protect published servers

SSH Proxy Both inbound and outbound None Channel types only, not tunnel payload Stop SSH being used as a covert tunnel

No decrypt Either None TLS handshake metadata only (SNI, certificate, cipher) Legal, privacy, or technical exclusion

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:

  • SSH channel type Firewall interpretation Result
  • session Legitimate interactive shell or file transfer such as SFTP or SCP Identified as allowed SSH traffic
  • X11 X11 display forwarding Identified as SSH tunneling
  • forwarded-tcpip Remote port forwarding ( ssh -R ) Identified as SSH tunneling
  • direct-tcpip Local or dynamic port forwarding ( ssh -L , ssh -D ) Identified as SSH tunneling

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

Verify that the relevant interfaces are virtual wire, Layer 2, or Layer 3 under Network > Interfaces > Ethernet .

Create the Decryption policy rule that defines which traffic to decrypt.

Set the rule Action to Decrypt and the rule Type to SSH Proxy .

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.

Commit, then add Decryption Exclusions for anything that must not be proxied.

The SSH Proxy Tab of a Decryption Profile

Setting group Setting Effect

Unsupported Mode Checks Block sessions with unsupported versions Terminates the session when the client hello is a version PAN-OS does not support (anything other than SSHv2)

Unsupported Mode Checks Block sessions with unsupported algorithms Terminates the session when the client or server specifies an algorithm PAN-OS does not support

Failure Checks Block sessions on SSH errors Terminates the session when SSH application errors occur

Failure Checks Block sessions if resources not available Terminates the session when the firewall has no free decryption resources

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:

Legal and regulatory — works councils, banking secrecy, and healthcare privacy regimes that forbid inspecting employee financial, medical, or legal traffic.

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.

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.

Mechanism Where Scope Maintained by

Predefined SSL Decryption Exclusions Device > Certificate Management > SSL Decryption Exclusion Hostnames of applications known to break decryption (pinned certificates, mutual authentication) Palo Alto Networks, delivered through content updates

Custom SSL Decryption Exclusions Same page, administrator-added entries Your own internal or partner hostnames You

No Decrypt policy rule Policies > Decryption Any policy construct: source, destination, user, URL category, service You

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.