OpenBSD OpenSSH sshd MaxAuthTries mishandling enables remote denial of service

sshd in OpenSSH before 10.4 allows remote attackers to cause a denial of service (resource consumption from excessive authentication attempts) because MaxAuthTries was mishandled for GSSAPIAuthentication.

• OpenBSD OpenSSH: the record identifies versions from 0 through less than 10.4 as affected, using a custom version type. The product's default status in the record is unaffected outside the listed range.
• Fixed release: OpenSSH 10.4 is the confirmed fixed release identified by the supplied affected facts and vendor release notes.
• No separate downstream backport ranges are provided, so the status of distributor-supplied packages must be verified independently.

sshd processes authentication attempts before login. When GSSAPIAuthentication is enabled, MaxAuthTries is mishandled, so the limit does not adequately protect resources against excessive authentication attempts. The supported attack path is remote and pre-authentication, requiring no valid account or user interaction. OpenSSH release notes state that GSSAPIAuthentication is disabled by default and that the activity can be penalised by PerSourcePenalties, but MaxAuthTries does not mitigate this case. The record classifies the flaw as CWE-770, allocation of resources without limits or throttling. Public sources do not specify the exact code path, resource type, or exhaustion threshold, so those implementation details remain unknown.

• The affected service is reachable over the network; a remote attacker requires no prior authentication and no user interaction.
• Exploitation occurs during pre-authentication and requires GSSAPIAuthentication to be enabled. This feature is disabled by default.
• The attacker sends excessive authentication attempts to drive resource consumption. MaxAuthTries does not prevent the described condition; OpenSSH notes that PerSourcePenalties can penalise the activity.
• The supplied record marks public_exploit as false, while real-world exploitation status is not established because known_exploited is null. No confirmed public exploit details or specific indicators were identified in the sources reviewed.

The flaw allows unauthenticated remote connections to consume resources during sshd pre-authentication, potentially degrading or interrupting SSH service availability. The record does not indicate data disclosure, data modification, or privilege escalation; the described effect is limited to availability. No impact beyond the service's security authority is confirmed. Operationally, loss of SSH access could hinder administration and recovery, but the exhaustion threshold and possible host-wide scope remain unknown.

• SSH service availability may degrade or fail when resources are consumed by excessive authentication attempts.
• Disruption of sshd can delay or prevent remote administration, incident response, and system recovery.
• Services that depend on SSH access may experience operational impact if resource exhaustion persists.
• The record describes an availability issue and provides no evidence that the flaw enables data disclosure or data modification.
• The resource level required to cause disruption and the impact beyond the SSH service are not publicly established.

1. Upgrade OpenBSD OpenSSH to 10.4, the confirmed fixed release. Validate the operating system or distributor package metadata because the record does not enumerate separate backports.
2. Prioritise sshd instances with GSSAPIAuthentication enabled. If an upgrade cannot be performed immediately, disabling GSSAPIAuthentication may reduce exposure when operationally acceptable, but the available sources do not establish this as a complete fix.
3. Review PerSourcePenalties against vendor-supported configuration guidance. The release notes state that the relevant activity would be penalised by this control, but do not present it as a replacement for patching.
4. After updating, verify the running sshd binary, effective configuration, and service restart or reload state. Recheck remote authentication to confirm that the patched implementation is active.

1. Inventory systems running OpenBSD OpenSSH and compare both package versions and the running sshd binary with the affected boundary.
2. Inspect the effective sshd configuration to identify servers with GSSAPIAuthentication enabled and record the configured MaxAuthTries value.
3. Review pre-login authentication telemetry for bursts of repeated failed or prolonged authentication attempts. This is precautionary monitoring, not a vendor-confirmed IOC.
4. Correlate unusual authentication activity with increased CPU or memory use and degradation in the ability to establish SSH sessions. Public sources do not define a resource threshold or specific log pattern.
5. Do not treat the absence of a matching log event as proof of safety; combine configuration and version checks with service-health review.