[21] In October 2019 protection for private keys at rest in RAM against speculation and memory side-channel attacks were added in OpenSSH 8.1.

This infrastructure is substantial, partly because OpenSSH is required to perform authentication, a capability that has many varying implementations.

OpenSSH versions after 3.7 (16 September 2003) allow PAM to be disabled at run-time, so regular users can run sshd instances.

For example, an X Window System tunnel may be created automatically when using OpenSSH to connect to a remote host, and other protocols, such as HTTP and VNC, may be forwarded easily.

[25] Tunneling a TCP-encapsulating payload (such as PPP) over a TCP-based connection (such as SSH's port forwarding) is known as "TCP-over-TCP", and doing so can induce a dramatic loss in transmission performance due to the TCP meltdown problem,[26][27] which is why virtual private network software may instead use for the tunnel connection a protocol simpler than TCP.

However, this is often not a problem when using OpenSSH's port forwarding, because many use cases do not entail TCP-over-TCP tunneling; the meltdown is avoided because the OpenSSH client processes the local, client-side TCP connection in order to get to the actual payload that is being sent, and then sends that payload directly through the tunnel's own TCP connection to the server side, where the OpenSSH server similarly "unwraps" the payload in order to "wrap" it up again for routing to its final destination.

This is the most flexible of OpenSSH's tunnelling capabilities, allowing applications to transparently access remote network resources without modifications to make use of SOCKS.

[43][44] On March 29, 2024, a serious supply chain attack on XZ Utils has been reported, targeting indirectly the OpenSSH server (sshd) running on Linux.

[citation needed] On July 1, 2024, the RegreSSHion security vulnerability was disclosed, which could enable a remote attacker to cause OpenSSH to execute arbitrary code and gain full root access.

OpenSSH developer Damien Miller replied urging Ylönen to reconsider, arguing that "SSH" had long since been a generic trademark.

Without marking these within the proposal as registered trademarks, Ylönen ran the risk of relinquishing all exclusive rights to the name as a means of describing the protocol.

[50] Both developers of OpenSSH and Ylönen himself were members of the IETF working group developing the new standard; after several meetings this group denied Ylönen's request to rename the protocol, citing concerns that it would set a bad precedent for other trademark claims against the IETF.