The Secure Shell (SSH) Protocol Architecture
updated by
Extracted elements (29)
Algorithm and method names use DNS-based local namespaces (name@domainname) to allow organizations to define experimental or classified extensions without central registration conflicts. This balances the need for extensibility against the risk of method-identifier collisions that would hinder interoperability.
The protocol deliberately allows host key verification to be skipped on first connection to improve usability during the transition period before widespread public key infrastructure exists on the Internet. The working group judged that deployment friction is itself a security problem, even though this option weakens the protocol when used.
All algorithm and method identifiers MUST be printable US-ASCII, non-empty strings no longer than 64 characters. Names MUST be case-sensitive. IANA-registered names (no '@') MUST NOT contain '@', ',', whitespace, control characters (ASCII ≤32), or DEL (127).
All implementations MUST support a minimal set of algorithms to ensure interoperability, even though local policy may not permit all such algorithms. The mandatory algorithms are specified in the relevant protocol documents.
Each server host SHOULD have a host key, and if it has keys it MUST have at least one key using each REQUIRED public key algorithm (DSS). Hosts MAY have multiple keys using different algorithms, and multiple hosts MAY share the same host key.
Implementations SHOULD NOT normally allow connections without host key verification by default, as they are vulnerable to active man-in-the-middle attacks. Implementations SHOULD try to make the best effort to check host keys, and SHOULD provide an option to reject unverifiable host keys.
The implementer MUST ensure that credentials validate the professed user identity AND that the server's local security policy permits the requested access. Where local security policy exists, it MUST be applied and enforced correctly, even though the type of service may not be known at authentication time.
The policy MUST specify which is the preferred algorithm (e.g., first listed) for encryption, integrity, and compression per direction. The server policy MUST NOT allow connections to the authentication agent unless forwarding has been explicitly requested.
Where character set data may be displayed, it MUST be explicitly specified. ISO-10646 UTF-8 encoding is used in most places; internal algorithm and protocol names MUST be in US-ASCII. Client and server user names MUST be encoded using ISO 10646 UTF-8.
Local extension algorithm names use the format 'name@domainname' (e.g., '[email protected]'). The domain part MUST be a valid, fully qualified domain name controlled by the defining organization. Only a single '@' is allowed, and the total name MUST NOT exceed 64 characters.
SSH consists of three major components layered in order: the Transport Layer Protocol (server authentication, confidentiality, integrity, optional compression), the User Authentication Protocol (client-to-server authentication), and the Connection Protocol (multiplexes the encrypted tunnel into logical channels). Each layer runs over the one below it.
SSH message numbers occupy bytes 1–255 and are partitioned by layer: 1–19 transport generic, 20–29 algorithm negotiation, 30–49 key exchange method specific, 50–59 user authentication generic, 60–79 user authentication method specific, 80–89 connection generic, 90–127 channel related, 128–191 reserved, 192–255 local extensions.
Two trust models are defined for host key verification: (1) a client-local database associating host names to public keys, requiring no infrastructure; and (2) certification by a trusted CA where the client only stores the CA root key. The protocol also permits skipping verification on first connect.
IANA maintains registries for SSH service names, authentication methods, connection protocol channel/request names, key exchange method names, and assigned algorithm names (encryption, MAC, public key, compression). All IANA-registered names require IETF CONSENSUS. Message numbers 0–191 are allocated by IETF CONSENSUS; 192–255 are PRIVATE USE.
Because MACs use a 32-bit sequence number, peers MUST rekey before sequence number wrap (after at most 2^28 packets given the 16-byte minimum packet size and 1 GB rekeying recommendation) to prevent replay attacks. A replayed packet will fail MAC validation if peers have rekeyed since the original transmission.
CBC mode encryption is theoretically vulnerable to chosen-ciphertext attacks due to high predictability of packet start sequences (Rogaway/Dai/Bellare attack). Inserting an SSH_MSG_IGNORE packet before data transmission whenever the previous packet has already been sent to the network mitigates this attack by preventing the attacker from knowing the next IV.
Client software SHOULD replace any control characters (except tab, carriage return, and newline) with safe sequences before displaying text such as error or debug messages, to prevent terminal control character injection attacks.
DH key exchange in SSH provides perfect forward secrecy (PFS): compromise of long-term private keys after a session does not compromise earlier session keys, provided the ephemeral DH parameters are erased from memory and not written to swap after key exchange completes.
If the transport layer does not provide confidentiality, authentication methods that rely on secret data SHOULD be disabled. If strong integrity protection is absent, password-change requests SHOULD be disabled to prevent undetected modification or denial of service.
SSH is vulnerable to connection-setup DoS: an attacker can force the server through CPU- and memory-intensive key exchange without authenticating. Implementers SHOULD provide mitigations such as restricting connections to clients known to have valid users.
The PRNG used to generate session-specific data (e.g., DH parameters) MUST be cryptographically secure. If insufficient entropy is available, refusing to run the protocol is preferable to using a weak PRNG. SSH binds each session key to the session via random, session-specific data in the hash.
Traffic analysis of SSH sessions can reveal information such as password length. Implementers should use SSH_MSG_IGNORE packets combined with random-length padding to thwart traffic analysis attacks.
Using SSH without verifying the server host key–hostname binding is inherently insecure and NOT RECOMMENDED because it is vulnerable to man-in-the-middle attacks. Three attack scenarios are described: pre-session device interposition, social-engineering key distribution, and in-session packet manipulation.
X11 forwarding combined with displays that accept connections only over local IPC mechanisms with ACLs corrects many X11 security problems, provided the 'none' MAC is not in use. It is RECOMMENDED that both X11 display implementations and SSH server implementations default to allowing display connections only over local IPC.
boolean is stored as a single byte: 0 represents FALSE, 1 represents TRUE. All non-zero values MUST be interpreted as TRUE; however, applications MUST NOT store values other than 0 and 1.
mpint encodes multiple-precision integers in two's complement, stored as a string with 8 bits per byte, MSB first. If the most significant bit would be set for a positive number, a zero byte MUST precede it. Unnecessary leading 0x00 or 0xFF bytes MUST NOT be included. The value zero MUST be stored as a zero-length string.
name-list is a uint32 length followed by a comma-separated list of US-ASCII names. Each name MUST have non-zero length and MUST NOT contain a comma. Terminating null characters MUST NOT be used for individual names or the list as a whole.
string is an arbitrary-length binary string stored as a uint32 length followed by that many bytes of value. No null terminator is used. US-ASCII is used for internal names; ISO-10646 UTF-8 is used for user-visible text. The terminating null character SHOULD NOT normally be stored.
uint32 is a 32-bit unsigned integer stored as four bytes in network byte order (decreasing significance). uint64 is a 64-bit unsigned integer stored as eight bytes in network byte order.