How to Fix the SSH Terrapin Vulnerability Safely

To fix the SSH Terrapin vulnerability, a prefix truncation attack, update the SSH client and server to versions that support strict key exchange, then confirm both endpoints negotiate it. If an update is not immediately possible, disable ChaCha20-Poly1305 and CBC-mode ciphers used with Encrypt-then-MAC, and verify the resulting configuration.

What the SSH Terrapin vulnerability actually does

CVE-2023-48795, known as the Terrapin attack, is a protocol-level weakness in SSH that can remove messages from the beginning of a secure channel. The practical fix is to use a fixed implementation or a carefully verified configuration workaround.

Prefix truncation means an attacker removes selected messages from the start of an encrypted SSH connection without necessarily breaking the connection. SSH is the Secure Shell protocol used to administer servers, network devices, storage systems, and other computers over a network.

Terrapin requires an active machine-in-the-middle position. An attacker in that position can observe and alter traffic between an SSH client and SSH server, so Terrapin is not a fully remote attack that works against an isolated SSH service without control of the connection path.

After the SSH connection starts, removed messages can affect security-relevant negotiation. Depending on the implementation and configuration, the attack may strip extensions or authentication-related mechanisms at the beginning of the secure channel, potentially weakening the intended connection.

The vulnerable conditions are specific rather than universal. The advisory identifies the chacha20-poly1305@openssh.com cipher and CBC-mode ciphers combined with Encrypt-then-MAC negotiation as affected configurations.

Check whether your SSH connection is exposed

First identify the SSH client, SSH server, and negotiated algorithms on both ends; Terrapin exposure depends on the connection between those components, not just on the device you manage.

1. Identify both endpoints

The SSH client is the software that initiates the connection, such as a laptop terminal, automation host, network-management workstation, or firewall process. The SSH server accepts the connection, such as an OpenSSH service on Linux, a network appliance, or a PAN-OS device.

Check both sides because one device may run OpenSSH while another uses PuTTY, libssh, Dropbear, or a vendor-specific SSH implementation. For PAN-OS, determine whether the relevant component is the documented SSH server or SSH client path.

2. Check the negotiated cipher and MAC

Determine whether the connection permits ChaCha20-Poly1305 or a CBC-mode cipher combined with Encrypt-then-MAC. A cipher encrypts the SSH data; a MAC, or message authentication code, helps detect altered data.

Do not treat the presence of a vulnerable algorithm in a general configuration list as proof that every connection is exploitable. Record the algorithms actually offered and negotiated by the relevant client-server pair, then compare them with the implementation’s Terrapin guidance.

3. Check internet exposure

For internet-facing SSH, include an external exposure check in your review. CERTVU recommends checking the Shadowserver Accessible SSH report as part of exposure assessment, alongside your own firewall, router, and server records.

Exposure does not prove that a Terrapin attack occurred. It shows that an SSH service may be reachable from the internet, which helps you prioritise updates and reduce unnecessary public access.

How to fix the SSH prefix truncation vulnerability: update both endpoints

The preferred fix is to update the SSH client and SSH server to fixed releases and confirm that both sides support and negotiate strict key exchange. Updating only one endpoint does not guarantee protection when the countermeasure depends on negotiation by both endpoints.

Strict key exchange is an SSH protocol countermeasure that helps prevent the initial exchange from being silently truncated. The protection is effective when both endpoints support it and the connection actually negotiates it.

OpenSSH 9.6 and later support the strict key exchange countermeasure identified in the advisory. Treat OpenSSH 9.6 as a comparison point, not as a universal version rule for every SSH product.

For other implementations, follow the fixed-version guidance for the exact product and role. PuTTY, libssh, Dropbear, PAN-OS, and other SSH components can publish different release paths, and a client update does not automatically update a separate server component.

Plan the update in this order:

1. Record the SSH client and server implementation and current version.
2. Check the product’s CVE-2023-48795 or Terrapin advisory for the fixed release.
3. Update the client and server components that participate in the connection.
4. Reconnect and confirm strict key exchange is supported and negotiated on both sides.
5. Recheck the permitted cipher and MAC configuration after the update.

For home users, the relevant update may be the operating system, terminal application, router, NAS, or firewall firmware. For small businesses, include automation hosts, jump servers, monitoring systems, and network appliances rather than checking only the main Linux server.

If you cannot update yet, disable the vulnerable modes

A temporary mitigation is to remove ChaCha20-Poly1305 and CBC plus Encrypt-then-MAC combinations from the SSH configuration, but the change must be verified and revisited after the software update.

Disabling vulnerable modes reduces the relevant Terrapin exposure when a fixed implementation cannot be deployed immediately. Do not disable all SSH encryption or authentication controls, and do not assume that a saved configuration file proves the active service uses the intended settings.

For PAN-OS SSH servers, Palo Alto Networks describes a workaround using an SSH profile with at least one allowed cipher and at least one allowed MAC algorithm. The configuration removes support for ChaCha20-Poly1305 and Encrypt-then-MAC algorithms.

Apply the PAN-OS change to the SSH profile used by the relevant server function, then verify the active profile and test a new connection. A profile that was edited but not attached to the correct service does not provide the intended mitigation.

Configuration workarounds can affect compatibility. Older SSH clients, scripts, and network appliances may fail to connect when an algorithm is removed, so test administrative access through a separate session before closing an existing working session.

SSH Terrapin fixes by implementation and product

The correct remediation depends on the implementation, product role, and release branch; the table below separates general strict-key-exchange guidance from vendor-specific version information.

Implementation or product	Affected or fixed information	Role to check	Recommended action
OpenSSH	OpenSSH 9.6 and later support strict key exchange	Client and server	Update both endpoints and verify strict key exchange is negotiated
PuTTY	Terrapin can affect widespread SSH implementations; use the project’s fixed-release guidance	Client	Identify the exact PuTTY release and update according to its advisory
libssh	Terrapin can affect libssh-based SSH components; fixed versions vary by release guidance	Client or embedded component	Identify the application using libssh and follow its update path
Dropbear on Mageia	Mageia package 2022.83-2.1.mga9 implements Strict KEX mode	Check the deployment role	Install the applicable updated package and verify the active Dropbear service
PAN-OS SSH server	Fixed in PAN-OS 10.2.14, 11.1.8, and 11.2.8, with later versions also fixed through kex-strict support	Server	Update PAN-OS or apply the documented cipher and MAC workaround temporarily
PAN-OS SSH client	Fixes included in PAN-OS 10.2.11, 11.0.6, 11.1.3, and later versions	Client	Update the PAN-OS client-side component and test outbound SSH
Prisma SD-WAN ION	Fixes listed in versions 5.6.19, 6.1.8, 6.3.2, and later versions	Product-specific client or service role	Match the ION release branch and verify the affected function

Version numbers in the table are product-specific, not interchangeable. A PAN-OS 11.1 fix does not establish the correct update for OpenSSH, PuTTY, libssh, or Dropbear.

Troubleshooting when the vulnerability still appears

If a scanner or advisory still reports Terrapin after remediation, first determine whether it examined the correct component, then verify negotiation and active configuration before making further changes.

Check the update target

Confirm that the updated package belongs to the SSH component used by the connection. A patched command-line client does not fix a separate SSH server, embedded libssh application, Dropbear service, or PAN-OS device.

Also check for duplicated systems. A public router may forward SSH to a NAS, while administrators connect through a jump host. Each SSH connection can involve a different client-server pair and a different software version.

Check strict key exchange on both sides

Strict key exchange must be supported and negotiated by both endpoints. If one side is too old, disabled, misconfigured, or using a different implementation path, the connection may not receive the intended protocol protection.

Separate a software-version finding from a negotiation finding. A device may run a fixed release but still show a configuration issue, while an old release may remain vulnerable even if its current cipher list looks restricted.

Check the active algorithms

After a workaround, recheck the effective cipher and MAC settings rather than the draft configuration. Confirm that ChaCha20-Poly1305 and the relevant CBC plus Encrypt-then-MAC combinations are not enabled where your mitigation requires them to be removed.

Keep a separate administrative connection open during changes to remote SSH. If a configuration change breaks compatibility, the existing session may be the safest way to restore the previous setting.

Post-fix SSH verification checklist

A Terrapin remediation is complete only when both endpoints use fixed software or a documented workaround, the negotiated connection has been checked, and internet exposure has been reviewed.

• Record the SSH client, server, implementation, and version for each important connection.
• Confirm the relevant fixed release or documented mitigation for every product.
• Verify strict key exchange support and negotiation on both endpoints where applicable.
• Confirm vulnerable cipher modes are no longer enabled when a configuration workaround is being used.
• Test a new SSH connection after changing software or algorithms.
• Check internet-exposed SSH using internal records and the Shadowserver Accessible SSH report approach.
• Review SSH configuration during routine network hardening, not only after a vulnerability notice.

For a home network, prioritise routers, NAS devices, remote-access hosts, and any internet-facing management service. For a small business, document the result for servers, firewalls, automation systems, and network appliances so a later update does not leave an overlooked SSH client exposed.

What to do next

Start with the exact SSH client-server path, identify the negotiated algorithms, and update both endpoints using the product-specific guidance. For the documented exposure-check approach, review the CERTVU advisory and its Shadowserver Accessible SSH recommendation; for product-specific PAN-OS and Prisma SD-WAN versions, use Palo Alto Networks’ CVE guidance.

Once you have verified the SSH fix, continue with our router security settings guide to review the wider home-network configuration. Router settings complement the endpoint checks above; they do not replace updating affected SSH software.

Frequently asked questions

What is the SSH Terrapin prefix truncation vulnerability?

CVE-2023-48795, called Terrapin, is an SSH protocol weakness that can let an active machine-in-the-middle attacker remove messages from the beginning of a secure channel. The removed messages can affect security-relevant extensions or authentication mechanisms.

Does Terrapin require a machine-in-the-middle attack?

Yes. Terrapin requires an attacker to actively observe and alter traffic between the SSH client and SSH server. It is not a fully remote attack that works against an isolated SSH service without control of the connection path.

Which SSH cipher configurations make Terrapin relevant?

The affected configurations include chacha20-poly1305@openssh.com and CBC-mode ciphers combined with Encrypt-then-MAC negotiation. Check the algorithms actually offered and negotiated by the specific client-server pair rather than relying only on a general software label.

Is upgrading to OpenSSH 9.6 enough to fix Terrapin?

OpenSSH 9.6 and later support the strict key exchange countermeasure, but both SSH endpoints must support and negotiate it. Updating only one endpoint does not guarantee protection, and other products require their own fixed-version guidance.

What should I do if I cannot upgrade the SSH software yet?

Temporarily disable ChaCha20-Poly1305 and CBC plus Encrypt-then-MAC configurations where the product guidance recommends it. Verify the active configuration and test compatibility, then complete the software update as soon as practical.

Last updated: 07 November 2026