Encryption finding · Edge

SSH Weak Key Exchange Algorithms Enabled: Fix It or Document It

Your scanner flagged SSH weak key exchange algorithms (Nessus 153953). What it means, how to move to modern and post-quantum key exchange, and what to document.

What the scanner said

SSH Weak Key Exchange Algorithms EnabledSSH Server CBC Mode Ciphers EnabledSSH Weak MAC Algorithms Enableddiffie-hellman-group1-sha1

Your scanner found an SSH server, on a server, firewall, switch, or appliance, that still offers old key exchange methods built on SHA-1 or 1024-bit keys. Tenable reports it as plugin 153953, based on RFC 9142, the IETF guidance on which methods SSH should stop using. Two findings often come with it: SSH Server CBC Mode Ciphers Enabled and SSH Weak MAC Algorithms Enabled. Scanners rate them Low, yet the key exchange protects every session to the device's management console.

Why it matters

Your administrators are already seeing a warning. Current OpenSSH clients warn on every connection to a server that can't offer post-quantum key exchange: "This session may be vulnerable to 'store now, decrypt later' attacks." OpenSSH made hybrid post-quantum key exchange its default in April 2025, so a device still offering SHA-1 methods is two steps behind.

Management sessions carry administrator credentials and device configurations, the traffic most worth recording today and decrypting later. The controls you answer for all expect strong encryption on administrative access: NIST 800-53 AC-17(2), PCI DSS 2.2.7, and NERC CIP-005 R2 where it applies.

The fix

We change it in three steps on every device that can take it: remove the old methods the scanner named, keep modern ones so existing tools still connect, and put hybrid post-quantum key exchange first wherever the SSH software supports it. The cipher and integrity findings close in the same change.

Linux and Windows servers, network gear, and appliances each set this differently, and we handle each; a clean scanner rerun is the evidence. Every device's SSH version goes into your cryptographic inventory, so you know which can move to post-quantum now and which need a firmware update or replacement first. See the crypto-agility practice.

When you can't fix it

Some devices can't change: older switches, management controllers, and OT equipment with a fixed SSH stack. Keep those reachable only from a management network or through an identity-gated path, so the weak method covers just the last short hop.

Record each one with its compensating control, an owner, and a date to revisit. That record is the crypto-agility plan for that device. See compensating controls for legacy systems, or the Risk-Acceptance Memo on the published price list.

Where it lands in the Risk Register

Finding	Treatment	Owner	Evidence
SSH server offers SHA-1 or 1024-bit key exchange methods on a named host (Nessus 153953)	Remediate (remove weak methods, add hybrid post-quantum where supported), or accept with compensating controls	Named by you	Scanner output before and after, the configuration change, and the device's SSH version in your cryptographic inventory. Maps to NIST 800-53 AC-17(2) and SC-13, and PCI DSS 2.2.7 where it applies.

Common questions

Is there a CVE for SSH weak key exchange algorithms?

No single CVE. It's a configuration check (Tenable 153953) based on RFC 9142, rated Low.

How do I fix it on Windows?

Windows Server runs OpenSSH, so it's the same three steps in its SSH configuration, then a restart and a rescan. Post-quantum key exchange needs a recent OpenSSH version.

Is this the same as Terrapin?

No. Terrapin (CVE-2023-48795) is a separate SSH flaw, closed by updating both ends to current OpenSSH, and worth checking in the same change.

Will removing the old methods break connections?

Only for tools that support nothing newer. We find those first, then update them or keep them on an isolated path.