CVSS 3.7 CVE-2021-36368
CVSS 3.7 CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:N
An issue was discovered in OpenSSH before 8.9. If a client is using public-key authentication with agent forwarding but without -oLogLevel=verbose, and an attacker has silently modified the server to support the None authentication option, then the user cannot determine whether FIDO authentication is going to confirm that the user wishes to connect to that server, or that the user wishes to allow that server to connect to a different server on the user’s behalf. NOTE: the vendor’s position is “this is not an authentication bypass, since nothing is being bypassed.”
FIDO2 Keys and SSH Agent Forwarding
FIDO2/sk keys (ssh-ed25519-sk, ecdsa-sk) are SSH keypairs where the private
key is stored on a hardware security token (e.g., YubiKey). Each use of the key requires
physical interaction with the token — a touch or PIN entry. This “user presence” check
is the second factor that protects against stolen private key files.
SSH agent forwarding (ssh -A) forwards the local SSH agent socket to the remote
server. When a user is logged in to a jump host with -A, processes on that jump host
can request cryptographic signatures from the user’s local agent — including FIDO2 key
operations that trigger the hardware token confirmation on the user’s machine.
The Vulnerability: Ambiguous FIDO Confirmation
When a user connects to a server via SSH-MITM with agent forwarding enabled, the following sequence can occur:
Step 1 — MITM accepts connection via trivial auth
The MITM server authenticates the user using a trivial authentication method — either
none (no interaction at all) or keyboard-interactive with zero prompts sent.
The OpenSSH client accepts this and establishes a session without any FIDO confirmation.
The user’s FIDO token has not been touched yet.
Step 2 — MITM forwards agent to the real server
The MITM server now uses the forwarded agent to authenticate to the real target server using the user’s FIDO2 key. This requires a signature from the hardware token.
Step 3 — FIDO confirmation appears on user’s terminal
A prompt appears on the user’s machine asking them to confirm use of their key:
Confirm user presence for key ED25519-SK SHA256:...
From the user’s perspective:
They connected to one server (the MITM)
One key confirmation is expected — for that one connection
The confirmation that appears is, in fact, for the MITM’s connection to the real server
The user has no reliable way to determine which server is prompting. The usual expectation is: one connection → one confirmation. That expectation is met — but the confirmation authorizes something the user did not intend.
Step 4 — Attacker has authenticated to the real server
Once the user confirms, the MITM has a fully authenticated session to the real server using the user’s FIDO2-protected key — without the user ever knowing.
Why OpenSSH Calls This “Not a Bypass”
OpenSSH’s official position is that the FIDO2 key was legitimately used: the user
confirmed its use. The none/trivial auth on the MITM server is not forging any
credential — the MITM server simply does not require a credential to connect.
The actual security issue is the ambiguity of what the confirmation authorizes: the user cannot determine from the confirmation prompt alone which server will receive their authenticated session. OpenSSH addressed this in 8.9 by adding agent restriction keys that bind an agent’s use to a specific destination.
For the general attack description and PoC, see Trivial Authentication.