OpenSSH 10.5 landed on August 11, and while the changelog reads like a normal point release, the release notes carry an announcement that matters more than any individual fix: the project intends to publish security releases more frequently than its usual schedule, because AI-assisted vulnerability research is producing reports faster than the old cadence can handle.

The agent locking bug

The headline fix concerns ssh-agent locking and the session-bind@openssh.com extension, which agents use to identify forwarded sessions.

Previously, binding requests were rejected while the agent was locked. That sounds safe, but the effect was the opposite: operations that were supposed to stay local could instead be performed remotely through a forwarded agent. The developers list adding PKCS#11 tokens and using keys carrying destination restrictions among the operations affected.

If you forward your agent to remote hosts, this is the fix to care about. Agent forwarding hands the remote end the ability to ask your local agent to sign things, and destination restrictions are the mechanism that is supposed to keep that ability scoped. A bug that weakens those restrictions undercuts the main defense.

# Check whether your agent is forwarding at all
echo "$SSH_AUTH_SOCK"

# Prefer destination-restricted keys over blanket forwarding
ssh-add -h host.example.com ~/.ssh/id_ed25519

Our SSH hardening guide covers why blanket ForwardAgent yes is worth avoiding in the first place, and the SSH config builder can generate per-host blocks that scope forwarding instead of enabling it globally.

Server side and client side

On the server, OpenSSH 10.5 corrects the restrict keyword in authorized_keys so that it also applies to tunnel forwarding. Tunnel forwarding remains administratively disabled by default, so this is a correctness fix rather than an open door being closed.

The client picks up a fix for a potential realloc use-after-free condition.

A genuinely useful new flag

The release adds ssh -Z, which prints the public keys SSH would try for public-key authentication, in the exact order it would try them.

ssh -Z user@host

If you have ever watched a login fail because the server hit MaxAuthTries before reaching the right key, this is the flag you wanted. It turns “which key is it even offering?” from a -vvv archaeology exercise into a single command.

FIDO improvements

ssh-keygen can now set or clear the touch-required and verify-required flags on FIDO private keys while resetting the key’s passphrase.

The client also reorders which certificates it attempts during public-key authentication. FIDO keys that do not require user presence go first, and keys that need a PIN or biometric verification are tried later. The practical result is fewer spurious prompts to tap a security key during an authentication attempt that was going to use a different credential anyway.

Smaller fixes

ssh-keyscan now reads server banners non-blocking, so a single unresponsive host no longer stalls a scan across many hosts. Errors from sshd’s packet-handling code now include peer address, port, and user, which makes log triage considerably less guessy.

The release also fixes ChannelTimeout and RekeyLimit not being applied correctly inside Match blocks in sshd_config, and restores PAMServiceName inside Match blocks after it was unintentionally disabled during the OpenSSH 10.4 refactoring.

The part worth reading twice

The developers say they have recently received a large volume of security reports either found directly by AI models or produced with AI assistance. Many of them turn out to have no meaningful security implication once a realistic threat model is applied, and the project is clear that it welcomes AI-assisted findings when they arrive with human analysis, test cases, and a proposed fix.

The concerning observation is the other one. The team has seen cases where a vulnerability first surfaced by AI tooling was later found independently by other researchers. The reasoning follows directly: if benign researchers using these tools keep converging on the same bugs, attackers running similar tooling can find them too, and they will not be filing reports.

So OpenSSH plans to ship releases more often, at least for now, so fixes reach users sooner rather than waiting for the normal schedule.

That is a defensive posture change, not a panic. But it does mean the practical advice for administrators shifts slightly: treat OpenSSH like a package that updates on its own schedule rather than yours, and make sure your patch process can absorb an off-cycle release without a planning meeting.

Upgrading

OpenSSH 10.5 is available from the project’s mirrors, with source packages for both OpenSSH and Portable OpenSSH. Most distributions will pick it up through normal channels.

# Confirm what you are running
ssh -V