How to Fix SSH Terrapin (CVE-2023-48795) and OpenSSH < 9.6 Findings

SSH Terrapin (CVE-2023-48795) is a man-in-the-middle prefix truncation weakness in the SSH handshake. It affects servers that offer ChaCha20-Poly1305 or CBC ciphers with Encrypt-then-MAC without strict key exchange. Fix it by upgrading OpenSSH to 9.6 or a distro package with backported strict KEX, or by disabling those algorithms, then rescan.

What the scanner is actually detecting

Two checks usually land on the same host, and which one fired tells you whether a configuration change is enough or a package update is needed.

Because 187201 relies only on the version number, a cipher change can clear 187315 while 187201 stays open.

Real-world risk

Terrapin needs an attacker who can actively modify traffic between client and server. It lets that attacker delete consecutive messages at the start of the encrypted channel without either side noticing. According to the OpenSSH 9.6 release notes, the most serious impact on OpenSSH is deleting the SSH2_MSG_EXT_INFO message, which disables part of the keystroke timing obfuscation added in OpenSSH 9.5, with no other discernible impact on session secrecy or integrity. Tenable rates plugin 187315 as Medium (CVSS v3 5.9).

The two companion CVEs in plugin 187201 are client-side: CVE-2023-51385 is command injection when a user or host name containing shell metacharacters reaches a ProxyCommand, LocalCommand or Match exec through %u or %h, and CVE-2023-51384 is ssh-agent applying destination constraints only to the first key of a PKCS#11 token. Treat the finding as a normal-cycle patch, prioritized for hosts reached over networks you do not control.

How to confirm it on the host

Start with the installed server package, not the banner. Skip ssh -V: it reports the client binary, not the sshd daemon the scanner connects to.

dpkg-query -W openssh-server                           # Debian/Ubuntu
rpm -q openssh openssh-server                          # RHEL, Rocky, Alma
sudo /usr/sbin/sshd -V 2>&1 | grep -i openssh          # daemon version string

sshd -V exists from OpenSSH 9.2; on older builds the usage message still starts with the version.

Check whether the fix was backported by searching the package changelog:

zgrep -h CVE-2023-48795 /usr/share/doc/openssh-*/changelog.Debian.gz   # Debian/Ubuntu
apt changelog openssh-server | grep CVE-2023-48795                      # fallback, needs repository access
rpm -q --changelog openssh-server | grep -iE 'CVE-2023-48795|terrapin'  # RHEL family

On RHEL 8 and its rebuilds, the changelog names the attack (“Fix Terrapin attack”), not the CVE ID, hence the second pattern; RHEL 9 cites the CVE. On any distro, the strongest evidence is the installed version compared with the vendor’s fixed build in the table below. Minimized Ubuntu images strip /usr/share/doc, so an empty zgrep there proves nothing.

Then check what sshd will negotiate (run as root). On Debian and Ubuntu (sshd_config plus drop-ins) and on RHEL 9 (where the crypto policy is pulled in by an Include in 50-redhat.conf), sshd -T prints the effective configuration after all includes:

sudo sshd -T | grep -E '^(ciphers|macs) '

On RHEL 8 (and CentOS, Alma and Rocky 8) that output is misleading. The systemd unit passes the crypto policy as -oCiphers= and -oMACs= command-line options, so a plain sshd -T shows compiled-in defaults, chacha20-poly1305 included, even after a working mitigation. Load the policy the way the unit does:

sudo sh -c '. /etc/crypto-policies/back-ends/opensshserver.config; . /etc/sysconfig/sshd; /usr/sbin/sshd -T $CRYPTO_POLICY' | grep -E '^(ciphers|macs) '

From another machine, confirm whether the server advertises strict KEX. A patched server includes the pseudo-algorithm kex-strict-s-v00@openssh.com in its key exchange offer:

ssh -vv -o BatchMode=yes user@server exit 2>&1 | grep -o 'kex-strict-s-v00@openssh.com' | sort -u
nmap -p 22 --script ssh2-enum-algos server

The researchers’ Terrapin Scanner gives a direct verdict; --json adds the SupportsStrictKex and Vulnerable fields. go install puts the binary in ~/go/bin:

go install github.com/RUB-NDS/Terrapin-Scanner@latest
~/go/bin/Terrapin-Scanner --connect server:22 --json

How to fix it

Preferred: update OpenSSH on servers and clients

OpenSSH 9.6 (18 December 2023) adds strict KEX, enabled automatically when both sides support it. Distribution packages backport it without changing the major version:

sudo apt update && sudo apt install --only-upgrade openssh-server openssh-client   # Debian/Ubuntu
sudo dnf upgrade openssh openssh-server openssh-clients                             # RHEL 8/9 family
sudo sshd -t && sudo systemctl restart ssh     # Debian/Ubuntu service name
sudo sshd -t && sudo systemctl restart sshd    # RHEL family service name

Fixed Terrapin package versions from the vendor trackers:

Backports do not always ship all three CVEs together: on Ubuntu 22.04, CVE-2023-51384 was fixed later (1:8.9p1-3ubuntu0.6) than Terrapin. Check each CVE in your vendor’s advisory. For network appliances and embedded SSH servers, the fix is a vendor firmware update.

Temporary mitigation: Debian, Ubuntu and other sshd_config systems

If you cannot patch yet, remove the vulnerable combinations. Because sshd uses the first value it reads for each keyword, a drop-in file works when /etc/ssh/sshd_config starts with an Include /etc/ssh/sshd_config.d/*.conf line (check with grep -i '^include' /etc/ssh/sshd_config). Otherwise, put the line near the top of sshd_config, before any Match block. Create /etc/ssh/sshd_config.d/00-terrapin.conf:

# Temporary CVE-2023-48795 mitigation: no ChaCha20-Poly1305 and no CBC ciphers
Ciphers aes256-gcm@openssh.com,aes128-gcm@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr

With CBC gone, the EtM MACs can stay: the researchers call CTR with EtM theoretically affected but not exploitable in practice, and this clears Nessus 187315 and the Terrapin Scanner. For full removal, also drop the *-etm@openssh.com MACs, as Red Hat does. If a legacy client forces you to keep CBC, keep ChaCha20-Poly1305 out and remove the EtM MACs instead, for example with Red Hat’s RHEL 7 set:

MACs umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512

Keeping CBC clears Terrapin (187315) but leaves Nessus 70658 “SSH Server CBC Mode Ciphers Enabled” (and equivalents in other scanners) open; treat it as an accepted risk until the legacy client is replaced.

On OpenSSH 7.5 and later, Ciphers -chacha20-poly1305@openssh.com also works, because a leading - removes entries from the default set (see sshd_config(5)). Validate and restart with sudo sshd -t && sudo systemctl restart ssh. On RHEL 7, put the explicit Ciphers and MACs lines in both /etc/ssh/sshd_config and /etc/ssh/ssh_config.

RHEL 8 (and CentOS, Alma and Rocky 8) ships OpenSSH 8.0. Red Hat backported the sshd_config Include keyword (openssh-8.0p1-12, RHEL 8.6 and later), but the default sshd_config has no Include line and /etc/ssh/sshd_config.d does not exist, so a drop-in is not read unless you add one. Even with an Include, the crypto policy passed as -oCiphers= and -oMACs= on the sshd command line overrides sshd_config. These lines work only if you uncomment CRYPTO_POLICY= in /etc/sysconfig/sshd, opting sshd out of the system policy; otherwise use the method below.

Temporary mitigation: RHEL 8.5+ and RHEL 9 (crypto-policies)

On these releases, sshd algorithms come from the system crypto policy, so edit the policy rather than sshd_config. Red Hat’s documented subpolicy removes ChaCha20-Poly1305 and all EtM MACs:

update-crypto-policies --show     # note the current policy for rollback
printf 'cipher@SSH = -CHACHA20-POLY1305nssh_etm = 0n' | sudo tee /etc/crypto-policies/policies/modules/CVE-2023-48795.pmod
sudo update-crypto-policies --set $(update-crypto-policies --show):CVE-2023-48795
sudo systemctl restart sshd
grep -E 'chacha20|etm' /etc/crypto-policies/back-ends/openssh.config /etc/crypto-policies/back-ends/opensshserver.config

The last command should return nothing. Red Hat calls this a temporary, interoperability-limiting measure until the update is installed. Newer crypto-policies releases replace ssh_etm with etm@SSH = DISABLE_ETM; check crypto-policies(7) on your system. On RHEL 8 releases older than 8.5, which the subpolicy does not support, update the package, or opt sshd out with CRYPTO_POLICY=, set the explicit Ciphers and MACs lines in /etc/ssh/sshd_config, and set them for the client in /etc/ssh/ssh_config as Red Hat recommends.

How to verify the fix and rescan

1. If you used the cipher mitigation, rerun the sshd -T check (on RHEL 8, the crypto-policy variant or the back-end file grep) and confirm that chacha20-poly1305@openssh.com is gone and no CBC cipher is paired with an EtM MAC.
2. From a separate host, rerun the ssh -vv or Terrapin Scanner check. A patched server shows kex-strict-s-v00@openssh.com; a mitigated one shows no vulnerable modes.
3. Rescan with the same policy and credentials. Plugin 187315 should clear once strict KEX is advertised or the vulnerable combinations are gone. Plugin 187201 stays until the banner reports 9.6 or later; for backported packages, record it as a false positive with the installed version, the vendor’s fixed build and the changelog entry as evidence.

What can break and how to roll back

• Old clients: devices that only offer ChaCha20-Poly1305 or CBC fail with “no matching cipher found”. Check sshd logs.
• Non-conforming peers: strict KEX drops connections on unexpected key exchange messages.
• Scripts: the CVE-2023-51385 fix makes ssh reject most shell metacharacters in command-line user and host names.
• Lockout: run sshd -t first and keep a second session open while restarting.

To roll back, delete 00-terrapin.conf and restart sshd. On RHEL, run sudo update-crypto-policies --set DEFAULT (or your recorded policy) and restart sshd; if you opted sshd out on RHEL 8, comment CRYPTO_POLICY= again. dnf history undo reverts a package update, but fixing the incompatible client is almost always better.

Common false positive reasons

Most disputed Terrapin results fall into a few patterns that also show up across other vulnerability scanner false positive causes:

• Backported packages: a banner such as OpenSSH 8.9p1 on a patched Ubuntu 22.04 host still triggers the version-based plugin 187201. Your evidence is the installed version against the fixed-version table plus the changelog entry; see how backported patches create scanner false positives.
• Unauthenticated scans: without credentials the scanner can only read the banner. An authenticated Linux scan over SSH with sudo lets it check installed package versions against vendor advisories.
• Stale config: sshd was not restarted, an earlier line or include overrides your drop-in, the RHEL 8 crypto policy overrides your sshd_config lines, or a second sshd (another port, a container) still answers.
• Wrong target: a load balancer, bastion or appliance answers on port 22 instead of the host you patched.

FAQ

Do I need to patch SSH clients as well as servers?

Yes. Strict KEX only activates when both sides support it. Until clients are updated, the server-side cipher restriction is what protects those connections.

Is disabling chacha20-poly1305 in sshd_config enough?

For the scanners, yes, if no CBC cipher is paired with an EtM MAC; confirm with sshd -T. On RHEL 8, an sshd_config change does nothing unless sshd is opted out of the crypto policy.

Why does Nessus 187201 still fire after I updated Ubuntu or RHEL?

The plugin reads only the version banner, which backported packages do not change. Keep the version and changelog output as evidence and rely on plugin 187315 or an authenticated check.

Can Terrapin be exploited without a man-in-the-middle position?

No. The attacker must be able to intercept and modify traffic between client and server.

Tracking this finding across many hosts

On a fleet, the real work is separating backported hosts from exposed ones and proving closure. SITEY, a self-hosted vulnerability management platform, imports findings from 16 scanners (Nessus results arrive as uploaded .nessus exports) and merges duplicates per scanner, so Nessus and Qualys records stay separate. Its AI triage can suggest a banner-only false positive with evidence for a human to decide, AI-written host-specific fix scripts run through human approval gates and are deployed by its Linux agents, and Nessus findings can then be retested individually to verify closure.

Sources

• Tenable: SSH Terrapin Prefix Truncation Weakness (CVE-2023-48795), plugin 187315
• Tenable: OpenSSH < 9.6 Multiple Vulnerabilities, plugin 187201
• Tenable: SSH Server CBC Mode Ciphers Enabled, plugin 70658
• OpenSSH 9.6 release notes
• Red Hat: CVE-2023-48795
• Red Hat security data: CVE-2023-48795 fixed packages (RHSA-2024:0606, RHSA-2024:1130)
• RHEL 8 openssh-8.0p1-19.el8_9.2 spec and changelog (AlmaLinux import)
• Ubuntu: CVE-2023-48795
• Debian security tracker: CVE-2023-48795
• Qualys ThreatPROTECT: Terrapin attack (CVE-2023-48795)
• Terrapin Attack (Ruhr University Bochum researchers)
• Terrapin Vulnerability Scanner (RUB-NDS)
• CentOS Stream 8 openssh package: sshd.service
• crypto-policies(7)