SSH Weak MAC Algorithms Enabled

This Tenable finding is not a software-version vulnerability; it is a configuration exposure. Plugin 71049 fires when an SSH server advertises MD5-based or 96-bit truncated MACs such as hmac-md5, hmac-md5-96, or hmac-sha1-96, and Tenable explicitly notes it checks the server options only, not a vulnerable package version. In practice, any SSH implementation or appliance config that still offers those MACs is in scope, so there is no universal affected version range and no single patched build to chase.

Tenable calling this LOW is basically right. The real-world attack requires an attacker to be on path to an SSH session and, in many environments, also depends on a client actually negotiating one of the weaker MACs instead of a stronger default like hmac-sha2-* or *[email protected]. That makes this a crypto hygiene / compliance issue first and an operational intrusion path only in narrower, already-bad conditions.

Why this verdict

• Downward pressure: requires on-path access. This is not unauthenticated remote code execution; it usually implies the attacker already controls a local segment, gateway path, Wi-Fi, or VPN transit.
• Downward pressure: weak MACs may be enabled but never selected. Modern OpenSSH defaults prefer stronger SHA-2 and *-etm options, so many real sessions won't use the bad algorithms at all.
• Downward pressure: no software flaw to weaponize at scale. Tenable explicitly says the plugin checks server options only, not vulnerable versions, and there is no CVE/KEV/EPSS signal amplifying urgency.

Why not higher?

If this were directly reachable internet infrastructure with a pre-auth remote exploit or reliable active exploitation evidence, the score would climb fast. But this finding needs multiple stacked prerequisites—reachability, on-path position, and negotiated use of the weaker MAC—which makes the real attack path much narrower than the crypto label alone suggests.

Why not lower?

It is still a legitimate security weakness on a management protocol, and auditors are right to push it out of the environment over time. Publicly reachable SSH, legacy SFTP integrations, and old network gear can still keep these MACs live longer than teams think, so this should remain on the hardening backlog rather than be dismissed entirely.

1. Remove weak MACs from server config — Delete MD5 and truncated 96-bit MACs from sshd_config or the platform-specific SSH policy so the server cannot negotiate them. For a LOW verdict there is no mitigation SLA; treat this as backlog hygiene and complete it in the next normal SSH hardening cycle.
2. Restrict SSH exposure — Limit SSH to admin networks, VPN, bastions, or allowlisted source ranges so casual internet enumeration cannot even reach the service. This reduces the reachable population immediately; for LOW, schedule it as part of routine access-control cleanup rather than emergency work.
3. Standardize client/server crypto policy — Push a supported MAC allowlist to both servers and managed clients so legacy overlap does not silently keep weak algorithms negotiable. With a LOW verdict, handle this during your next baseline refresh and exceptions review.
4. Validate negotiated algorithms on critical paths — For high-value bastions, SFTP gateways, and network gear, confirm what MACs are actually negotiated in live sessions instead of trusting scanner presence alone. That lets you identify the few systems where this finding is operationally real versus merely configurable.

Run this on the target Linux/macOS host that exposes SSH, preferably as root so sshd can fully evaluate the active configuration. Save as check_ssh_weak_macs.sh and run sudo bash check_ssh_weak_macs.sh /etc/ssh/sshd_config; it outputs VULNERABLE, PATCHED, or UNKNOWN and exits with 1, 0, or 2 respectively.

#!/usr/bin/env bash
# check_ssh_weak_macs.sh
# Purpose: determine whether the local SSH server is configured to allow weak MD5 or 96-bit MAC algorithms.
# Exit codes:
#   0 = PATCHED
#   1 = VULNERABLE
#   2 = UNKNOWN

set -u

CFG="${1:-/etc/ssh/sshd_config}"

find_sshd() {
  if command -v sshd >/dev/null 2>&1; then
    command -v sshd
    return 0
  fi
  for p in /usr/sbin/sshd /usr/local/sbin/sshd /sbin/sshd; do
    if [ -x "$p" ]; then
      echo "$p"
      return 0
    fi
  done
  return 1
}

SSHD_BIN="$(find_sshd)" || {
  echo "UNKNOWN: sshd binary not found"
  exit 2
}

if [ ! -f "$CFG" ]; then
  echo "UNKNOWN: config file not found: $CFG"
  exit 2
fi

# Try to evaluate the effective server config. This handles Include directives and defaults better than raw parsing.
MACS_LINE=""
if MACS_LINE="$($SSHD_BIN -T -f "$CFG" 2>/dev/null | awk '/^macs /{print $2; exit}')"; then
  :
elif MACS_LINE="$($SSHD_BIN -G -f "$CFG" 2>/dev/null | awk '/^macs /{print $2; exit}')"; then
  :
else
  echo "UNKNOWN: could not evaluate active sshd configuration with '$SSHD_BIN -T' or '-G'"
  exit 2
fi

if [ -z "$MACS_LINE" ]; then
  echo "UNKNOWN: no effective MAC list returned by sshd"
  exit 2
fi

WEAK_REGEX='(^|,)(hmac-md5|hmac-md5-96|hmac-sha1-96|[email protected]|[email protected]|[email protected])(,|$)'

if echo "$MACS_LINE" | grep -Eq "$WEAK_REGEX"; then
  echo "VULNERABLE: weak MACs enabled -> $MACS_LINE"
  exit 1
fi

echo "PATCHED: no MD5 or 96-bit weak MACs found -> $MACS_LINE"
exit 0

Sources

1. Tenable plugin 71049
2. IETF RFC 4253 SSH Transport Layer Protocol
3. OpenBSD `sshd_config` manual
4. NIST SP 800-131A Rev. 2
5. `ssh-audit` GitHub repository
6. Nmap `ssh2-enum-algos` script documentation
7. CISA Known Exploited Vulnerabilities Catalog
8. FIRST EPSS FAQ