CVE-2023-48795 Terrapin Attack, SSH Downgrade Risk and Practical Mitigation

CVE-2023-48795 is not “SSH is broken” and it is not a generic remote code execution bug. It is more specific and, for mature security teams, more interesting: the Terrapin attack shows that parts of the early SSH encrypted channel can lose integrity under certain protocol and algorithm conditions. A network attacker who can actively intercept and modify traffic may be able to remove selected early messages from an SSH connection without either endpoint noticing, which can downgrade or disable some negotiated security features. NVD describes the issue as affecting the SSH transport protocol with certain OpenSSH extensions, including OpenSSH before 9.6 and many other SSH implementations, and assigns it CVSS 3.1 5.9 Medium with a high attack-complexity network vector. (NVD)

The practical reading is this: CVE-2023-48795 deserves remediation, but the remediation should be precise. Treat it as a protocol downgrade and integrity-bypass risk in SSH negotiation, not as proof that every SSH session is readable, writable, or instantly compromised. The attack requires active man-in-the-middle capability, not just the ability to scan port 22. It also depends on vulnerable encryption modes such as chacha20-poly1305@openssh.com or CBC ciphers combined with Encrypt-then-MAC MAC algorithms. The Terrapin research team states that the attack requires MITM capability at the network layer and a vulnerable encryption mode; the same project also notes that the strict key exchange countermeasure must be supported by both client and server to take effect. (Terrapin Attack)

For defenders, the mistake is usually one of two extremes. One team sees “Medium” and leaves it for a quarterly patch cycle even though SSH is the management plane for servers, appliances, SFTP services, CI runners, cloud workloads, and break-glass access. Another team sees “SSH downgrade attack” and assumes private keys, passwords, and shell traffic are immediately exposed. Neither interpretation is accurate. The right response is to identify exposed SSH services and SSH client libraries, determine whether vulnerable algorithms are still negotiable, confirm whether strict KEX is supported on both sides, patch or upgrade where possible, and use temporary algorithm restrictions only when patching is delayed.

One-page technical summary

Feld	Practical answer
CVE	CVE-2023-48795
Common name	Terrapin attack
Klasse der Anfälligkeit	SSH protocol prefix truncation and early-channel integrity weakness
Main risk	Downgrade or disablement of selected SSH extension-negotiated security features
Attacker position	Active man-in-the-middle who can intercept and modify TCP traffic
Common vulnerable modes	chacha20-poly1305@openssh.com; CBC ciphers with -etm@openssh.com MACs
OpenSSH fix line	OpenSSH 9.6 introduced strict KEX support
Temporary mitigation	Disable vulnerable algorithms if upgrading both sides cannot be done immediately
What it is not	Not a direct universal SSH password theft bug, not a generic shell RCE, not passive decryption

The core of CVE-2023-48795 is easier to understand if you stop thinking of SSH as a single magic encrypted pipe. SSH has phases. It negotiates algorithms, exchanges keys, turns on encryption, and then continues into authentication and channel operation. Terrapin targets the transition into the early encrypted channel. That point in the protocol is security-sensitive because small differences in what each side believes was negotiated can affect authentication algorithms, extensions, and countermeasures.

Why Terrapin is a protocol problem, not just an OpenSSH bug

SSH is built from protocol layers. RFC 4251 describes SSH as a protocol for secure remote login and other secure network services over an insecure network, with the transport layer providing server authentication, confidentiality, and integrity for later layers. (RFC-Editor) RFC 4253 defines the SSH Transport Layer Protocol, including how data integrity is protected. In the original transport design, packet integrity is protected with a MAC computed over a shared secret, packet sequence number, and packet content. The sequence number is implicit, starts at zero, increments after every packet, and is never sent on the wire. RFC 4253 also says it is never reset, even if keys or algorithms are renegotiated later. (IETF Datatracker)

That design matters because Terrapin is a sequence-number manipulation attack. The sequence number is part of the integrity computation, but it is not visible on the wire. In normal operation, if an attacker deletes a packet, the sender and receiver sequence numbers drift apart, and the next authenticated packet should fail integrity verification. Terrapin works around that expectation by manipulating the handshake so that sequence numbers are offset and then realigned across the point where encryption starts.

The second ingredient is SSH extension negotiation. RFC 8308 defines ext-info-c und ext-info-s, which are indicators placed into the kex_algorithms field of SSH_MSG_KEXINIT. If a peer receives the appropriate indicator, it may send SSH_MSG_EXT_INFO; the message can carry extension names and values such as server-sig-algs, which tells a client what public-key signature algorithms the server can process during authentication. (IETF Datatracker)

In other words, SSH extension negotiation is not decorative. It is how modern implementations advertise important capabilities after key exchange. If an attacker can make one side miss SSH_MSG_EXT_INFO, the session can continue under a weaker or less featureful understanding of what the peer supports. That is why CVE-2023-48795 is usually described as a downgrade risk rather than a classic memory corruption bug.

The attack mechanics, without exploit theater

Terrapin is a prefix truncation attack. The researchers describe it as breaking the integrity of SSH’s secure channel by carefully adjusting sequence numbers during the handshake, allowing an attacker to remove messages sent at the beginning of the secure channel without the client or server noticing. (Terrapin Attack) The original paper by Fabian Bäumer, Marcus Brinkmann, and Jörg Schwenk states that SSH channel integrity is broken for widely used encryption modes and that encrypted packets at the beginning of the SSH channel can be deleted without detection. (arXiv)

At a high level, the sequence is:

1. The attacker is already in an active MITM position.
2. The SSH connection negotiates a vulnerable encryption mode.
3. The attacker injects extra ignorable messages before encryption begins.
4. After encryption starts, the attacker deletes the same number of consecutive early encrypted messages.
5. The sequence numbers line up again, so the endpoints do not detect the deletion through normal packet integrity checks.

The deleted message of greatest interest is often SSH2_MSG_EXT_INFO. The researchers’ public explanation uses the deletion of EXT_INFO as a practical example: an attacker can drop the message used to negotiate extensions without the client or server noticing, because injected ignored packets can offset the sequence numbers. (Terrapin Attack)

That is the “trick” behind the attack. It does not require breaking the cryptographic primitive in the usual sense. It abuses how the protocol state machine, optional messages, sequence numbers, and certain encryption modes fit together. The paper identifies two root causes: optional messages in the SSH handshake that are not authenticated in the right way for this purpose, and sequence numbers that are not reset when encryption keys are activated. (arXiv)

What can actually be downgraded

The highest-value practical effect is deleting extension negotiation. The Terrapin paper says the attack can fully break SSH extension negotiation under RFC 8308, enabling downgrade of public key algorithms for user authentication or disabling a countermeasure against keystroke timing attacks introduced in OpenSSH 9.5. (arXiv) The public Terrapin site similarly states that truncating the extension negotiation message can lead to less secure client authentication algorithms and deactivation of specific OpenSSH 9.5 keystroke timing protections. (Terrapin Attack)

OpenSSH’s own release notes are careful about impact. OpenSSH 9.6 says the attack allows a MITM to create a limited break in the integrity of the early encrypted SSH transport protocol by sending extra messages before encryption and deleting an equal number of consecutive messages immediately after encryption starts. OpenSSH also states that the most serious identified impact for OpenSSH is deletion of the SSH2_MSG_EXT_INFO message before authentication, which can disable a subset of keystroke timing obfuscation features introduced in OpenSSH 9.5, and that there is no other discernible impact to session secrecy or session integrity in the OpenSSH analysis. (OpenSSH)

That distinction is important. For OpenSSH, the most visible operational risk is downgrade of negotiated features, not decryption of an established shell. But OpenSSH is not the entire SSH ecosystem. The original research also identified AsyncSSH implementation flaws that, combined with prefix truncation, could redirect a victim’s login into a shell controlled by an attacker. (Terrapin Attack) That is why defenders should not treat CVE-2023-48795 as only an OpenSSH version check. Client libraries, SFTP products, embedded SSH stacks, appliances, and custom automation can all matter.

Affected algorithms and why AES-GCM is different

The vulnerable conditions commonly discussed for CVE-2023-48795 are:

Algorithm condition	Warum das wichtig ist
chacha20-poly1305@openssh.com	Widely deployed OpenSSH encryption mode affected by the sequence-number manipulation pattern
CBC ciphers with -etm@openssh.com MACs	CBC combined with Encrypt-then-MAC can be affected in the Terrapin model
AES-GCM	The Terrapin project says AES-GCM is not affected because it does not use SSH sequence numbers in the same way; it uses an IV from key derivation as its nonce and increments it after sending a binary packet

The Terrapin project’s FAQ states that a client or server is vulnerable in technical terms if it supports and is configured to offer chacha20-poly1305@openssh.com, or any -cbc encryption algorithm together with any MAC algorithm suffixed -etm@openssh.com. It also says AES-GCM is not affected by Terrapin because it does not use SSH sequence numbers in the same way. (Terrapin Attack)

This is where many operational mistakes happen. Teams sometimes disable ChaCha20 and assume they are done. That may be sufficient for one implementation and one policy, but it is not a complete fleet strategy. You also need to look for CBC plus Encrypt-then-MAC, verify what both client and server negotiate, and understand whether strict KEX is active. Conversely, a scanner that reports “ChaCha20 supported” is not automatically proving that a realistic attack path exists in your environment. The attacker still needs an active MITM position, and a patched endpoint pair with strict KEX can change the outcome.

Why strict KEX became the durable fix

OpenSSH 9.6 introduced a protocol extension called strict KEX to address Terrapin. It is automatically enabled when both client and server support it. OpenSSH describes two changes: endpoints terminate the connection if they receive unnecessary or unexpected messages during key exchange, and the MAC counter is reset at the conclusion of each key exchange. OpenSSH states either change should be sufficient to thwart Terrapin. (OpenSSH)

This is clean in principle. Terrapin needs optional or ignorable handshake messages to create sequence-number offsets. Strict KEX removes most of that malleability by making unexpected messages fatal during key exchange. Terrapin also relies on sequence-number continuity across the transition into encrypted transport. Resetting the counters cuts the link between pre-encryption manipulation and post-encryption packet numbering.

The Terrapin team’s FAQ adds an operational caveat: strict key exchange must be supported by both client and server. A patched server with an old client, or a patched client with an old server, can still result in a vulnerable connection if the negotiated algorithms remain vulnerable and strict KEX does not take effect. (Terrapin Attack)

That point deserves emphasis in enterprise environments. Many SSH inventories focus on servers because servers are easy to scan. But SSH clients are everywhere: developer laptops, deployment bots, backup jobs, CI/CD runners, SFTP integrations, appliance management tools, Python automation using Paramiko, Go services using golang.org/x/crypto/ssh, Java SFTP connectors, and Windows clients such as PuTTY and WinSCP. CVE-2023-48795 is negotiated connection risk, not just daemon risk.

OpenSSH 9.6 and the limits of version-only thinking

OpenSSH 9.6 was released on December 18, 2023, and includes the strict KEX countermeasure for Terrapin. (OpenSSH) If you build OpenSSH directly from upstream, “before 9.6” is a simple line to understand. In real operations, it is less simple because Linux distributions often backport security fixes without changing the visible upstream version in a way that satisfies naive scanners.

That means:

Observation	Safe interpretation
Banner says OpenSSH 8.x	Could be vulnerable, or could be vendor-patched with a backport
Banner says OpenSSH 9.6 or later	Better signal, but still verify configuration and client compatibility
Scanner says vulnerable because ChaCha20 is offered	Useful warning, not full proof of exploitable exposure
Server supports strict KEX	Good, but the client must also support it
Server is not internet-exposed	Still matters for hostile Wi-Fi, compromised networks, internal MITM, SFTP partners, bastions, and lateral movement paths

Ubuntu’s CVE page lists the publication date as December 18, 2023, gives a Medium priority and CVSS 5.9, and describes both the affected algorithm classes and a long list of affected SSH products and libraries. (Ubuntu) Red Hat also tracks CVE-2023-48795 in its CVE portal and characterizes it as an SSH channel-integrity flaw involving sequence-number manipulation during the handshake. (Red Hat Customer Portal)

The operational rule is simple: use vendor advisories and package changelogs as the source of truth for managed operating systems, not only the SSH banner. For third-party clients and libraries, use the upstream project’s release notes.

Affected clients, libraries, and products

NVD and Ubuntu list a broad set of affected software, including OpenSSH before 9.6, PuTTY before 0.80, AsyncSSH before 2.14.2, Go x/crypto before 0.17.0, libssh before 0.10.6, Paramiko before 3.4.0, and many other products or libraries. (NVD) This breadth reflects the fact that Terrapin is tied to protocol behavior and negotiated algorithms, not a single source file in one product.

A few examples show how different projects handled it.

Umsetzung	Relevant fix or guidance	What defenders should do
OpenSSH	9.6 introduced strict KEX, terminates unexpected KEX messages, and resets MAC counters	Upgrade both server and client paths, or use vendor-fixed packages
PuTTY	0.80 mitigates Terrapin when connecting to a mitigated server and warns when a vulnerable connection would be possible	Upgrade Windows and Unix PuTTY clients, especially admin workstations
Paramiko	3.4.0 addresses CVE-2023-48795, supports strict KEX behavior, raises errors on unexpected messages in strict mode, and resets packet sequence numbers on MSG_NEWKEYS	Upgrade Python automation, SFTP jobs, and internal tools using Paramiko
Weiter x/crypto/ssh	v0.17.0 fixes the protocol weakness in the SSH package	Update Go modules and rebuild binaries that embed SSH functionality
AsyncSSH	Related implementation flaws were assigned CVE-2023-46445 and CVE-2023-46446	Upgrade AsyncSSH and review applications using it for server or client behavior

PuTTY’s advisory is useful because it frames real user exposure. PuTTY 0.80 fully mitigates Terrapin when connecting to a server that also has mitigations, and otherwise warns before proceeding where the attack would be possible. The PuTTY page also notes that with PuTTY’s default cipher configuration and common server configurations, connections would often not be vulnerable, but specific configuration changes or limited server algorithm offerings can expose the issue. (Chiark)

Paramiko’s changelog for 3.4.0 says it addressed CVE-2023-48795 by adjusting strict KEX behavior, raising a MessageOrderError on unexpected messages during initial key exchange, and resetting packet sequence numbers on MSG_NEWKEYS. It also notes that users unable to upgrade immediately can use disabled_algorithms to disable ETM MACs and CBC ciphers, depending on the version they run. (Paramiko)

The Go team announced that golang.org/x/crypto v0.17.0 fixed a protocol weakness in golang.org/x/crypto/ssh that allowed a MITM attacker to compromise secure-channel integrity before it was established, preventing transmission of a number of messages immediately after the secure channel was established. The announcement also says the attack does not compromise confidentiality and can prevent transmission of SSH2_MSG_EXT_INFO, disabling newer security features. (Google Gruppen)

Why AsyncSSH changed the severity conversation

CVE-2023-48795 is the general protocol flaw. The Terrapin research also led to AsyncSSH-specific CVEs. The public Terrapin FAQ lists CVE-2023-46445 as Rogue Extension Negotiation Attack in AsyncSSH and CVE-2023-46446 as Rogue Session Attack in AsyncSSH. (Terrapin Attack) NVD describes CVE-2023-46446 as an issue in AsyncSSH before 2.14.1 that allows attackers to control the remote end of an SSH client session through packet injection or removal and shell emulation, also called a Rogue Session Attack. (NVD)

This is the main lesson: protocol weaknesses often become more dangerous when paired with implementation state-machine bugs. A pure protocol downgrade might only suppress a negotiated feature. A flawed implementation might process messages out of order, accept a state transition too early, or confuse authentication and connection phases. When the two meet, the impact can move from “feature downgrade” to “session confusion” or worse.

That is why a serious CVE-2023-48795 response should include libraries, clients, and application stacks. A vulnerability management dashboard that only checks Linux openssh-server packages misses a large part of the SSH attack surface.

Detection starts with exposure, but does not end there

The first step is to know where SSH is reachable. That includes public SSH, internal management networks, SFTP endpoints, bastions, cloud instances, network appliances, developer jump hosts, CI runners, and partner-facing file transfer services.

A basic outside-in discovery pass can start like this:

# Replace with your authorized CIDR or asset list.
# Use only against systems you own or are authorized to test.

nmap -p 22 -sV --version-intensity 5 -oA ssh_discovery <YOUR_CIDR>

# Extract hosts with open SSH.
awk '/22\/open/{print $2}' ssh_discovery.gnmap | sort -u > ssh_hosts.txt

This tells you where SSH is visible. It does not prove Terrapin exposure. Version detection can be incomplete, banners can be misleading, and distro backports can make old-looking versions safe. The next step is to inspect actual algorithm negotiation and strict KEX support.

On an individual host, verbose OpenSSH client output can help:

ssh -vv -o PreferredAuthentications=publickey -o BatchMode=yes user@host.example 2>&1 | tee ssh_verbose.log

Look for lines showing key exchange, cipher, MAC, and extension negotiation. On newer OpenSSH clients and servers, you may see strict key exchange indicators in debug logs, depending on version and verbosity. For production validation, however, a purpose-built scanner is usually cleaner.

Using the Terrapin Vulnerability Scanner safely

The RUB-NDS Terrapin Vulnerability Scanner is a Go utility from the research team that checks whether an SSH client or server appears vulnerable. Its README states that it needs a single connection to gather supported algorithms, does not perform a full SSH key exchange, never attempts authentication on a server, and does not perform the attack in practice. It determines vulnerability by checking supported algorithms and support for known countermeasures such as strict key exchange, and may conservatively claim vulnerability if a peer supports countermeasures unknown to the tool. (GitHub)

Server scan example:

# Docker example from the project pattern.
docker run --rm -it ghcr.io/rub-nds/terrapin-scanner --connect ssh.example.com:22

Local binary example:

# Scan the default SSH port.
./Terrapin-Scanner --connect ssh.example.com

# Scan a nonstandard SSH port.
./Terrapin-Scanner --connect ssh.example.com:2222

Client scan example:

# Listen for a client connection on port 2222.
./Terrapin-Scanner --listen 0.0.0.0:2222

# In another terminal or from the client under test:
ssh -p 2222 testuser@scanner-host

For fleet work, JSON output is more useful than console text:

./Terrapin-Scanner --connect ssh.example.com:22 --json > terrapin_ssh_example_com.json

A simple batch wrapper:

#!/usr/bin/env bash
set -euo pipefail

INPUT="${1:-ssh_hosts.txt}"
OUT="${2:-terrapin-results.jsonl}"

: > "$OUT"

while read -r host; do
  [ -z "$host" ] && continue
  echo "[*] Scanning $host" >&2

  if timeout 15 ./Terrapin-Scanner --connect "${host}:22" --json > /tmp/terrapin_one.json 2>/tmp/terrapin_err.log; then
    jq -c --arg host "$host" '. + {target: $host}' /tmp/terrapin_one.json >> "$OUT"
  else
    jq -n -c --arg host "$host" --arg error "$(cat /tmp/terrapin_err.log | tail -n 3)" \
      '{target: $host, scan_error: $error}' >> "$OUT"
  fi
done < "$INPUT"

echo "[*] Results written to $OUT"

Then summarize:

jq -r '
  [.target,
   (.supportsChaCha20 // "unknown"),
   (.supportsCbcEtm // "unknown"),
   (.supportsStrictKex // "unknown"),
   (.vulnerable // "unknown")]
  | @csv
' terrapin-results.jsonl > terrapin-summary.csv

The exact JSON field names may change by tool version, so inspect one output sample before you automate reporting.

Interpreting scanner output without fooling yourself

A Terrapin scan should feed triage, not replace judgment.

Finding	Likely meaning	Next action
Vulnerable algorithm supported, no strict KEX	Treat as likely vulnerable connection path	Patch or restrict algorithms
Vulnerable algorithm supported, strict KEX supported	Better posture, but verify both client and server paths	Retest with representative clients
ChaCha20 supported, AES-GCM also supported	Vulnerability depends on actual negotiation and countermeasures	Confirm preference order and strict KEX
Server banner old, scanner says not vulnerable	Could be algorithm-restricted or backported	Confirm vendor package state
Scanner says vulnerable on an appliance	Often real, but remediation may require firmware or vendor advisory	Open vendor case and apply supported fix
Client library old but servers patched	Risk may remain when connecting to unpatched servers	Upgrade clients and automation libraries

The most common false sense of closure is patching servers only. The Terrapin FAQ explicitly says patched client plus vulnerable server, or vulnerable client plus patched server, can still result in a vulnerable connection because strict key exchange requires both sides. (Terrapin Attack)

The most common false panic is assuming a vulnerable-looking OpenSSH banner means unpatched. Linux vendors routinely backport security fixes. Always check the vendor package version and advisory status for the specific distribution release.

Package and library checks

For Linux servers, capture both the SSH banner and the package version.

Debian and Ubuntu:

ssh -V 2>&1 || true
dpkg -l | grep -E '^ii\s+openssh-(server|client)\s'
apt-cache policy openssh-server openssh-client | sed -n '1,80p'

RHEL, CentOS, Rocky, AlmaLinux, Fedora:

ssh -V 2>&1 || true
rpm -q openssh openssh-server openssh-clients
dnf info openssh-server openssh-clients | sed -n '1,120p'

Alpine:

ssh -V 2>&1 || true
apk info -v | grep -E '^openssh'

Python projects using Paramiko:

python3 - <<'PY'
import importlib.metadata as md

for pkg in ["paramiko", "asyncssh"]:
    try:
        print(f"{pkg} {md.version(pkg)}")
    except md.PackageNotFoundError:
        pass
PY

Go projects using x/crypto/ssh:

go list -m all | grep 'golang.org/x/crypto'

JavaScript and Node.js SSH dependencies:

npm ls ssh2 2>/dev/null || true
npm ls 2>/dev/null | grep -Ei 'ssh|sftp' || true

These checks do not replace a full software composition analysis process, but they catch the common cases: automation scripts, internal SFTP clients, deployment tooling, and embedded SSH clients inside applications.

Mitigation strategy, from clean fix to temporary controls

The durable fix is to upgrade affected SSH implementations so that strict KEX or equivalent mitigation is available on both sides. For OpenSSH, that means OpenSSH 9.6 or a vendor-patched package with the relevant backport. OpenSSH’s release notes describe strict KEX as the fix for Terrapin, automatically enabled when both client and server support it. (OpenSSH)

If immediate upgrading is not possible, temporarily disable the vulnerable algorithm combinations. The Terrapin FAQ recommends disabling chacha20-poly1305@openssh.com und -etm@openssh.com MAC algorithms, and using unaffected algorithms such as AES-GCM. (Terrapin Attack) This is a workaround, not a permanent substitute for patching.

Beispiel sshd_config hardening for servers:

# Temporary Terrapin mitigation profile.
# Test compatibility before deploying broadly.

Ciphers aes128-gcm@openssh.com,aes256-gcm@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr
MACs hmac-sha2-512,hmac-sha2-256

# General SSH hardening that reduces management-plane risk.
PermitRootLogin no
PasswordAuthentication no
KbdInteractiveAuthentication no
PubkeyAuthentication yes
AllowAgentForwarding no
X11Forwarding no

Validate before restart:

sshd -t && systemctl reload sshd

On systems where the service is named ssh:

sshd -t && systemctl reload ssh

Client-side OpenSSH configuration:

Host *
    Ciphers aes128-gcm@openssh.com,aes256-gcm@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr
    MACs hmac-sha2-512,hmac-sha2-256

Per-host configuration is safer when you have legacy systems:

Host legacy-sftp-partner
    HostName sftp.partner.example
    User batch
    Ciphers aes128-gcm@openssh.com,aes256-gcm@openssh.com,aes128-ctr,aes256-ctr
    MACs hmac-sha2-512,hmac-sha2-256

Before deploying algorithm restrictions, test older clients and embedded systems. Some appliances and older SSH clients may not support your preferred algorithms. The security goal is not to break access during an incident. The goal is to reduce vulnerable negotiation paths while moving toward patched implementations.

A safer rollout pattern

A good production rollout has four phases.

Phase	Aktion	Evidence to keep
Entdecken Sie	Find SSH servers, SFTP endpoints, clients, and libraries	Asset list, scan timestamp, network vantage point
Überprüfen Sie	Run Terrapin scanner and package checks	Scanner output, package versions, vendor advisory status
Remediate	Upgrade or restrict algorithms	Change ticket, package update logs, config diff
Retest	Re-run scanner with representative clients	Before and after output, exception list

The evidence matters because Terrapin findings can linger in vulnerability scanners long after you believe remediation is complete. If you can prove that a vendor-patched package is installed, strict KEX is supported, or vulnerable algorithms are disabled, you can close false positives faster.

Evidence bundle example:

#!/usr/bin/env bash
set -euo pipefail

TS="$(date -u +%Y%m%dT%H%M%SZ)"
HOST="$(hostname -f 2>/dev/null || hostname)"
OUT="ssh-terrapin-evidence-${HOST}-${TS}"

mkdir -p "$OUT"

{
  echo "host=$HOST"
  echo "time_utc=$TS"
  echo
  echo "=== ssh client version ==="
  ssh -V 2>&1 || true
  echo
  echo "=== packages ==="
  (dpkg -l | grep -E '^ii\s+openssh-(server|client)\s') 2>/dev/null || true
  (rpm -q openssh openssh-server openssh-clients) 2>/dev/null || true
  (apk info -v | grep -E '^openssh') 2>/dev/null || true
  echo
  echo "=== effective sshd config ==="
  sshd -T 2>/dev/null | egrep -i 'ciphers|macs|kexalgorithms|permitrootlogin|passwordauthentication|kbdinteractiveauthentication|allowagentforwarding|x11forwarding' || true
} | tee "$OUT/evidence.txt"

tar -czf "${OUT}.tar.gz" "$OUT"
echo "Created ${OUT}.tar.gz"

What detection can and cannot see

CVE-2023-48795 is not the kind of vulnerability where you should expect a clean log entry saying “Terrapin attack detected.” The attacker’s goal is to alter early SSH negotiation. Normal sshd logs are usually too high-level to prove that a prefix truncation attempt occurred.

Useful signals are indirect:

Signal	Why it might matter	Begrenzung
SSH sessions negotiating vulnerable algorithms	Indicates exposure if strict KEX is absent	Not proof of attack
Unexpected connection failures after enabling strict KEX	Could reveal incompatible or suspicious peers	Also common during legacy client rollout
MITM-capable network locations	Raises exploit plausibility	Requires network architecture context
Old SSH clients in admin workstations	Can keep risk alive after server patching	Often missing from server-focused inventories
Vulnerable SFTP libraries	Common in file transfer jobs and integrations	Hidden inside application dependencies

For OpenSSH logs, increasing verbosity may help with troubleshooting negotiation, but it is not a detection strategy by itself. Focus on reducing possible negotiation paths and proving strict KEX support rather than trying to hunt for a perfect Terrapin signature.

Why CVSS Medium can still be urgent in some environments

NVD lists CVE-2023-48795 as CVSS 3.1 5.9 Medium with high attack complexity and no confidentiality or availability impact in the base vector, but high integrity impact. (NVD) That scoring is reasonable for a protocol downgrade requiring an active MITM. But CVSS does not know your network.

Raise priority when:

• SSH is exposed to the internet on bastions, appliances, SFTP servers, or cloud instances.
• Users connect from untrusted networks such as airports, hotels, conference Wi-Fi, or contractor networks.
• SFTP is used for regulated data exchange or business-critical file transfer.
• Developers and operators use older SSH clients or PuTTY versions.
• Automation uses older Paramiko, AsyncSSH, Go x/crypto/ssh, Java SSH, or Node SSH libraries.
• You have network locations where a compromised router, proxy, VPN concentrator, or Wi-Fi infrastructure could become a MITM point.

Lower emergency pressure when:

• SSH is reachable only through a tightly controlled private management network.
• Both client and server stacks are known to support strict KEX.
• Vulnerable algorithms have already been disabled.
• Vendor advisories confirm backported fixes.
• You have no known use of vulnerable SSH libraries in automation.

The correct priority is not “Medium means later.” It is “Medium with a protocol-level MITM precondition, adjusted for where SSH sits in our control plane.”

Common hardening mistakes

The first mistake is checking only ssh -V on a server. That reports the client binary. You also need openssh-server package state and sshd effective configuration.

The second mistake is assuming server-side remediation is enough. Strict KEX must be negotiated by both peers. Old clients remain a problem when they connect to unpatched servers, and patched servers cannot force old clients to support a mitigation they do not implement.

The third mistake is disabling ChaCha20 globally without compatibility testing. That may be acceptable in many fleets, but it can break older appliances, embedded clients, or partner SFTP flows. A staged rollout with monitoring is safer.

The fourth mistake is letting vulnerability scanner output override vendor truth. If a distribution backported the fix, the visible upstream OpenSSH version may remain old. If a scanner cannot understand that backport, you need evidence from the vendor package and advisory.

The fifth mistake is ignoring libraries. Terrapin is an SSH ecosystem issue. Python, Go, Java, Rust, Node, Windows desktop clients, SFTP tools, and appliances can all carry SSH stacks.

Related CVEs that help frame the risk

CVE-2023-46445 and CVE-2023-46446 are directly tied to the Terrapin research because they describe AsyncSSH implementation-level issues found in the same investigation. The Terrapin project identifies CVE-2023-46445 as Rogue Extension Negotiation in AsyncSSH and CVE-2023-46446 as Rogue Session Attack in AsyncSSH. (Terrapin Attack) These matter because they show how a protocol-level truncation primitive can become more serious when an implementation accepts unexpected message flows.

CVE-2024-6387, known as regreSSHion, is a different OpenSSH issue: a server-side sshd regression involving unsafe signal handling and potential pre-auth compromise in affected Portable OpenSSH versions. Penligent’s OpenSSH regreSSHion write-up frames sshd as a control-plane hinge for fleets, bastions, appliances, CI runners, and break-glass access, which is also the right operational lens for Terrapin even though the bug class is different. (Sträflich)

The broader lesson is not that all SSH vulnerabilities are the same. They are not. Terrapin is a negotiation integrity issue. regreSSHion is a daemon implementation issue. AsyncSSH rogue-session flaws are state-machine implementation issues. But all of them affect the same operational surface: the remote administration and file-transfer path that defenders rely on when everything else is broken.

Strict KEX is necessary, but implementation quality still matters

A later 2025 research paper on SSH strict KEX implementation found that strict KEX simplifies the SSH handshake model by forbidding optional messages during the handshake, but implementation differences still matter. The authors analyzed ten SSH implementations supporting strict KEX, learned 33 state machines, and reported that seven implementations violated the strict KEX specification; they also identified critical vulnerabilities in Tectia SSH and Erlang OTP SSH. (arXiv)

That does not mean strict KEX is bad. It means protocol hardening must be implemented correctly. OpenSSH and Go’s x/crypto/ssh are described in that paper as strict-KEX compliant in the analyzed setting, while several other implementations had deviations or taint-style approaches. (arXiv)

For defenders, the conclusion is practical: prefer maintained SSH implementations, keep them current, and do not assume that a feature name in a banner equals correct behavior under edge-case protocol flows.

A practical remediation playbook

Use this workflow for CVE-2023-48795 response.

First, inventory:

# External view.
nmap -p 22 -sV --version-intensity 5 -iL external_assets.txt -oA external_ssh

# Internal management networks.
nmap -p 22 -sV --version-intensity 5 -iL internal_mgmt_assets.txt -oA internal_ssh

Second, scan for Terrapin-relevant negotiation:

while read -r host; do
  ./Terrapin-Scanner --connect "${host}:22" --json > "results/${host}.json" || true
done < ssh_hosts.txt

Third, check packages and libraries on managed systems:

# Linux OpenSSH packages.
ansible linux_servers -b -m shell -a '
  (dpkg -l | grep -E "^ii\s+openssh-(server|client)\s") 2>/dev/null ||
  (rpm -q openssh openssh-server openssh-clients) 2>/dev/null ||
  (apk info -v | grep -E "^openssh") 2>/dev/null || true
'

Fourth, upgrade or apply vendor patches. Do not build your own OpenSSH in production unless that is already your operating model. Use distribution packages where possible, because they preserve service integration, SELinux or AppArmor profiles, systemd units, audit behavior, and vendor support.

Fifth, apply temporary algorithm restrictions only where needed:

Ciphers aes128-gcm@openssh.com,aes256-gcm@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr
MACs hmac-sha2-512,hmac-sha2-256

Sixth, retest with real clients. Include:

• Admin laptops using OpenSSH.
• Windows users using PuTTY, WinSCP, SecureCRT, or other SSH clients.
• CI runners.
• Deployment bots.
• Backup systems.
• SFTP partner integrations.
• Application code using SSH libraries.

Seventh, document exceptions. Some appliances will require firmware, vendor support cases, or temporary compensating controls. For each exception, record reachable network scope, supported algorithms, vendor status, business owner, and target remediation date.

In authorized security testing and CVE validation programs, teams can use Penligent to keep this kind of SSH exposure workflow repeatable: discover reachable assets, validate configuration and version evidence, track remediation state, and preserve the proof needed for internal reporting without turning the process into a one-off spreadsheet. (Sträflich) The value is not “an AI says it is fixed”; the value is forcing each claim to be tied to evidence such as package state, algorithm negotiation, scanner output, and post-change validation.

Configuration examples for different risk positions

A modern, stricter OpenSSH server profile:

# Modern SSH baseline. Test before rollout.

Protocol 2

# Authentication posture.
PermitRootLogin no
PasswordAuthentication no
KbdInteractiveAuthentication no
PubkeyAuthentication yes
MaxAuthTries 3

# Reduce forwarding abuse.
AllowAgentForwarding no
AllowTcpForwarding no
X11Forwarding no
PermitTunnel no

# Terrapin temporary mitigation if strict KEX cannot be guaranteed everywhere.
Ciphers aes128-gcm@openssh.com,aes256-gcm@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr
MACs hmac-sha2-512,hmac-sha2-256

# Operational visibility.
LogLevel VERBOSE

A client-side profile for sensitive admin hosts:

Host prod-* bastion-* sftp-critical
    PubkeyAuthentication yes
    PasswordAuthentication no
    KbdInteractiveAuthentication no
    Ciphers aes128-gcm@openssh.com,aes256-gcm@openssh.com,aes128-ctr,aes256-ctr
    MACs hmac-sha2-512,hmac-sha2-256
    ForwardAgent no
    ServerAliveInterval 30
    ServerAliveCountMax 3

A compatibility exception should be explicit:

Host legacy-partner-sftp
    HostName sftp.legacy-partner.example
    User batchuser

    # Temporary exception approved in CHG-12345.
    # Remove after partner upgrades SSH server.
    Ciphers aes128-ctr,aes256-ctr
    MACs hmac-sha2-256
    ForwardAgent no

Never hide legacy exceptions inside global configuration. Make them visible, owned, and time-bounded.

SFTP and managed file transfer considerations

SFTP runs over SSH, so Terrapin can matter for SFTP clients and servers too. The risk is not that every SFTP file payload is decrypted. The risk is that the SSH session setup can lose integrity under vulnerable conditions, potentially suppressing extension information or interacting with implementation flaws.

SFTP-heavy environments should check:

• Managed file transfer appliances.
• Partner-facing SFTP endpoints.
• Batch jobs using Paramiko, JSch, sshj, Go SSH, Node ssh2, or vendor SDKs.
• Desktop SFTP clients used by operations teams.
• File transfer gateways embedded in ERP, data warehouse, billing, healthcare, or logistics workflows.

The easiest place to miss CVE-2023-48795 is not the Linux bastion you patch every week. It is the old SFTP connector nobody wants to touch because it moves a critical file at 2:00 a.m. every day.

How to explain the risk to non-specialists

A useful internal explanation is:

“Terrapin does not mean SSH encryption is gone. It means a network attacker who can actively sit between a client and server may be able to remove certain early SSH negotiation messages when vulnerable algorithms are used. That can downgrade some security features. The permanent fix is to update SSH clients and servers so both support strict key exchange. Where we cannot patch immediately, we will disable the vulnerable algorithm combinations and verify the result.”

That message avoids both panic and minimization. It explains the attacker position, the impact, and the remediation path.

For a risk register, use language like:

Risk statement	Better than
“Some SSH connections may allow early-channel prefix truncation under CVE-2023-48795 when vulnerable algorithms are negotiated and strict KEX is absent.”	“SSH is broken.”
“MITM capability is required, but SSH is a privileged management channel, so exposed and high-trust paths should be prioritized.”	“Medium CVSS, defer.”
“Fix requires both client and server support for strict KEX or temporary algorithm restrictions.”	“Patch the server only.”
“Scanner output must be reconciled with vendor backports and actual negotiated algorithms.”	“Banner says old, therefore vulnerable.”

FAQ

Is CVE-2023-48795 the same as SSH being cracked?

• No. CVE-2023-48795 is an SSH protocol integrity and downgrade issue, not a universal break of SSH confidentiality.
• The attacker needs active man-in-the-middle capability and vulnerable negotiated algorithms.
• The best-known OpenSSH impact is deletion of early extension information, not passive decryption of shell traffic.
• It still matters because SSH is often used for privileged administration, automation, and SFTP.

Can Terrapin steal SSH passwords or private keys?

• Terrapin by itself is not described as a direct password or private-key theft vulnerability.
• It can suppress or downgrade some negotiated security features, especially extension negotiation.
• Implementation-specific flaws can make the situation worse, as shown by the AsyncSSH-related CVEs.
• Private keys should still be protected with normal controls: no agent forwarding by default, hardware-backed keys where possible, and patched clients.

Does upgrading only the SSH server fix the issue?

• Not always.
• Strict KEX must be supported by both the client and the server to protect the connection.
• Server patching is necessary, but old clients, old libraries, and old SFTP tools can keep risk alive.
• Retest using the actual clients that administrators, CI jobs, and file-transfer systems use.

Is disabling ChaCha20 enough?

• Disabling chacha20-poly1305@openssh.com reduces one major Terrapin exposure path.
• You must also review CBC ciphers combined with Encrypt-then-MAC MACs.
• Algorithm restrictions are a temporary mitigation when patching is delayed.
• The durable fix is to run SSH implementations that support strict KEX correctly.

Why do vulnerability scanners still flag patched systems?

• Some scanners rely on banners or supported algorithms and may not understand vendor backports.
• A server can advertise an older OpenSSH version while containing a distribution backport.
• A scanner may also report conservatively if it sees vulnerable algorithms but cannot confirm a countermeasure.
• Keep evidence: package versions, vendor advisory status, strict KEX support, and before-and-after scan results.

Does Terrapin affect SFTP?

• SFTP uses SSH as its transport, so SSH negotiation weaknesses can affect SFTP sessions.
• The most important SFTP risk is often hidden clients and libraries inside scheduled jobs, partner integrations, and managed file transfer systems.
• Patch SFTP servers and clients, not just interactive SSH servers.
• Test partner workflows before disabling algorithms globally.

How should an enterprise prioritize CVE-2023-48795?

• Prioritize internet-exposed SSH, bastions, SFTP endpoints, network appliances, and high-privilege automation.
• Include admin workstations and CI runners because clients matter.
• Use vendor advisories for package truth, not only SSH banners.
• Apply temporary algorithm restrictions only with compatibility testing and a plan to remove exceptions.

Should I remove SSH from the internet because of Terrapin?

• Reducing SSH exposure is good practice, but CVE-2023-48795 alone does not require panic removal in every environment.
• Exposed SSH should be restricted to known source ranges, protected by strong authentication, monitored, and kept patched.
• For high-value management paths, prefer VPN, zero-trust access, or bastion models with tight logging.
• Treat Terrapin as a reason to improve SSH governance, not as the only reason to redesign access.

Closing judgment

CVE-2023-48795 is a reminder that secure transport is not only about strong ciphers. It is also about transcript integrity, extension negotiation, message ordering, state-machine discipline, and whether both ends of a connection actually support the same countermeasures. Terrapin does not make every SSH session readable, and it should not be sold internally as instant compromise. But it also should not be dismissed because of a Medium score.

The practical fix is straightforward: identify SSH exposure, upgrade clients and servers, verify strict KEX on real connection paths, disable vulnerable algorithm combinations only as a temporary bridge, and keep evidence. The teams that handle Terrapin well are the ones that treat SSH as a living control plane rather than a background service that only matters when someone cannot log in.