SSH Proxy
Focus
Focus

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:
  1. Go to PoliciesDecryption and select the policy rule that controls SSH decryption.
  2. Select the Destination tab.
  3. Add the IP addresses of the systems you want to exclude from the rule.
  4. Select Negate.
  5. Click OK.
  6. Commit the change.
The following figure shows how SSH Proxy decryption works. See Configure SSH Proxy for how to enable SSH Proxy decryption.
  1. The client sends an SSH request to the server to initiate a session.
  2. The firewall intercepts the client’s SSH request .
  3. 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.
  4. The server responds to the request, which the firewall intercepts.
  5. 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.
  6. (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.
  7. 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.