OpenSSH 10.3 It is now available It introduces a combination of security patches, behavior modifications, and new capabilities that impact both system administrators and developers. While many of the new features are technical, several may cause connection failures with older clients or servers if configurations are not carefully reviewed.
For corporate environments, where OpenSSH is a core component on Linux servers, BSD systems, and network devices, this update is especially relevant. Version 10.3 fixes vulnerabilities, adjusts certificate validation, and changes how certain configuration options are handled, so it's advisable to test it in pre-production environments before mass deployment.
Broken compatibility with non-rekeying implementations
One of the most significant changes in OpenSSH 10.3 is the removal of the code for "Bug compatibility" with implementations that do not support rekeyingUntil now, the project maintained a series of internal adjustments that allowed it to continue communicating with older or non-standard SSH clients or servers that lacked this ability to renegotiate keys during the session.
From this version onwards, if a SSH client or server does not support rekeyingThe connection with OpenSSH 10.3 will simply fail when attempting to establish a connection or during the session. This can affect infrastructures that still use legacy software, embedded devices, or proprietary solutions that implement the SSH protocol incompletely.
Systems managers in organizations should Inventory SSH devices and services To check if all components support rekeying before upgrading. In deployments where older hardware or custom software is maintained, it may be necessary to upgrade those components or isolate them in segments where OpenSSH 10.3 is not used.
Fix for command injection bug via username
On the client SSH fixes a validation vulnerability This allowed, under certain conditions, special shell characters present in the username to be expanded before the security check. The problem arises when using third-party controlled usernames and advanced configurations with substitution tokens.
Specifically, the vulnerability affected configurations that include the token %u within Match exec blocks in the ssh_config file. In that scenario, an attacker with the ability to influence the username passed to the ssh command could execute arbitrary commands in the shell, taking advantage of metacharacter expansion.
The new version adjusts the validation order of these parameters to prevent dangerous expansion of malicious usernames. Even so, developers remind us that exposing SSH command-line arguments to untrusted input is still a bad design practice, especially in scripts or automated tools used in large environments.
Changes in the handling of certificates and main
OpenSSH 10.3 introduces several significant adjustments to the SSH certificate management and its "mains" (identities to which the certificate is associated), with a direct impact on how access is validated.
Bug in matching main characters with commas
An error has been corrected in sshd when comparing the main option="" The issue arose from the entries in authorized_keys with the list of principals included in a certificate. The failure occurred when one of the principal names in the certificate contained a comma, which could lead to improper matches in very specific scenarios.
For the problem to be exploitable, several conditions had to be met: that the input of authorized_keys includes more than one mainThe bug caused the certificate authority to issue a certificate with several of these names separated by commas, and to use user-trusted CA keys. The main certificate authentication flow based on TrustedUserCAKeys and AuthorizedPrincipalsFile was not affected.
Certificates with empty principal list
Another change in behavior corrects a problematic historical design in certificatesUntil now, when a certificate with an empty principals section was used together with authorized_keys principals="", it was treated de facto as a wildcard, allowing authentication as any user who trusted the same certificate authority.
This posed a non-obvious risk: a CA that mistakenly issued a certificate with empty main list It was inadvertently granting extremely broad access. In OpenSSH 10.3, this situation changes, and a certificate without principals is now considered as not matching any principal, preventing this dangerous "wildcard" behavior.
Furthermore, the project has unified the treatment of wildcards in main certificatesThe use of wildcards is permitted in host certificates, but not in user certificates. This aims for more predictable and auditable behavior, something especially valued in security audits of European organizations subject to frameworks such as NIS2 or ENS.
Strict application of ECDSA algorithms
In the cryptographic section, OpenSSH 10.3 corrects a problem in the application of the PubkeyAcceptedAlgorithms and HostbasedAcceptedAlgorithms directives for ECDSA keys. Until this version, if the name of an ECDSA algorithm appeared in any of these lists, the server would de facto accept other ECDSA algorithms even if they were not explicitly listed.
With the new revision, sshd accurately respects the list of allowed algorithmsThis closes that gap and offers finer control over which ECDSA variants can be used. This is useful for administrators looking to limit the set of algorithms to more robust profiles or align with national security recommendations.
Correction in scp when downloading as root
The tool scp also receives a security adjustment When used in legacy mode (rcp compatibility) and run as root. In previous versions, when downloading files without using the -p option, the program did not remove the setuid and setgid bits from the received files.
This behavior, inherited from Berkeley's original CPRThis could be dangerous in certain copy workflows, as a file transferred with special permissions could be executed with elevated privileges on the destination system. OpenSSH 10.3 corrects this behavior to strengthen security in remote administration, a common practice on production servers in data centers.
Enhanced ProxyJump validation and multiplexing control
Regarding advanced connection options, the client introduces improvements in ProxyJump (-J or -oProxyJump parameter)Now, user and host values ​​passed via command line are more strictly validated to prevent potential command injection vectors in configurations where these fields may be influenced by untrusted input.
It is important to note that this Validation only applies to what is received via the command line and it does not affect the values ​​defined within the configuration files. Even so, it provides an additional layer of protection for scripts, automations, and tools that use ProxyJump dynamically.
In the field of connection multiplexing, a problem has been solved with the session confirmation when using ControlMaster ask/autoask in proxy mode using "ssh -O proxy". Previously, confirmation requests were not evaluated correctly in this type of multiplexed session.
In addition, new commands are added to obtain detailed information about active sessionsThe command "ssh -O conninfo" and the escape sequence "~I" display connection information for ongoing sessions, while "ssh -O channels" reports which channels the multiplexer process is keeping open. These features can facilitate troubleshooting in complex deployments, which are very common in large organizations and service providers in the EU.
What's new in ssh-agent, ssh-add and key management
OpenSSH 10.3 takes another step in the alignment with the IETF draft draft-ietf-sshm-ssh-agent Regarding the SSH agent, compatibility has been added with the new codepoints assigned by IANA for agent forwarding, so that when the server advertises support for those names using the EXT_INFO message, OpenSSH prioritizes the use of the standardized identifiers.
However, support for the Historical extensions with the @openssh.com suffixensuring interoperability with existing infrastructures. The ssh-agent component also incorporates support for the "query" extension defined in the same draft, allowing for more structured querying of agent capabilities.
For its part, the utility ssh-add adds the -Q option to query the protocol extensions that the agent supports. This functionality is especially useful for security and operations teams that need to check what features are available on agents deployed across different systems.
In the area of ​​keys, ssh-keygen now includes the ability to write ED25519 keys in PKCS8 formatThis facilitates its integration with other cryptographic tools and libraries used in business and public administration environments.
Origin penalties and diagnostic improvements in SSHD
The SSH server incorporates improvements aimed at mitigating abuse and facilitating observability. One of these is the introduction of the invaliduser penalty within PerSourcePenaltieswhich is applied when login attempts are received with usernames that do not exist in the system.
By default, this new penalty consists of a wait five secondsThis aligns with the existing penalty for authfail, but administrators can configure longer durations if they detect brute-force attacks or mass user sweeps. Furthermore, the time resolution of penalties is now floating-point, allowing for penalties of less than one second in high-frequency event scenarios.
In parallel, the new multiplexing capabilities described above ("ssh -O conninfo", "ssh -O channels" and the escape "~I") provide greater visibility into active connectionsThis can be very helpful when diagnosing latency problems, blocking, or abnormal use of SSH tunnels and channels.
More changes in security and compatibility
OpenSSH 10.3 adds in sshd the server option GSSAPIDelegateCredentialsThis setting controls whether the server accepts delegated credentials offered by the client. This option mirrors the existing client-side policy and allows the behavior to be adapted to each organization's internal policies regarding Kerberos and similar credential delegation.
The scope of the RevokedHostKeys directives in ssh_config and RevokedKeys in sshd_configwhich can now point to multiple files. This makes it easier to manage revoked key lists separated by projects, departments, or trust levels—useful in large infrastructures with multiple teams and vendors.
The version also corrects a number of practical problems: a bug in the PIN entry for PKCS#11 keys introduced in versions 10.1 and 10.2, FIDO/WebAuthn certificate signature handling is improved, an sshd crash related to missing subsystem directives within Match blocks is fixed, and a username confusion issue in the PAM module is addressed in the portable branch.
With this release, OpenSSH 10.3 consolidates a comprehensive package of changes that enhances safetyIt adjusts legacy behaviors and expands management capabilities without losing compatibility with most modern deployments. Organizations that rely on SSH for remote administration, automation, and secure tunneling would do well to plan the upgrade, first reviewing their test environments for potential issues with legacy implementations, unusual options, or highly customized configurations.
