In December 2023, Fabian Bäumer, Marcus Brinkmann and Jörg Schwenk from the Ruhr University Bochum have published their paper¹ about the Terrapin attack onto the SSH protocol that got very wide attention. Thanks to their responsive disclosure, the industry had already developed a protocol extension, collectively referred to as "Strict Kex", now also available as Internet-Draft² and first new product versions were immediately available at the time of disclosure.

For Strict Kex to become effective, both the client and the server must support this extension. Hence, it is important to monitor the adoption process of the new versions. Now, 16 months, or 5 quarters since the disclosure, let's have a look across publicly available SSH Servers on the Internet.

Too long to read? Check the takeaways bullet points at the end.

SSH Server Patch status

For this research, we did not crawl the entire Internet but randomly selected 250k servers (precisely 255,241 servers across all Internet subnets) which allow incoming port 22 traffic from any IPv4 Internet address. Comparing the results to the original paper, this sample set offers a reasonable representation of the global distribution.

When connecting to each server, we recorded product names, announced key exchange algorithms and protocol extensions. Specifically, we checked how many servers announce support for the Strict Kex capability. Then, we aggregated the results across some categories of product names and versions to provide insights into both the deployment rate and the adoption rate of Strict Kex in each category.

As shown in Table 1, more than 90% of SSH servers on the Internet are claiming to be an OpenSSH implementation. OpenSSH version 9.6 has been released right at the Terrapin disclosure time in December 2023 and introduced the Strict Kex implementation. By now, more than 16% of all OpenSSH servers are of version 9.6 or newer and almost all of them support Strict Kex (the few outliers either have this capability manually disabled or a different server implementation uses a falsified product name).
A special mention goes to the large Unix distributions, namely Ubuntu and Debian, for backporting the Strict Kex implementation also to earlier versions of OpenSSH and providing that update to previous versions of Linux. As a result, over 57% of the deployed Pre-9.6-OpenSSH versions are already providing Strict Kex support, which brings the totally deployed set of patched OpenSSH servers to 64.58%!

Among the remaining 8.5% Non-OpenSSH servers, Dropbear leads with a 46% share and also got a first version with Strict Kex support right in December 2023. Dropbear installations version 2022.84 or newer fully support the extension. However, those versions only make up less than 1% of all seen Dropbear installations. Older versions and deployments not announcing their version are the vast majority and those have very little support for this new extension. Consequently, Dropbear's total support rate for Strict Kex is only 3.3%!

The next largest product type with a 14% share of the Non-OpenSSH deployments is Rosssh. Unfortunately, we did not see any Rosssh server in our sample set that supports Strict Kex, although Rosssh likewise reacted quickly and provided an implementation of Strict Kex in December 2023!

Similarly, the next largest deployment, AWS-SFTP, shows a rather surprisingly low rate of 0.45% for Strict Kex, although one could assume that patching in public cloud platforms would be rather frequent.

We like to call out Mod-SFTP and Lancom as two vendors who got their global deployment updated by more than 77% (Mod-SFTP), respectively more than 42% (Lancom) although only having a rather low share of the overall deployed servers.
Finally the remaining 1,800+ products make up the remaining quarter of Non-OpenSSH servers and that mix has a 14% patch rate for Strict Kex.

In sum, across all Non-OpenSSH server implementations only 7.5% have been patched for Strict Kex and that finally brings the total share of publicly reachable SSH servers of all types to 59.73%

In other words: Five quarters after the Terrapin disclosure, if you connect to an unknown SSH server on the Internet, you have a 40% chance that it does NOT yet support Strict Kex!

Authentication Encryption Modes

We are using the same categories as in the original paper to classify the Encryption and MAC algorithms into Cipher Families and Authentication Encryption Modes (AE Modes) but show them separately for Strict Kex and Non-Strict Kex servers.

The Cipher Families table does not provide a lot of additional value on top of the Authentication Encryption Modes, thus we are focusing on AE Modes exclusively.

As shown in Table 2, the support for ChaCha20-Poly1305 has increased further, almost all of the Strict Kex servers are supporting this method now and 79% declare it as their preferred method; this is 19 percentage points more than for Non-Strict Kex servers. But even among 60.64% of the Non-Strict Kex servers, ChaCha20-Poly1305 is the preferred method, which is slightly more than the 57.64% from the October 2023 test run reported in the original Terrapin paper!

This is surprising, given the recommendation to disable vulnerable ciphers as a stop-gap in installation that cannot be upgraded to new SSH versions.
Thus we can note that this suggested counter measurement was not followed but upgrading to Strict Kex versions defines the single industry response to Terrapin!

The good news is that the Strict Kex versions are showing some form of consolidation of supported authentication encryption modes:
Almost all servers support the first four methods (ChaCha20-Poly1305, AES-GSCM, AES-CTR-EaM and AES-CTR-EtM) with a clear preference for the first two. The support for the AES-CBC methods is steadily decreasing and even more so the support of more exotic ciphers.
This shows a healthy trend towards finding the right balance between keeping fallback methods available but reducing the overall complexity in the SSH key exchange process.

Extensions

Across all tested SSH servers, 89.06% are sending server extensions; for those servers supporting Strict Kex that ratio even increased to 98.64%

Table 3 shows which extensions are claimed by the servers (where 100% are all the servers of that category that provide at least one extension to the client).

All servers with server extensions support the server-sig-algs extension (although 0.02 have a typo when announcing the capability). The support to bind the public key to the host and the support for the PING extension have increased nicely with newer product versions that also provide the Strict Kex support.

Further analysis of the signature algorithms extension reveals that almost all the Strict Kex servers support rsa-sha2-256 and rsa-sha2-512; 96% also support ssh-ed25519; this ratio is 15 percentage points higher compared to all SSH server versions.

Almost the same level of increase occurred for the ecdsa-sha2-nistp256/384/521 algorithms. Support for sk-ssh-ed25519 and sk-ecdsa-sha2-nistp256 even increased by 22 percentage points to now close to 89% of all Strict Kex servers.

Even the support for the legacy ssh-rsa and ssh-dss has increased slightly and is now at 71% each, as well as 49% support for webauthn-sk-ecdsa-sha2-nistp256. On top, there are 50 additional methods with a total of 2.57% support (compared to 67 methods with 3.24% support across all servers).

It would be nice to see the industry achieving more consolidation on signature algorithms and follow the same trend we can see for authentication encryption methods.

How SSH implementations could be improved

Remember that both the SSH client and the SSH server must support Strict Kex in order to get the new mode enabled. Switching to non-vulnerable authentication encryption modes would mitigate the problem for Non-Strict Kex servers, however the usage of ChaCha20-Poly1305 even increased with the introduction of new implementations.
At the time of the initial patch in 2023, it would have been possible to introduce a new "ChaCha20-Poly13-OnlyInStrictMode" identifier that would automatically disable that encryption cipher for all legacy implementations, would fall back to not vulnerable ciphers but would retain the preferred cipher for the new Strict Kex servers only. But that ship has sailed and such an implementation does not make sense any longer.

Still, implementations in Strict Kex mode could do the following: We learned that by now 60% of all implementations on the server side and potentially even more on the client side support the Strict Kex mode. The patched servers are likely to be accessed the most, so that the vast number of actual SSH sessions run already in Strict Kex mode.
Now, if a non-strict Kex process has been negotiated AND if a vulnerable authentication encryption mode has been chosen, the client implementation could abort the Kex process and disconnect from the server. Then it enters that server IP onto a list of still-vulnerable implementations and when it reconnects to servers of that list, the client removes the vulnerable AE modes from its Kex packet so that a fallback cipher will be negotiated. As this will only happen for servers on this special list, the global performance impact will be minimal. When, at a further point in future, the server will be patched, the client will notice this by reading the Strict Kex extension and can then remove the IP address from the list so that following connections can benefit from the preferred ChaCha20-Poly1305 cipher again.

Such an implementation would provide a smart response to the patch status of the SSH server preventing a Terrapin attack in each case without affecting the cipher choice more than necessary.

Summary of the takeaways

With this analysis we discovered these four takeaways:

• Patch rate: Five quarters after the Terrapin disclosure 40% of publicly available SSH servers are still unpatched.
• No other countermeasures deployed: Recommendations to remove vulnerable ciphers in non-patched servers were largely ignored.
• Kex algorithm consolidation: Consolidation has started for Authentication Encryption Modes, but there still is a long way to go, especially for user signature algorithms.
• Improved implementations: SSH clients could add code to prevent the Terrapin attack in all cases by smarter response to the Strict Kex support status of a server.

References

• [1] F. Bäumer, M. Brinkmann, J. Schwenk, Terrapin Attack: Breaking SSH Channel Integrity By Sequence Number Manipulation, 2023-12-19, arXiv:2312.12422
• [2] D. Miller, SSH Strict KEX extension, 2025-03-18, Internet Engineering Task, draft-miller-sshm-strict-kex-01