SSH Proxy
Table of Contents
SSH Proxy
SSH Proxy decryption decrypts inbound and outbound SSH
sessions and ensures that attackers can’t use SSH to tunnel potentially
malicious applications and content.
In an SSH Proxy configuration, the firewall resides
between a client and a server. SSH Proxy enables the firewall to
decrypt inbound and outbound SSH connections and ensures that attackers
don’t use SSH to tunnel unwanted applications and content. SSH decryption
does not require certificates and the firewall automatically generates
the key used for SSH decryption when the firewall boots up. During
the boot up process, the firewall checks if there is an existing
key. If not, the firewall generates a key. The firewall uses the
key to decrypt SSH sessions for all virtual systems configured on
the firewall and all SSH v2 sessions.
SSH allows tunneling, which can hide malicious traffic from decryption.
The firewall can’t decrypt traffic inside an SSH tunnel. You can
block all SSH tunnel traffic by configuring a Security policy rule
for the application ssh-tunnel with the Action set
to Deny (along with a Security policy rule
to allow traffic from the ssh application).
SSH tunneling sessions can tunnel X11 Windows packets and TCP
packets. One SSH connection may contain multiple channels. When
you apply an SSH Decryption profile to traffic, for each channel
in the connection, the firewall examines the App-ID of the traffic
and identifies the channel type. The channel type can be:
- session
- X11
- forwarded-tcpip
- direct-tcpip
When the channel type is session, the firewall identifies the
traffic as allowed SSH traffic such as SFTP or SCP. When the channel
type is X11, forwarded-tcpip, or direct-tcpip, the firewall identifies
the traffic as SSH tunneling traffic and blocks it.
Limit SSH use to administrators who need
to manage network devices, log all SSH traffic, and consider configuring Multi-Factor Authentication to
help ensure that only legitimate users can use SSH to access devices,
which reduces the attack surface.
After you enable SSH Decryption on the firewall, authenticating
to hosts that have a certificate fails because the SSH client no
longer uses public key-based authentication, so the server can’t
use a public key that the client that the client can decrypt to
with its private key to complete the handshake. Use username and
password authentication to initiate the SSH session.
For systems
that must use key-based authentication, configure your SSH Decryption
policy rule to exclude the systems that require public key authentication. To
edit the SSH Decryption policy rule:
- Go to and select the policy rule that controls SSH decryption.
- Select the Destination tab.
- Add the IP addresses of the systems you want to exclude from the rule.
- Select Negate.
- Click OK.
- Commit the change.
The following figure shows how SSH Proxy decryption works. See Configure
SSH Proxy for how to enable SSH Proxy decryption.
- The client sends an SSH request to the server to initiate a session.
- The firewall intercepts the client’s SSH request .
- The firewall forwards the request to the server and initiates an SSH session with the server. This establishes the first of two separate sessions that the firewall creates. Each session establishes a separate SSH tunnel.
- The server responds to the request, which the firewall intercepts.
- The firewall inserts the SSH key into the server’s response and forwards it to the client. This establishes the second separate session (and separate SSH tunnel) that the firewall creates.
- (First part of “7” in the diagram) After the firewall establishes separate sessions with the server and the client, the firewall acts as a proxy between them.
- The firewall checks the traffic between the client and server to see if it is routed normally or if it uses SSH port forwarding (SSH tunneling). If the firewall identifies SSH port forwarding, the firewall blocks the tunneled traffic and restricts it according to the configured Security policy. The firewall only looks for SSH port forwarding, it does not perform content and threat inspection on SSH tunnels.
When you configure SSH Proxy, the proxied traffic does
not support DSCP code points or QoS.