RFC 9987 Published: The Significance and Impact of SSH Agent Protocol Standardization

SSH Agent Protocol Finally Has a Formal Standard

For years, SSH Agent has been an indispensable tool in the daily workflow of developers and system administrators—it allows us to securely authenticate using private keys without repeatedly entering passphrases. However, this widely-used protocol has long lacked a formal official specification document. With the publication of RFC 9987: Secure Shell (SSH) Agent Protocol, this situation has finally changed.

The SSH Agent protocol previously existed primarily as the PROTOCOL.agent document within the OpenSSH project, serving as a de facto standard rather than a formal specification certified through the IETF standardization process. A de facto standard is one that forms naturally through market dominance and widespread adoption, but without formal certification by a standards organization. Since OpenSSH holds a dominant position in SSH implementations (estimated at over 80% of global SSH servers), its internal documentation effectively defined Agent protocol behavior. However, de facto standards carry inherent risks: they may be unilaterally changed at the discretion of project maintainers, other implementers may encounter ambiguities in interpretation, and they lack authoritative citation basis in regulatory compliance scenarios.

The emergence of RFC 9987 means that this protocol, relied upon by millions of systems, has formally entered the Internet standards document system. The IETF (Internet Engineering Task Force) is the international organization responsible for developing Internet technical standards, and RFCs (Request for Comments) are its series of numbered documents covering technical specifications for Internet protocols, procedures, and concepts. The journey from proposal to formal RFC typically involves drafts (Internet-Drafts), working group discussions, multiple rounds of public review, and IESG approval—ensuring technical rigor and broad industry consensus. Specifically, the standardization work for RFC 9987 was led by OpenSSH core maintainer Damien Miller, discussed through the IETF curdle working group, and went through multiple revisions over several years before final approval. This model of implementer-driven standardization ensures high consistency between the RFC document and actual running code, avoiding the common problem of "paper standards" being disconnected from reality.

What Is the SSH Agent Protocol

Core Function

SSH Agent is a daemon process running in the background that holds the user's decrypted private keys. When a user needs to log into a remote server via SSH, the SSH client communicates with the local Agent, which uses the private key to perform the signing operation—while the private key itself never leaves the Agent process.

The concept of SSH Agent can be traced back to the SSH-1 protocol era—in 1995, Tatu Ylönen at Helsinki University of Technology in Finland developed the original SSH protocol and implementation. When the OpenSSH project forked from the last freely-licensed version of SSH 1.2.12 in 1999, ssh-agent became a core component of the OpenSSH toolkit and rose to de facto standard status as OpenSSH gained widespread adoption. Today, Apple has integrated ssh-agent into the system Keychain since macOS Leopard (10.5), Microsoft has included a built-in OpenSSH Agent service since Windows 10 version 1803, and Linux distributions include it by default. This deep cross-platform integration makes standardization of the Agent protocol particularly urgent—different platform implementations need an authoritative reference to ensure consistent behavior.

This design brings several key advantages:

• No repeated password entry: Once a private key is decrypted, it can be used multiple times during the session
• Private key isolation: Private keys are never exposed to the applications requiring authentication
• Agent Forwarding: Allows using local private keys on jump hosts, enabling multi-hop login

It's worth noting that Agent Forwarding, while convenient, is one of the most commonly overlooked security risks in SSH usage. When Agent Forwarding is enabled, a socket proxy pointing to the local Agent is created on the remote server, meaning the root user on that remote server (or anyone who can access the socket) can use your Agent for authentication—they cannot extract the private key, but they can initiate connections to other servers under your identity for the duration of your session. Therefore, security best practices recommend using ProxyJump (-J option) instead of Agent Forwarding, or using ssh-agent's confirmation mode (AddKeysToAgent confirm), which requires manual user confirmation for each signing request.

How the Protocol Works

The SSH Agent protocol essentially defines the communication method between client applications and the Agent. Clients can request the list of held public keys, request signing of specific data, add or remove keys, and more. All communication occurs over a local socket (Unix domain socket), typically referenced by the SSH_AUTH_SOCK environment variable.

A Unix domain socket is an inter-process communication (IPC) mechanism that, unlike network sockets, doesn't pass through the network protocol stack but completes data transfer directly within the kernel, providing lower latency and higher security. The SSH Agent's socket path typically looks like /tmp/ssh-XXXXX/agent.PID, with file system permissions set to owner-only read/write (0600), providing the first layer of access control. In containerized and multi-tenant environments, socket file permission management becomes an important security consideration—incorrect permission configuration could allow other users on the same host to hijack your Agent.

The SSH Agent's security model is based on operating system-level process isolation and file system permissions. The Agent process stores decrypted private keys in its process memory, and modern implementations (such as OpenSSH 7.0+) use the mlock() system call to prevent key memory pages from being swapped to disk, and apply XOR-based "shielding" to key data in memory when keys are not actively in use, increasing the difficulty of memory forensics. However, the Agent's security boundary stops at local root privileges—an attacker with root privileges can theoretically attach to the Agent process via the ptrace system call, or directly read /proc/[pid]/mem to extract plaintext keys from memory. This fundamental limitation is a key driver behind the adoption of hardware security keys (such as FIDO2 devices).

Protocol messages use a simple TLV (Type-Length-Value) encoding format: each message begins with a 4-byte length field, followed by a 1-byte message type identifier, and finally the message body. Key message types include SSH_AGENTC_REQUEST_IDENTITIES (request key list), SSH_AGENTC_SIGN_REQUEST (request signature), SSH_AGENTC_ADD_IDENTITY (add key), and others. This simple design makes the protocol easy to implement and debug, while also enabling third-party tools (such as password managers, hardware key drivers) to relatively easily implement the Agent protocol interface.

The Significance of RFC 9987 Standardization

From De Facto Standard to Formal Specification

Formally standardizing a protocol that's already been widely adopted may seem like merely documentation work, but its value should not be underestimated. RFC 9987 provides different SSH implementations (such as OpenSSH, PuTTY, Tectia, Dropbear, libssh, etc.) with a unified, authoritative reference, helping reduce compatibility issues between implementations.

For security-sensitive infrastructure, a formally peer-reviewed specification means clearer behavior definitions, less room for ambiguity, and stronger auditability. Enterprises and government agencies conducting compliance assessments can reference a formal RFC number rather than an open-source project's internal documentation. In U.S. federal government FedRAMP certification, financial industry PCI-DSS compliance assessments, and enterprise-level SOC 2 audits, the ability to reference formal international standards directly impacts the credibility of compliance documentation and audit efficiency.

Promoting SSH Ecosystem Interoperability

With the proliferation of cloud-native and zero-trust architectures, the complexity of SSH key management continues to increase. The core principle of Zero Trust security architecture is "never trust, always verify," which fundamentally challenges traditional SSH key management models. In the traditional model, an SSH private key might be long-lived and broadly authorized; under zero-trust frameworks, more organizations are adopting short-lived certificates in place of long-term keys—issuing SSH certificates valid for only hours, signed by internal CAs, combined with identity providers (IdP) for real-time identity verification. Tools like HashiCorp Vault, Teleport, and Smallstep all implement this model, and standardization of the SSH Agent protocol facilitates reliable integration of these tools with different SSH clients in certificate lifecycle management.

Hardware security modules (HSMs), smart cards, FIDO2/U2F security keys, and other new authentication methods all need to integrate with the SSH ecosystem through the Agent protocol. FIDO2 is a passwordless authentication standard jointly developed by the FIDO Alliance and W3C. Since OpenSSH 8.2, SSH natively supports FIDO2 security keys (such as YubiKey, Google Titan Key) as SSH key types (sk-ecdsa-sha2-nistp256@openssh.com and sk-ssh-ed25519@openssh.com). For these key types, the private key material never leaves the hardware device, signing operations must be completed on the device, and typically require the user to physically touch the device for confirmation. This approach elevates SSH authentication security to a level where private keys cannot be stolen even if the host is completely compromised.

Meanwhile, SSH key algorithms themselves continue to evolve. From the earliest RSA and DSA, to NIST elliptic curve-based ECDSA (P-256/P-384/P-521), to the currently widely recommended Ed25519 (based on Daniel Bernstein's Curve25519). Ed25519 has become the most recommended SSH key type today due to its fixed 256-bit key length, excellent signing/verification performance (dozens of times faster than RSA-4096), and independence from potentially backdoored NIST curve parameters. Looking ahead, as quantum computing develops, post-quantum cryptographic algorithms (such as ML-DSA/CRYSTALS-Dilithium being standardized by NIST) may need to be introduced into the SSH ecosystem. The standardization of RFC 9987 provides a framework for defining new key types and signature algorithms in the Agent protocol in the future, enabling orderly protocol evolution through formal standard extension processes.

A standardized protocol specification provides clear implementation guidelines for manufacturers of these new authentication devices, lowering the integration barrier and ensuring that hardware keys from different vendors work consistently across various SSH Agent implementations.

Practical Impact for Developers

Limited Changes in the Short Term

For the vast majority of developers who use SSH daily, the publication of RFC 9987 won't bring immediately noticeable changes. Your existing ssh-agent and ssh-add commands will continue to work as before, and your workflow requires no adjustment. This is precisely the nature of standardization work—it documents and codifies existing practices rather than introducing breaking changes.

Long-Term Value Lies in Stability and Trust

The real value manifests over the long term. Once a protocol has a formal standard:

• New SSH implementations can more easily ensure compatibility with the existing ecosystem
• Security researchers have a clear specification as an analysis baseline
• Future protocol evolution will occur through open standard processes, rather than depending on decisions from a single project

For developers building security tools, key management systems, or identity authentication platforms, RFC 9987 provides an authoritative reference that can be cited with confidence. This is especially important for products that need to pass SOC 2, FedRAMP, and other compliance certifications—auditors prefer to see implementations following a formal international standard rather than internal documentation from an open-source project that could change at any time.

Additionally, for the emerging SSH certificate automation management ecosystem (including Netflix's BLESS, Facebook/Meta's Pam-Ussh, Uber's Pam-Ussh, and other large-scale SSH certificate schemes), a standardized Agent protocol means these systems can more confidently assume consistent Agent behavior across all target clients, simplifying integration logic, reducing edge case handling, and ultimately improving the reliability of the entire SSH infrastructure.

Conclusion

The publication of RFC 9987 is another exemplary case of open-source community practice merging with formal standardization processes. The SSH Agent protocol has silently supported the secure login workflows of developers and operations personnel worldwide for over two decades, and it has finally received the formal identity it deserves. While this release doesn't introduce exciting new features at the technical level, it lays a more solid foundation for the long-term healthy development of the entire SSH ecosystem. For any practitioner concerned with infrastructure security, this is a step worth noting.