Every time you type ssh user@host, a quiet negotiation happens: which key exchange, which cipher, which MAC, which authentication method, which channel type. All of those choices are strings on the wire — diffie-hellman-group14-sha1, hmac-sha2-256, publickey, session. RFC 4250 is the registry that decides what those strings mean, who gets to add new ones, and how vendors avoid stepping on each other. It is one of four core SSH-2 documents ratified together in January 2006 (alongside RFC 4251 architecture, 4252 auth, 4253 transport, 4254 connection), and it is the least glamorous but arguably most durable of the set.

The problem it solves. SSH-1, the 1995 Tatu Ylönen original, baked algorithm identifiers into the protocol as small integers. That was fine when there were three ciphers, but by the late 1990s the SSH-2 working group knew extensibility was the whole game — new ciphers, new KEX methods, new auth schemes would keep arriving forever. So SSH-2 replaced integer opcodes with human-readable ASCII names, and RFC 4250 became the bookkeeping document that governs the namespace.

The key design decision: namespaces with a private escape hatch. Names in SSH come in two flavors:

• IANA-registered names, which are short and unadorned: ssh-rsa, aes128-ctr, curve25519-sha256. Adding one requires an RFC or a formal IANA action.
• Locally-defined names, which must contain an @ followed by a domain the vendor controls: [email protected], [email protected]. No coordination needed — the domain is the namespace.

This is a beautifully pragmatic trick. It means OpenSSH could roll out ChaCha20-Poly1305 in 2013, or certificate-based host keys, or [email protected] global requests, without waiting for IETF process. The @domain suffix guarantees no collision with a future IANA-blessed name. Modern SSH is dominated by @openssh.com-suffixed algorithms — the escape hatch became the main road.

What the registry actually covers. RFC 4250 §4 enumerates the assigned-number spaces:

• Message numbers 1–255 (with 1–19 for transport, 20–29 for KEX generic, 30–49 for KEX-method-specific, 50–79 for user auth, 80–89 for connection generic, 90–127 for channels, 128–191 reserved for client protocols, 192–255 for local extensions)
• Disconnect reason codes (SSH_DISCONNECT_HOST_KEY_NOT_VERIFIABLE, etc.)
• Channel open failure codes, extended data types, pseudo-terminal opcodes
• Named algorithm registries: encryption, MAC, public key, KEX, compression, service names, auth methods, connection protocol channel/request names

The message-number partitioning is subtle: because KEX-method-specific messages live in 30–49, two different key exchanges can reuse the same number for different messages. When you're doing diffie-hellman-group-exchange, message 34 means SSH_MSG_KEX_DH_GEX_REQUEST; during ecdh, message 30 means SSH_MSG_KEX_ECDH_INIT. Context, not opcode, disambiguates.

Why it matters today. The registry is how SSH stayed relevant across two decades of cryptographic churn. SHA-1 signatures got deprecated (ssh-rsa replaced by rsa-sha2-256/rsa-sha2-512 per RFC 8332). Ed25519 was added. Post-quantum KEX hybrids ([email protected], mlkem768x25519-sha256) are shipping now in OpenSSH — using exactly the naming convention this RFC laid down. When you read your sshd logs and see kex: algorithm: curve25519-sha256, you're looking at a string whose grammar RFC 4250 defined.

Backstory. The four-RFC split (architecture / transport / auth / connection) plus RFC 4250 for numbers mirrors the way ISO/OSI documents were structured, but the naming-with-@domain convention is pure IETF pragmatism — borrowed loosely from MIME's x-vendor tradition but made unambiguous by requiring a real domain. It has since been quietly copied by other protocols (SASL mechanism names, some XMPP extensions).