Extension Negotiation in the Secure Shell (SSH) Protocol
Extracted elements (26)
Prior practice of disabling SSH flow control by sending an initial window size of 2^32-1 is problematic: it can cause channel hang if more than 2^32 bytes are transferred (the other party may implement flow control per RFC 4254), and some implementations cannot handle large window sizes and may disconnect. The 'no-flow-control' extension provides a safe, negotiated alternative.
The ext-info indicator names are placed in kex_algorithms because it is one of two name-list fields in SSH_MSG_KEXINIT without separate per-direction copies. The client and server use different indicator names ('ext-info-c' vs 'ext-info-s') to ensure they never produce a matching key exchange algorithm, thus not affecting algorithm negotiation.
The original SSH transport layer (RFC 4253) lacks proper extension negotiation, and diverse implementations discard unrecognized information, making it risky to signal capabilities without risking disconnection. This mechanism was motivated by the need for clients to discover which public key algorithms a server accepts (e.g., for RSA-SHA-256/512 per RFC 8332) without trial-and-error and associated authentication penalties.
The server is permitted to send a second SSH_MSG_EXT_INFO immediately before SSH_MSG_USERAUTH_SUCCESS to reveal extensions it was unwilling to expose to unauthenticated clients. The second message completely replaces the first, causing both parties to re-evaluate extensions in effect.
Without the 'elevation' extension, Windows SSH servers must always elevate administrative sessions to ensure full access. The extension allows clients to explicitly request or decline elevation, reducing attack surface by avoiding unnecessary elevation for sessions that don't require it.
OpenSSH clients up to version 7.5 advertise support for SSH_MSG_EXT_INFO but disconnect upon receiving an extension-value containing null bytes. The 'delay-compression' extension uses a binary encoding with potential null bytes. Implementations interoperating with OpenSSH ≤7.5 should detect the version string and omit 'delay-compression'; the extension SHOULD NOT be omitted for OpenSSH ≥7.6.
A client that sent 'ext-info-c' MUST accept a server's SSH_MSG_EXT_INFO at both opportunities (after SSH_MSG_NEWKEYS and immediately preceding SSH_MSG_USERAUTH_SUCCESS) but MUST NOT require it at either.
A party that has signaled support for 'delay-compression' MUST NOT initiate key re-exchange until it has sent its compression trigger message (if using delay-compression) or until SSH_MSG_USERAUTH_SUCCESS has been sent/received (if delay-compression was not negotiated).
Applications implementing this mechanism MUST add either 'ext-info-s' (server) or 'ext-info-c' (client) to the kex_algorithms field in the SSH_MSG_KEXINIT message sent during the first key exchange.
Applications MUST ignore unrecognized extension-names. Applications that do not implement or recognize an extension MUST ignore its extension-value regardless of size or content. Applications MUST tolerate any sequence of bytes — including null bytes at any position — in an unknown extension's extension-value.
If a client or server offers 'ext-info-c' or 'ext-info-s' respectively, it MUST be prepared to accept an SSH_MSG_EXT_INFO message from the peer.
If a client sends SSH_MSG_EXT_INFO, it MUST send it as the next packet immediately following the client's first SSH_MSG_NEWKEYS message to the server.
If 'delay-compression' takes effect and the renegotiated algorithm is the same as the already-enabled algorithm in one or both directions, the internal compression state MUST be reset for each such direction at the time the renegotiated algorithm takes effect.
Implementations MUST accept well-formed SSH_MSG_EXT_INFO messages up to the maximum packet length they accept, as the cumulative size of the message is bounded only by the implementation's maximum packet length per RFC 4253.
Implementations MUST NOT send an incorrect indicator name for their role (i.e., a server must not send 'ext-info-c' and vice versa). Implementations MAY disconnect if the counterparty sends an incorrect indicator. If 'ext-info-c' or 'ext-info-s' is actually negotiated as a key exchange method, the parties MUST disconnect.
Servers that implement public key authentication SHOULD implement the 'server-sig-algs' extension. If a server does not send this extension, a client MUST NOT make any assumptions about the server's public key algorithm support.
When 'no-flow-control' is in effect, implementations MUST refuse to open more than one simultaneous channel. Nevertheless, server implementations SHOULD support clients opening more than one non-simultaneous channel.
The 'delay-compression' extension, sent by either party, carries two name-lists encoded as strings within the extension-value string: compression_algorithms_client_to_server and compression_algorithms_server_to_client. It takes effect only if both parties send it and share a common algorithm, activating immediately after SSH_MSG_USERAUTH_SUCCESS (server side) or SSH_MSG_NEWCOMPRESS (client side).
The 'elevation' extension is sent by the client with a value of 'y' (request elevation), 'n' (no elevation), or 'd' (server default). After authentication, a supporting server SHOULD send a SSH_MSG_GLOBAL_REQUEST with the request name 'elevation' and a boolean indicating whether elevation was performed.
The 'no-flow-control' extension, sent by either party with a value of 'p' (preferred) or 's' (supported), disables SSH channel flow control when both parties send it and at least one sends 'p'. When in effect, initial window size fields become meaningless, SSH_MSG_CHANNEL_WINDOW_ADJUST messages MUST be ignored, and channels behave as if all window sizes are infinite.
The 'server-sig-algs' extension is sent by the server as a name-list of public key algorithms accepted for 'publickey' user authentication. The server MUST enumerate all algorithms it might accept; a client receiving this extension can avoid trial-and-error algorithm selection and associated authentication penalties.
RFC 8308 adds two new message numbers to the 'Message Numbers' registry under SSH Protocol Parameters: 7 (SSH_MSG_EXT_INFO) and 8 (SSH_MSG_NEWCOMPRESS). It also adds 'ext-info-s' and 'ext-info-c' to the 'Key Exchange Method Names' registry.
RFC 8308 creates a new 'Extension Names' registry under SSH Protocol Parameters with initial entries: server-sig-algs, delay-compression, no-flow-control, and elevation. Future non-local names (without '@') require IETF Review policy per RFC 8126; names must follow RFC 4250 Section 4.6.1 conventions.
The extension negotiation mechanism transmits extension information confidentially after key exchange, which protects capability disclosure from passive observers. However, security considerations of the base SSH protocol (RFC 4251) and related documents continue to apply. Authentication penalties — including IP throttling, blocking, and alerting — may be triggered if clients use unexpected public key algorithms, motivating correct use of 'server-sig-algs'.
SSH_MSG_EXT_INFO (message number 7) carries a uint32 nr-extensions count, followed by that many pairs of string extension-name and string extension-value (binary). The extension-value field may contain null bytes at any position.
SSH_MSG_NEWCOMPRESS (message number 8) is a single-byte message (value 8) sent by the client after receiving SSH_MSG_USERAUTH_SUCCESS when 'delay-compression' is in effect, signaling the start of the renegotiated compression algorithm.