blueredix logo
SCAN On-demand vulnerability scans from €149
info service-ssh-cve

Vulnerabilities in OpenSSH

OpenSSH is the front door to most servers on the internet. The really serious bugs are rare; on the other hand, version-only matching produces a lot of noise. How to read SSH findings sensibly.

Why SSH findings need a careful read

OpenSSH is on practically every Linux server connected to the internet. CVEs in OpenSSH therefore look very scary in scan reports — and almost always need a second look before you panic.

Two reasons:

  1. The truly serious bugs in OpenSSH are rare. Bugs that allow an attacker to take over an SSH server without an account come every few years. The 2024 regreSSHion (CVE-2024-6387) was the first practical such bug in many years, and even that one was a tricky timing condition that needed thousands of connection attempts to exploit reliably.
  2. Most OpenSSH servers are managed by their operating system. Ubuntu, Debian, RHEL, SUSE, and Amazon Linux all back-port security fixes onto a stable upstream version. “OpenSSH 9.6p1” on Ubuntu 24.04 has the patches for upstream 9.6p1’s bugs — so the long list of CVEs that public databases say affect 9.6p1 are mostly already fixed on your machine. Looking at the version number alone produces a flood of false positives.

The blueredix scanner handles both. Distribution-tagged builds short-circuit the database lookup with an info-level “distribution-managed” notice, and an applicability filter rejects CVEs whose vulnerable description doesn’t actually match your version with explicit version bounds.

When an OpenSSH CVE is a real concern

Look at the distribution-managed flag on the finding first.

  • Distribution-managed and KEV-flagged or EPSS > 0.3. A known-exploited bug exists, and you need to confirm your distribution has shipped the fix. Check your distribution’s security tracker (USN, DSA, RHSA) for the CVE ID and confirm the installed package is at-or-above the patched version. On Ubuntu, apt list --installed openssh-server plus the security-notice text is enough.
  • Distribution-managed and not KEV / low EPSS. The distribution will pick this up in the regular security stream. Schedule the patch but no fire drill.
  • Not distribution-managed (custom build, vendor appliance). Read the CVE description. Is it pre-authentication or post-authentication? Pre-authentication is rare enough to warrant out-of-band action; post-authentication is much less urgent for a properly configured server.

Pre-authentication vs. post-authentication

OpenSSH has two distinct attack-surface zones:

  • Pre-authentication. The attacker just needs network access to the SSH port. Bugs here are universal-impact: every server visible on the internet running the affected version is at risk. CVE-2024-6387 (regreSSHion) is the recent example.
  • Post-authentication. The attacker has already logged in. Bugs here let an attacker who shouldn’t have escalated their privilege do so. Concerning if combined with weak SSH key management; less concerning otherwise.

For an unauthenticated attacker on the public internet, pre-authentication bugs are what matters. Most scary-sounding SSH CVE descriptions resolve to “post-authentication memory bug affecting privilege separation” or “local-side bug in ssh-agent” once you read past the headline.

SSH hardening that pays off independently of CVEs

Most actual SSH compromises don’t come from OpenSSH CVEs — they come from weak credentials. Worth enforcing regardless of what the scanner says:

  1. Disable password authentication. PasswordAuthentication no in sshd_config. Public keys only.
  2. Disable root login. PermitRootLogin no. If you need root, use sudo from an unprivileged account.
  3. Bind to a specific IP if you don’t need public SSH — ListenAddress 10.0.0.5. The most effective defence is “the service isn’t reachable from where the attackers are”.
  4. Run a brute-force guard like Fail2Ban or CrowdSec on internet-exposed servers. Doesn’t stop a sophisticated attacker but cuts the noise floor by 99%.
  5. Use ed25519 keys instead of RSA when generating new ones — smaller, faster, and free of the theoretical risks of short RSA keys.

How blueredix surfaces SSH findings

For SSH the report shows:

  • The detected version and patch suffix (OpenSSH 9.6p1 Ubuntu 3ubuntu13.4).
  • The detected distribution if recognisable.
  • Either a list of applicable CVEs (filtered as described above) or a single info-level “distribution-managed” notice that redirects you to your distribution’s security tracker.

If you see a long list of CVEs from before 2020 against a modern OpenSSH, the applicability filter has already trimmed what the public database originally returned — see How to read a CVE for the underlying mechanism.

Further reading