On August 11, OpenSSH 10.5/10.5p1 was released — about five weeks earlier than the project’s usual cycle would have anticipated. The reason for the early release this time is more interesting than the fixes themselves, so we’ll start with it.
Why the release was unscheduled
The developers explain it by the stream of vulnerability reports found by AI models or with their help. Most of these reports, according to the project, have no practical value under a realistic threat model. But the team faced something else: some bugs initially found by AI were later independently discovered by ordinary researchers. The takeaway is straightforward — if a tool is available to well-meaning enthusiasts, it is available to those who won’t submit a report. Hence the decision to release more frequently so that fixes reach users faster rather than pile up until the planned window.
A useful detail for those who themselves receive such reports: the project does not reject AI findings in principle. The condition is that the finding is accompanied by human analysis, a reproducible test case, and a proposed patch. Without this, the report is considered noise.
The ssh-agent lock that wouldn’t lock
The third bug was the most unpleasant. In OpenSSH 10.4, agent locking (ssh-add -x) inadvertently disabled the check that distinguishes a local request from a request coming from a remote machine through a forwarded agent. This check is the extension session-bind@openssh.com, precisely the mechanism that in theory prevents a compromised server from reaching your agent.
Consequences: operations intended to be strictly local could be performed remotely. This included adding a PKCS#11 token and using keys restricted by purpose — i.e., keys bound to specific hosts. Found by sn0x-sharma.
Ironically, this happened when the agent was locked: a user who was more careful and blocked the agent during brief departures ended up with worse behavior than someone who didn’t.
restrict, which didn’t restrict tunnels
The key word restrict in authorized_keys — the recommended way to issue a key for “one task” — disables all tunneling pries. It turned out sshd did not apply it to tunnel forwarding (tun). In other words, a key marked as highly restricted still allowed bringing up a tunnel device if the server was configured with PermitTunnel.
The third fix — a potential use-after-free during realloc in the ssh(1) client: reproduced when remote forwarding was added through a local session multiplexing socket at a moment when the request to open remote forwarding was still pending a server response. Found by Brian Mingus from Cognatory.
CVE numbers are not provided in the release notes. The severity has to be inferred from the description: there is no remotely exploitable RCE here, but the first finding hits the scenario for which agent forwarding is generally restricted.
What to change in the build
One breaking change in the portable version: Portable OpenSSH now requires ECC support in libcrypto, including the NISTP521 curve. The project notes that this is available in all supported implementations today — LibreSSL, OpenSSL, BoringSSL, AWS-LC. The problem may only occur for those who build with a reduced or exotic crypto backend.
On a brighter note in this release: ssh-keygen(1) can now set and unset the flags touch-required and verify-required on already created FIDO keys; ssh(1) now tries authenticators in increasing order of “friction” — first those that don’t require physical action; a new mode ssh -Z user@host shows which keys the client actually attempted to present (extremely useful when the agent offers a dozen keys and the server cuts the connection due to the attempt limit); sshd(8) through setproctitle(3) now honestly signs the monitor process after authentication. Also removed from the pre-authentication surface is the parsing of keys.
What a VPS owner should do
ssh -V # client version
sshd -V 2>/dev/null || \
/usr/sbin/sshd -V # daemon version, if the binary isn’t in PATH
In distributions, the patch usually arrives as a backport to an older version rather than a bump to 10.5 — base your actions on the package changelog, not on the number in ssh -V.
Order of actions by usefulness (decreasing):
- Update the openssh-client package on your workstation — the agent vulnerability hits the client, not the server.
- Review who you forward the agent to. ForwardAgent yes in ~/.ssh/config for Host * is a bad idea regardless of version.
- Check authorized_keys on servers with PermitTunnel enabled: keys with restrict behaved differently before the update.
- Update sshd and restart — sessions won’t be torn down on restart.
If you need permanent agent forwarding, look at alternatives: ProxyJump instead of a chain with agent forwarding blocks most scenarios and, in principle, prevents remote machines from accessing the keys.
Sources
- OpenSSH Release Notes — 10.5/10.5p1
- Help Net Security: Locking your ssh-agent exposed local-only keys until OpenSSH 10.5
- Linuxiac: OpenSSH 10.5 Fixes Security Flaws as Project Responds to AI-Assisted Bug Discovery
Question for those who manage a fleet of servers: do you use restrict in authorized_keys at all, or do you limit yourself to a single user and command=? How widespread is agent forwarding in your environment — or have you all already moved to ProxyJump?