Why SecureCRT Fails on New Linux and How to Fix It

Several colleagues reported that after installing fresh Linux systems such as Ubuntu 24.04, Rocky 9 or CentOS Stream, SecureCRT could not connect to remote hosts, while Xshell or the command‑line ssh worked.

Key exchange failed
No matching host key type found

Root Cause

New Linux releases disable older SSH algorithms (e.g., ssh‑rsa with SHA‑1) by default. Older versions of SecureCRT rely solely on these deprecated algorithms, causing the handshake to fail.

Solution Options

Upgrade SecureCRT : Install SecureCRT 9.6.4 (x64 build 3695), which includes support for the newer algorithms.

Or manually enable the modern algorithms in the existing SecureCRT client:

Open Session → Session Options → Connection → SSH2:
Check Key Exchange:
  curve25519‑sha256
  ecdh‑sha2‑nistp256
Check Host Key Type:
  RSA‑SHA2‑256
  RSA‑SHA2‑512
(Apply the same settings in SecureFX if used.)

After adjusting these settings and reconnecting, the connection usually succeeds.

Why Xshell Works

Xshell enables the newer algorithms by default, so no manual configuration is required. SecureCRT’s conservative defaults are intentional, not a bug.

Practical Advice

If corporate policy forces the use of CRT (e.g., audit requirements), you must adapt the client to the new environment. Otherwise, consider alternatives such as Xshell, Tabby, or WindTerm, which handle modern SSH algorithms out of the box.

Remember that the tool itself is neutral; the key is understanding why it fails and how to make it work.