Mastering SSH Proxy on Palo Alto Networks Firewalls for Enhanced Security

Introduction to SSH Proxy in PAN-OS

Secure Shell (SSH) is a ubiquitous protocol for secure remote login, command execution, and file transfer. However, its encrypted nature can be exploited by malicious actors to create covert channels for command-and-control (C2) communication, data exfiltration, or tunneling other protocols, bypassing traditional security controls. Palo Alto Networks Next-Generation Firewalls (NGFWs) address this challenge with the SSH Proxy feature.

SSH Proxy in PAN-OS enables the firewall to act as a "man-in-the-middle" (MITM) for SSH sessions. It decrypts SSH traffic, allowing for inspection by App-ID and enforcement through Security policies. This capability is crucial for identifying and blocking unauthorized SSH tunneling (e.g., X11 forwarding, TCP port forwarding) and detecting applications or threats attempting to hide within SSH encryption.

     
      CRITICAL (Palo Alto Networks):
     
     The primary goal of SSH Proxy is not to inspect the content of interactive shell commands or files being transferred in real-time (like Antivirus profiles do for other protocols), but rather to identify and control the *types* of SSH channels and embedded applications. It prevents SSH from being used as an unchecked, encrypted bypass for other network restrictions.

How SSH Proxy Works in PAN-OS

When SSH Proxy is configured for specific traffic via a Decryption policy:

The Palo Alto Networks firewall intercepts the SSH connection initiated by a client to a server.
The firewall establishes its own SSH session to the destination server, essentially acting as an SSH client from the server's perspective.
Simultaneously, the firewall acts as an SSH server to the original client, presenting its own SSH proxy host key.
The firewall decrypts traffic from the client, inspects it (primarily using App-ID to identify SSH channel types like session , X11 , forwarded-tcpip , direct-tcpip ), and applies Security policies.
If allowed, the firewall re-encrypts the traffic and forwards it to the server (and vice-versa for server responses).

Automatic Key Generation: The Palo Alto Networks firewall automatically generates a unique RSA key pair specifically for its SSH Proxy functionality during boot-up. This key is used when the firewall presents itself as an SSH server to the client. There is no need to manually manage or upload SSH certificates for this feature, unlike SSL Forward Proxy.

Impact on SSH Host Key Verification: Because the firewall is intercepting the SSH session, the client will see the firewall's SSH proxy host key instead of the actual server's host key. This will likely trigger a host key mismatch warning on the SSH client if the client has previously connected to the server directly. Users may need to be educated about this, or accept the new host key.

     
      PCNSE/PCNSA Exam Note (Palo Alto Networks):
     
     Understand that SSH Proxy is a form of active decryption. The Palo Alto Networks firewall does not use the server's private key. Instead, it terminates the client's SSH session and initiates a new one to the server, bridging the two. This is why clients see the firewall's host key.

Supported PAN-OS Versions and Platforms

SSH Proxy functionality is available on all Palo Alto Networks PA-Series, VM-Series, and CN-Series firewalls running supported PAN-OS versions (e.g., PAN-OS 9.1, 10.0, 10.1, 10.2, 11.0 and later). Always refer to the specific PAN-OS release notes for the most current information on features and capabilities.

Prerequisites for SSH Proxy Configuration

PAN-OS License: SSH Proxy is a core feature and does not typically require a separate license beyond the base PAN-OS.
Supported Interface Types: SSH Proxy decryption is supported on traffic traversing interfaces configured in Virtual Wire , Layer 2 , or Layer 3 mode on Palo Alto Networks firewalls. It is not supported on Tap mode interfaces (as they cannot actively intercept and modify traffic) or Tunnel interfaces (decryption for tunnel content usually happens before/after tunnel processing).
Zone Configuration: Interfaces involved in the SSH traffic flow (source and destination) must be assigned to appropriate Security Zones. Policies (Decryption and Security) are applied based on these zones in PAN-OS.

     
      Gotcha! (Palo Alto Networks):
     
     Attempting to configure SSH Proxy on a Palo Alto Networks firewall for traffic not passing through a supported interface type (Virtual Wire, L2, L3) will result in the proxy not engaging, and traffic will pass through undecrypted (or be blocked if no matching allow rule exists).

Key Palo Alto Networks Concepts for SSH Proxy

Decryption Policy

The Decryption Policy is the cornerstone for enabling SSH Proxy in PAN-OS. A Decryption Policy rule identifies the specific SSH traffic that the Palo Alto Networks firewall should decrypt. Key parameters for an SSH Proxy Decryption rule:

Source/Destination Zones and Addresses: Define the scope of traffic to be decrypted based on Palo Alto Networks zone-based architecture.
Service: Typically set to service-ssh or a custom service object for TCP port 22. Can also use the ssh application if you want to ensure it's actually SSH traffic before attempting decryption, though service-based matching is common here.
Action: Must be set to Decrypt .
Type: Must be set to SSH Proxy . This distinguishes it from SSL/TLS decryption types in PAN-OS.

Decryption Profile (SSH Proxy specific settings)

A Decryption Profile can be attached to an SSH Proxy Decryption rule in PAN-OS to control various parameters of the SSH handshake and protocol. This allows for granular control over the security aspects of the proxied SSH connections. Navigate to Objects > Decryption > Decryption Profile in the PAN-OS GUI, add a new profile, and select the "SSH" tab.

Key settings within a Palo Alto Networks SSH Decryption Profile:

Block unsupported versions: Block SSHv1 if only SSHv2 is desired.
CRITICAL (Palo Alto Networks): SSHv1 is insecure and should always be blocked if possible. Enabling this option in the Palo Alto Networks SSH Decryption Profile is a best practice.
Server Authentication: This section in the Decryption Profile is less relevant for standard SSH host key validation (which is implicit in the proxied connection) and more for SSL/TLS contexts, but options exist. For SSH Proxy, the primary focus is on protocol versions and algorithms.
Unsupported Mode Checks: Block sessions using algorithms or modes deemed weak or unsupported.
- Key Exchange Algorithms (KEX): Block weak KEX methods (e.g., diffie-hellman-group1-sha1).
- Encryption Ciphers: Block weak ciphers (e.g., 3des-cbc, arcfour).
- Message Authentication Codes (MACs): Block weak MACs (e.g., hmac-md5).
- Server Host Key Algorithms: Block connections to servers presenting weak host key types (e.g. ssh-dss). This refers to the key type presented by the *actual backend server* to the firewall.

If no Decryption Profile is attached to the SSH Proxy rule, the Palo Alto Networks firewall uses default SSH proxy settings which are generally secure but may not align with specific organizational compliance requirements.

     
      PCNSE/PCNSA Exam Note (Palo Alto Networks):
     
     Remember that Decryption Profiles for SSH Proxy on Palo Alto Networks firewalls allow you to enforce cryptographic standards for the proxied connections. You can block outdated SSH versions or weak algorithms. This is a key control point.

App-ID Integration

Once SSH traffic is decrypted by the Palo Alto Networks SSH Proxy, the firewall's App-ID technology inspects the decrypted flow. App-ID can identify the specific type of SSH channel being used, such as:

ssh : Standard interactive shell sessions, SFTP, SCP.
ssh-tunnel : Indicates generic SSH tunneling, which often encapsulates X11 forwarding, local port forwarding ( direct-tcpip App-ID function), or remote port forwarding ( forwarded-tcpip App-ID function). App-ID will often classify these as ssh-tunnel .
Specific applications that might tunnel over SSH (if discernible patterns exist and Palo Alto Networks has signatures for them).

This identification by App-ID is crucial for creating targeted Security policies on the Palo Alto Networks firewall.

Security Policy

After decryption and App-ID classification by the Palo Alto Networks firewall, Security Policies are evaluated to determine whether to allow or deny the traffic. This is where the actual enforcement happens based on the identified application. For example, you might have:

A Security Policy rule allowing the ssh application from trusted sources to specific servers.
A Security Policy rule explicitly denying the ssh-tunnel application network-wide or for specific user groups to prevent unauthorized tunneling.

     
      Gotcha! (Palo Alto Networks):
     
     Simply enabling SSH Proxy via a Decryption policy on a Palo Alto Networks firewall does not automatically block SSH tunnels. You MUST configure corresponding Security policy rules to deny traffic identified by App-ID as
     
      ssh-tunnel
     
     or other unwanted applications within the SSH flow.

Step-by-Step Configuration in PAN-OS (GUI)

Configuring SSH Proxy on a Palo Alto Networks firewall involves creating a Decryption Profile (optional but recommended), a Decryption Policy rule, and appropriate Security Policy rules. These steps are based on PAN-OS 11.0, but are generally applicable to recent PAN-OS versions.

1. Verify Interface and Zone Configuration

Navigate to Network > Interfaces in the PAN-OS GUI. Ensure the interfaces that will carry the SSH traffic are configured as Virtual Wire, Layer 2, or Layer 3.
Navigate to Network > Zones . Ensure these interfaces are assigned to appropriate Security Zones.

2. Create/Configure a Decryption Profile for SSH Proxy (Recommended)

Go to Objects > Decryption > Decryption Profile .
Click Add or clone an existing profile.
Name the profile (e.g., SSH-Proxy-Strict-Profile ).
Protocol Version Checks:
- Tick Block unsupported versions .
- Tick Block SSHv1 connections (Highly Recommended).
Unsupported Mode Checks: For each category (Key Exchange, Encryption Ciphers, MAC Algorithms, Server Host Key Algorithms), select the algorithms you want to block . Best practice is to block known weak or legacy algorithms. Consult Palo Alto Networks documentation or security guidelines for current recommendations.
Click OK .

3. Create a Decryption Policy Rule

Go to Policies > Decryption .
Click Add .
General Tab:
- Name the rule (e.g., Decrypt-Outbound-SSH ).
- Optionally, add a description and tags.
Source Tab:
- Specify Source Zones (e.g., trust ).
- Specify Source Addresses (e.g., any or specific subnets/IPs).
Destination Tab:
- Specify Destination Zones (e.g., untrust ).
- Specify Destination Addresses (e.g., any or specific server IPs).
Service/URL Category Tab:
- Under Service, add service-ssh (or a custom service object for TCP/22). You can also specify the application ssh here.
Options Tab:
- Set Action to Decrypt .
- Set Type to SSH Proxy .
- Optionally, select the Decryption Profile created in Step 2 from the dropdown (e.g., SSH-Proxy-Strict-Profile ). If no profile is selected, default PAN-OS SSH Proxy settings apply.
Click OK . Ensure this rule is appropriately ordered within your Decryption policy set.

     
      PCNSE/PCNSA Exam Note (Palo Alto Networks):
     
     For the PCNSE exam, be very clear on the settings in the 'Options' tab of a Decryption Policy rule when configuring SSH Proxy on a Palo Alto Networks firewall: Action=Decrypt, Type=SSH Proxy.

4. Configure Security Policy Rules

After SSH traffic is decrypted by the Palo Alto Networks firewall, it's subject to Security Policy. You need rules to allow legitimate SSH and block unwanted tunneling.

Go to Policies > Security .
Rule to Allow Legitimate SSH:
- Click Add .
- Name: e.g., Allow-SSH-App .
- Source/Destination Zones and Addresses: As appropriate for your allowed SSH flows.
- Application: Add ssh . You might also add sftp and scp if you want to be explicit, though these are often identified within the base ssh App-ID post-decryption by the Palo Alto Networks firewall.
- Service: application-default (recommended) or service-ssh .
- Action: Allow .
- Profiles: Apply any relevant Security Profiles (Antivirus, Vulnerability Protection, Anti-Spyware, File Blocking) as needed. While SSH Proxy itself doesn't inspect file content deeply, profiles can act on known malicious signatures if tunneled executables are identified by App-ID. For example, Anti-Spyware profiles can detect C2 signatures that might be present in SSH traffic.
- Click OK .
Rule to Block SSH Tunneling:
- Click Add . This rule should typically be placed *before* a broader "allow ssh" rule if you want to selectively block tunneling while allowing normal SSH, or after if you want to allow specific SSH tunnels and block others. A common strategy is to block all ssh-tunnel by default.
- Name: e.g., Block-SSH-Tunnel .
- Source/Destination Zones and Addresses: As appropriate (often broad to prevent tunneling generally).
- Application: Add ssh-tunnel .
- Service: application-default or any (as the port might not be standard if tunneled).
- Action: Deny or Drop .
- Click OK .

5. Commit Configuration

Click Commit in the top-right corner of the PAN-OS web interface.
Review changes and click Commit again to apply them to the Palo Alto Networks firewall.

Managing SSH Proxy Operations

Authentication Considerations

Username/Password Authentication: This is the primary authentication method supported when SSH Proxy is active on a Palo Alto Networks firewall. The firewall proxies the username/password credentials to the server.
Public Key Authentication (PKA): Palo Alto Networks SSH Proxy does NOT support public key authentication. This is a critical limitation. If a client attempts to use PKA to a server being proxied by the firewall, the authentication will fail because the firewall cannot participate in the PKA exchange in a way that satisfies both client and server cryptographic expectations transparently for this proxy model.
Interactive (Keyboard-Interactive) Authentication: Often used for multi-factor authentication (MFA) prompts via SSH, this method *may* work with Palo Alto Networks SSH Proxy depending on the specifics of the MFA prompts and server/client behavior, but it's less straightforward than simple username/password. Thorough testing is required for specific MFA implementations.

     
      CRITICAL (Palo Alto Networks):
     
     Systems or users that *require* public key authentication for SSH access must be excluded from Palo Alto Networks SSH Proxy decryption. This is typically done by creating a "No Decrypt" Decryption Policy rule placed *before* the SSH Proxy Decrypt rule, specifically matching the traffic to/from these systems.

Configuring Exclusions for PKA systems on a Palo Alto Networks firewall:

Go to Policies > Decryption .
Click Add to create a new rule. Place this rule *above* your general SSH Proxy decryption rule (rule order is critical in PAN-OS).
Define the Source/Destination (e.g., IP of the server requiring PKA, or specific client IPs).
Set Service to service-ssh .
In the Options tab, set Action to No Decrypt .
Click OK and commit the changes to the firewall.

Impact on SSH Client Experience

Host Key Warnings: As mentioned, clients will see the Palo Alto Networks firewall's SSH proxy host key. This will cause warnings like "WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!" if the client has connected to the server directly before. Users need to be instructed to accept the new key (the firewall's proxy key) after verifying its authenticity if a distribution mechanism for it exists, or simply accept it if internal policy dictates. For most SSH Proxy deployments, the firewall's proxy key is not pre-distributed.
Potential for Slower Connection Setup: The additional step of the Palo Alto Networks firewall proxying the connection can introduce a slight delay in SSH session establishment, though usually minimal.

Traffic Inspection Capabilities and Limitations within Palo Alto Networks SSH Proxy

Capabilities:
- Identifies SSH channel types (interactive shell, SFTP, SCP, X11 forwarding, local/remote port forwarding) using Palo Alto Networks App-ID.
- Allows policy enforcement (allow/deny) based on these App-IDs through PAN-OS Security Policies.
- Can identify certain applications tunneled over SSH if their signatures are known to Palo Alto Networks App-ID and Threat Prevention content.
Limitations:
- No Deep Content Inspection of Interactive Shell/File Content: Palo Alto Networks SSH Proxy does not inspect the contents of an interactive shell session (i.e., the commands typed or output received) for threats in real-time, nor does it inspect the content of files transferred via SCP/SFTP for malware in the same way SSL Forward Proxy allows for Antivirus scanning of HTTP/HTTPS file downloads. Security profiles (like Anti-Spyware) applied to the *decrypted* SSH traffic primarily act on known C2 signatures or protocol anomalies identified by App-ID rather than full content scanning of the SSH payload.
- Quality of Service (QoS): Proxied SSH traffic on a Palo Alto Networks firewall does not support DSCP code points or QoS markings originating from the client. The proxy process effectively neutralizes original QoS markings for the segments it manages.
- Limited Visibility into Encrypted Payloads within Allowed Tunnels: If an SSH tunnel (e.g., App-ID ssh-tunnel ) is allowed by Security Policy, the traffic *within* that tunnel remains encrypted from the Palo Alto Networks firewall's perspective as it passes through. The benefit is gained by identifying and blocking the tunnel itself if unauthorized.

     
      Gotcha! (Palo Alto Networks):
     
     Do not expect Palo Alto Networks SSH Proxy to perform the same level of content inspection (e.g., antivirus scanning of file transfers within SSH) as SSL Forward Proxy does for web traffic. Its main strength is controlling SSH usage patterns (via App-ID) and blocking unauthorized tunneling.

Performance Considerations

SSH decryption, like any decryption process on a Palo Alto Networks firewall, consumes CPU resources.
The impact depends on the volume of SSH traffic being decrypted and the firewall model's capacity.
In environments with very high volumes of SSH traffic requiring decryption, ensure the Palo Alto Networks firewall is appropriately sized. Monitor CPU utilization (e.g., using show running resource-monitor CLI command) after enabling SSH Proxy.
Palo Alto Networks data sheets provide performance metrics, but real-world impact can vary based on traffic characteristics and other enabled features.

Logging, Monitoring, and Troubleshooting SSH Proxy on Palo Alto Networks Firewalls

Log Analysis

Effective monitoring of SSH Proxy on Palo Alto Networks firewalls relies on analyzing various logs in PAN-OS:

Traffic Logs ( Monitor > Logs > Traffic ):
- Shows sessions matched by Security policies.
- For decrypted SSH traffic, the "Application" column will display the App-ID identified within the SSH session (e.g., ssh , sftp , ssh-tunnel ).
- The "Decrypted" column will indicate "Yes" if the session was handled by a decryption policy.
- Filter by (app eq ssh) or (app eq ssh-tunnel) and (decrypted eq yes) .
Decryption Logs ( Monitor > Logs > Decryption ):
- Provides details specific to the decryption process itself for SSH Proxy.
- Shows successful SSH Proxy handshakes, failures, and reasons for failures (e.g., unsupported ciphers if blocked by Decryption Profile, client aborted, PKA attempt).
- Key columns: "Proxy Type" (will show SSH), "Error/Status", "Decryption Profile Used".
- Filter by (proxy_type eq ssh) .
System Logs ( Monitor > Logs > System ):
- May contain messages related to the SSH Proxy service ( sshrd daemon) itself, such as startup issues or critical errors, though less common for session-specific troubleshooting.

CLI Troubleshooting Commands for PAN-OS

The PAN-OS CLI provides powerful tools for deeper inspection of SSH Proxy operations:

Show session information:
```
show session all filter application ssh destination-port 22
```
```
show session id <session_id>
```
Look for flags indicating decryption (e.g., 'decrypted: True', 'proxy: True', 'type: PROXY'). The 'application' field will show the identified App-ID.
Check SSH Proxy statistics/counters:
```
show counter global filter delta yes name ssh_proxy_stats
```
```
show counter global | match sshproxy
```
(The exact counter names might vary slightly across PAN-OS versions. Use `show counter global | match ssh` to find relevant counters like `sshrd_stats`, `ssh_proxy_sess_created`, `ssh_proxy_sess_failed`). This can show proxied sessions, errors, etc.

Debug dataplane packet diagnostics (use with caution in production environments due to performance impact):

debug dataplane packet-diag set filter match destination-port 22 source-ip <client_ip> destination-ip <server_ip>
debug dataplane packet-diag set filter on
debug dataplane packet-diag show settings
debug dataplane packet-diag clear filter 
debug dataplane packet-diag clear all   
less mp-log Pkt_diag.log

This allows you to see packet flow through the dataplane stages. For SSH proxy, you'd see packets related to both client-to-firewall and firewall-to-server legs.

Check SSH proxy daemon status and logs (Management Plane):
```
debug ssh-proxy status
```
```
less mp-log sshd.log
```
```
less mp-log sshrd.log
```
This can show specific errors from the SSH proxy daemon (sshrd).

Common Issues and Resolutions for Palo Alto Networks SSH Proxy

Issue	Potential Palo Alto Networks Cause(s)	Troubleshooting Steps & Resolution (Palo Alto Networks Context)
SSH connections fail entirely for proxied traffic.	- Palo Alto Networks firewall cannot connect to the backend SSH server (routing, Security Policy blocking firewall-initiated session). - SSH Decryption Profile blocks essential algorithms/versions used by client/server. - Client attempting Public Key Authentication (PKA).	- Check firewall's connectivity to the server (ping from firewall CLI using correct source interface, check Traffic logs for firewall-to-server leg potentially being denied by policy). - Review Decryption logs for errors (e.g., "Unsupported cipher," "Protocol mismatch"). Adjust SSH Decryption Profile on the firewall if necessary. - Confirm client is using username/password. If PKA is required, create a "No Decrypt" rule for that specific traffic flow.
Clients receive SSH host key warnings (e.g., "REMOTE HOST IDENTIFICATION HAS CHANGED!").	Expected behavior: Client sees Palo Alto Networks firewall's proxy host key.	- Educate users to accept the new key after initial setup (this is the firewall's key). - For internal environments, advanced users could potentially add the firewall's SSH proxy public key to their `known_hosts` file, but this is rarely done for SSH proxy and requires distributing the key.
SSH tunneling (e.g., port forwarding via `ssh-tunnel` App-ID) is still possible.	No PAN-OS Security Policy rule to block `ssh-tunnel` , or the rule is misconfigured/misordered (e.g., an "allow any" rule is hit first).	- Verify a Security Policy rule exists with application `ssh-tunnel` and action `Deny` . - Ensure this deny rule is placed correctly in the Security Policy rulebase (typically before broader allow rules for `ssh`). - Check Traffic logs to see which Security Policy rule is matching the `ssh-tunnel` traffic.
Legitimate SSH (interactive shell, identified as `ssh` App-ID) is blocked.	PAN-OS Security Policy rule for `ssh` application is missing, misconfigured, or a deny rule (e.g., an overly broad `ssh-tunnel` deny, or default deny) is taking precedence.	- Verify a Security Policy rule allows `ssh` application for the relevant zones/IPs. - Check Traffic logs for the specific session to see which rule is blocking it and why (e.g., "rule: default-deny").
High CPU utilization on the Palo Alto Networks firewall.	Large volume of SSH traffic being decrypted by SSH Proxy.	- Monitor CPU with `show running resource-monitor` on the firewall CLI. - Review if all SSH traffic being decrypted is necessary. Consider "No Decrypt" exclusions for high-volume, trusted internal SSH flows not requiring tunnel inspection or where PKA is used. - Evaluate firewall sizing if SSH decryption is a critical and heavy workload. Consult Palo Alto Networks performance datasheets.

     
      PCNSE/PCNSA Exam Note (Palo Alto Networks):
     
     For troubleshooting Palo Alto Networks SSH Proxy, know which logs (Traffic, Decryption) provide which type of information. Also, be acutely aware of the Public Key Authentication (PKA) limitation as a common cause of "failed connections" when SSH Proxy is active. Understanding rule order for both Decryption and Security policies is critical.

Advanced SSH Proxy Scenarios and Best Practices for Palo Alto Networks Environments

Integrating with User-ID: If Palo Alto Networks User-ID is configured and operational, you can create Decryption and Security policies based on usernames or Active Directory/LDAP groups. This provides more granular control over who can use SSH and how. For example, allow general ssh (App-ID) for developers but deny ssh-tunnel (App-ID) for all users except specific network administrators.
SSH Proxy for Inbound Connections: SSH Proxy can be used to inspect inbound SSH connections from the internet or less trusted zones to servers in your DMZ or internal network, providing an additional layer of security and visibility into potentially compromised external systems attempting to connect.
Regular Log Review and Auditing: Periodically review Palo Alto Networks Traffic and Decryption logs to monitor SSH Proxy activity, identify anomalies (e.g., unexpected `ssh-tunnel` attempts, decryption errors), and confirm policies are working as expected.
Keep PAN-OS and Content (App-ID/Threat) Signatures Up-to-Date: New App-IDs for tunneled applications and updated threat intelligence (including C2 signatures relevant to SSH) are delivered through Palo Alto Networks content updates. Keeping your firewall's PAN-OS version and content versions current ensures maximum efficacy of SSH Proxy and related security features.
Principle of Least Privilege: Only decrypt SSH traffic that genuinely needs inspection. For highly sensitive internal SSH communications where tunneling is not a concern, PKA is mandated, and trust levels are high, consider "No Decrypt" rules to bypass SSH Proxy for those specific flows.
Documentation: Document your Palo Alto Networks SSH Proxy configuration, including reasons for specific Decryption Profile settings, exclusion policies (especially for PKA), and the expected behavior for users (e.g., host key warnings).

Palo Alto Networks SSH Proxy Flow Diagrams

Diagram 1: PAN-OS SSH Proxy Man-in-the-Middle (MITM) Detailed Flow

This diagram illustrates the detailed Man-in-the-Middle (MITM) process employed by the Palo Alto Networks firewall when SSH Proxy is active. It shows the two separate SSH sessions (Client-to-Firewall and Firewall-to-Server) and the points of decryption by the firewall, inspection (App-ID, Security Policy), and re-encryption for forwarding.

Diagram 2: PAN-OS SSH Traffic Processing Decision Flow (with SSH Proxy)

This decision tree outlines how Palo Alto Networks firewalls process SSH traffic. It highlights when SSH Proxy is engaged based on interface type and Decryption Policy, how different SSH client authentication methods affect the flow (especially PKA), and the subsequent roles of App-ID classification and Security Policy enforcement on the decrypted or bypassed traffic.

Diagram 3: PAN-OS Policy Interaction for SSH Traffic with SSH Proxy

This diagram shows the interaction between Decryption Policies and Security Policies in PAN-OS for SSH traffic. It illustrates how traffic flows through different policy evaluation stages on a Palo Alto Networks firewall, depending on whether SSH Proxy decryption is applied. Key configuration elements like Decryption rules and Security rules for `ssh` and `ssh-tunnel` applications are shown influencing these paths.

PCNSE Exam Focus: Key Takeaways for Palo Alto Networks SSH Proxy

Purpose: SSH Proxy on Palo Alto Networks firewalls is used to decrypt and inspect SSH traffic to identify (via App-ID) and control SSH channel usage (e.g., interactive shell, file transfer, tunneling like X11, TCP forwarding) and prevent abuse of the SSH protocol for covert channels or policy bypass.
Configuration Essentials: Requires a Decryption Policy rule with Action = Decrypt and Type = SSH Proxy . An optional SSH Decryption Profile can be attached to enforce cryptographic standards (e.g., block SSHv1, weak ciphers/KEX/MACs).
App-ID & Security Policy Synergy: After decryption, Palo Alto Networks App-ID classifies the traffic (e.g., ssh , sftp , scp , ssh-tunnel ). Security Policies then enforce allow/deny actions based on these specific App-IDs. You *must* have Security Policies to block unwanted applications like ssh-tunnel ; SSH Proxy enablement alone does not block them.
Critical Authentication Limitation: Palo Alto Networks SSH Proxy primarily supports username/password authentication. It does NOT support Public Key Authentication (PKA). Systems or users requiring PKA must be excluded from SSH Proxy using a "No Decrypt" Decryption Policy rule placed *before* the SSH Proxy decryption rule.
Host Key Impact: When SSH Proxy is active, the client's SSH application will see the Palo Alto Networks firewall's SSH proxy host key, not the original server's host key. This will likely trigger a host key warning on the client.
Inspection Limitations: SSH Proxy does not perform deep content inspection within interactive shells (commands/output) or file transfers (for malware) in the same way as, for example, Antivirus profiles scan files in HTTP. Its strength lies in App-ID based channel control and crypto enforcement. QoS markings are generally not preserved across the proxied connection.
Supported Interface Types: SSH Proxy is supported on Palo Alto Networks firewalls for traffic traversing interfaces configured in Virtual Wire, Layer 2, or Layer 3 mode. Not on Tap mode or directly on Tunnel interfaces for the tunnel's own SSH management.
Logging for Visibility and Troubleshooting: Monitor Traffic logs (for App-ID, Security Policy actions on decrypted/non-decrypted SSH) and Decryption logs (for SSH Proxy handshake details, errors like cipher mismatches, PKA failures, and profile enforcement).