Network Working Group S. Lehtinen
Request for Comments: 4250 SSH Communications Security Corp
Category: Standards Track C. Lonvick, Ed.
Cisco Systems, Inc.
January 2006
Network Working Group S. Lehtinen
Request for Comments: 4250 SSH Communications Security Corp
Category: Standards Track C. Lonvick, Ed.
Cisco Systems, Inc.
January 2006
The Secure Shell (SSH) Protocol Assigned Numbers
安全Shell（SSH）协议指定了编号
Status of This Memo
关于下段备忘
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2006).
版权所有（C）互联网协会（2006年）。
Abstract
摘要
This document defines the instructions to the IANA and the initial state of the IANA assigned numbers for the Secure Shell (SSH) protocol. It is intended only for the initialization of the IANA registries referenced in the set of SSH documents.
本文档定义了安全Shell（SSH）协议的IANA指令和IANA分配编号的初始状态。它仅用于初始化SSH文档集中引用的IANA注册表。
Table of Contents
目录
1. Introduction ....................................................2
2. Contributors ....................................................3
3. Conventions Used in This Document ...............................3
3.1. RFC 2119 Keywords ..........................................3
3.2. RFC 2434 Keywords ..........................................3
3.3. Protocol Fields and Values .................................4
4. IANA Considerations .............................................5
4.1. Message Numbers ............................................5
4.1.1. Conventions .........................................5
4.1.2. Initial Assignments .................................6
4.1.3. Future Assignments ..................................6
4.2. Disconnection Messages Reason Codes and Descriptions .......7
4.2.1. Conventions .........................................7
4.2.2. Initial Assignments .................................7
4.2.3. Future Assignments ..................................8
4.3. Channel Connection Failure Reason Codes and Descriptions ...8
4.3.1. Conventions .........................................8
4.3.2. Initial Assignments .................................8
1. Introduction ....................................................2
2. Contributors ....................................................3
3. Conventions Used in This Document ...............................3
3.1. RFC 2119 Keywords ..........................................3
3.2. RFC 2434 Keywords ..........................................3
3.3. Protocol Fields and Values .................................4
4. IANA Considerations .............................................5
4.1. Message Numbers ............................................5
4.1.1. Conventions .........................................5
4.1.2. Initial Assignments .................................6
4.1.3. Future Assignments ..................................6
4.2. Disconnection Messages Reason Codes and Descriptions .......7
4.2.1. Conventions .........................................7
4.2.2. Initial Assignments .................................7
4.2.3. Future Assignments ..................................8
4.3. Channel Connection Failure Reason Codes and Descriptions ...8
4.3.1. Conventions .........................................8
4.3.2. Initial Assignments .................................8
4.3.3. Future Assignments ..................................8
4.3.4. Notes about the PRIVATE USE Range ...................9
4.4. Extended Channel Data Transfer data_type_code and Data .....9
4.4.1. Conventions .........................................9
4.4.2. Initial Assignments ................................10
4.4.3. Future Assignments .................................10
4.5. Pseudo-Terminal Encoded Terminal Modes ....................10
4.5.1. Conventions ........................................10
4.5.2. Initial Assignments ................................10
4.5.3. Future Assignments .................................12
4.6. Names .....................................................12
4.6.1. Conventions for Names ..............................13
4.6.2. Future Assignments of Names ........................13
4.7. Service Names .............................................13
4.8. Authentication Method Names ...............................14
4.9. Connection Protocol Assigned Names ........................14
4.9.1. Connection Protocol Channel Types ..................14
4.9.2. Connection Protocol Global Request Names ...........14
4.9.3. Connection Protocol Channel Request Names ..........15
4.9.4. Initial Assignment of Signal Names .................15
4.9.5. Connection Protocol Subsystem Names ................15
4.10. Key Exchange Method Names ................................16
4.11. Assigned Algorithm Names .................................16
4.11.1. Encryption Algorithm Names ........................16
4.11.2. MAC Algorithm Names ...............................17
4.11.3. Public Key Algorithm Names ........................17
4.11.4. Compression Algorithm Names .......................17
5. Security Considerations ........................................17
6. References .....................................................18
6.1. Normative References ......................................18
6.2. Informative References ....................................18
Authors' Addresses ................................................19
Trademark Notice ..................................................19
4.3.3. Future Assignments ..................................8
4.3.4. Notes about the PRIVATE USE Range ...................9
4.4. Extended Channel Data Transfer data_type_code and Data .....9
4.4.1. Conventions .........................................9
4.4.2. Initial Assignments ................................10
4.4.3. Future Assignments .................................10
4.5. Pseudo-Terminal Encoded Terminal Modes ....................10
4.5.1. Conventions ........................................10
4.5.2. Initial Assignments ................................10
4.5.3. Future Assignments .................................12
4.6. Names .....................................................12
4.6.1. Conventions for Names ..............................13
4.6.2. Future Assignments of Names ........................13
4.7. Service Names .............................................13
4.8. Authentication Method Names ...............................14
4.9. Connection Protocol Assigned Names ........................14
4.9.1. Connection Protocol Channel Types ..................14
4.9.2. Connection Protocol Global Request Names ...........14
4.9.3. Connection Protocol Channel Request Names ..........15
4.9.4. Initial Assignment of Signal Names .................15
4.9.5. Connection Protocol Subsystem Names ................15
4.10. Key Exchange Method Names ................................16
4.11. Assigned Algorithm Names .................................16
4.11.1. Encryption Algorithm Names ........................16
4.11.2. MAC Algorithm Names ...............................17
4.11.3. Public Key Algorithm Names ........................17
4.11.4. Compression Algorithm Names .......................17
5. Security Considerations ........................................17
6. References .....................................................18
6.1. Normative References ......................................18
6.2. Informative References ....................................18
Authors' Addresses ................................................19
Trademark Notice ..................................................19
This document does not define any new protocols. It is intended only to create the initial state of the IANA databases for the SSH protocol and also contains instructions for future assignments. Except for one HISTORIC algorithm generally regarded as obsolete, this document does not define any new protocols or number ranges not already defined in: [SSH-ARCH], [SSH-TRANS], [SSH-USERAUTH], [SSH-CONNECT].
本文件未定义任何新协议。它仅用于为SSH协议创建IANA数据库的初始状态，还包含有关未来分配的说明。除了一个通常被视为过时的历史算法外，本文档未定义任何在[SSH-ARCH]、[SSH-TRANS]、[SSH-USERAUTH]、[SSH-CONNECT]中尚未定义的新协议或编号范围。
The major original contributors of this set of documents have been: Tatu Ylonen, Tero Kivinen, Timo J. Rinne, Sami Lehtinen (all of SSH Communications Security Corp), and Markku-Juhani O. Saarinen (University of Jyvaskyla). Darren Moffat was the original editor of this set of documents and also made very substantial contributions.
这组文档的主要原始贡献者是：Tatu Ylonen、Tero Kivinen、Timo J.Rinne、Sami Lehtinen（SSH Communications Security Corp的所有成员）和Markku Juhani O.Saarinen（Jyvaskyla大学）。达伦·莫法特（Darren Moffat）是这组文件的原始编辑，也做出了重大贡献。
Many people contributed to the development of this document over the years. People who should be acknowledged include Mats Andersson, Ben Harris, Bill Sommerfeld, Brent McClure, Niels Moller, Damien Miller, Derek Fawcus, Frank Cusack, Heikki Nousiainen, Jakob Schlyter, Jeff Van Dyke, Jeffrey Altman, Jeffrey Hutzelman, Jon Bright, Joseph Galbraith, Ken Hornstein, Markus Friedl, Martin Forssen, Nicolas Williams, Niels Provos, Perry Metzger, Peter Gutmann, Simon Josefsson, Simon Tatham, Wei Dai, Denis Bider, der Mouse, and Tadayoshi Kohno. Listing their names here does not mean that they endorse this document, but that they have contributed to it.
多年来，许多人为本文件的编写做出了贡献。应该承认的人包括马茨·安德森、本·哈里斯、比尔·索末菲、布伦特·麦克卢尔、尼尔斯·莫勒、达米恩·米勒、德里克·福库斯、弗兰克·库萨克、海基·努西亚宁、雅各布·施莱特、杰夫·范·戴克、杰弗里·奥特曼、杰弗里·哈泽尔曼、乔恩·布莱特、约瑟夫·加尔布雷斯、肯·霍恩斯坦、马克斯·弗里德、马丁·福森、尼古拉斯·威廉姆斯、，Niels Provos、Perry Metzger、Peter Gutmann、Simon Josefsson、Simon Tatham、Wei Dai、Denis Bider、der Mouse和Tadayoshi Kohno。在这里列出他们的名字并不意味着他们认可这份文件，而是意味着他们对这份文件作出了贡献。
All documents related to the SSH protocols shall use the keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" to describe requirements. These keywords are to be interpreted as described in [RFC2119].
所有与SSH协议相关的文件应使用关键字“必须”、“不得”、“必需”、“应”、“不得”、“应”、“不应”、“建议”、“可”和“可选”来描述要求。这些关键字将按照[RFC2119]中所述进行解释。
The keywords "PRIVATE USE", "HIERARCHICAL ALLOCATION", "FIRST COME FIRST SERVED", "EXPERT REVIEW", "SPECIFICATION REQUIRED", "IESG APPROVAL", "IETF CONSENSUS", and "STANDARDS ACTION" that appear in this document when used to describe namespace allocation are to be interpreted as described in [RFC2434]. These designations are repeated in this document for clarity.
当用于描述命名空间分配时，本文件中出现的关键词“私人使用”、“分层分配”、“先到先得”、“专家评审”、“所需规范”、“IESG批准”、“IETF共识”和“标准行动”应按照[RFC2434]中所述进行解释。为清晰起见，本文件中重复了这些名称。
PRIVATE USE - For private or local use only, with the type and purpose defined by the local site. No attempt is made to prevent multiple sites from using the same value in different (and incompatible) ways. There is no need for IANA to review such assignments and assignments are not generally useful for interoperability.
私人使用-仅供私人或本地使用，类型和用途由本地站点定义。未尝试阻止多个站点以不同（且不兼容）的方式使用相同的值。IANA无需审查此类分配，而且这些分配通常对互操作性没有帮助。
HIERARCHICAL ALLOCATION - Delegated managers can assign values provided they have been given control over that part of the name space. IANA controls the higher levels of the namespace according to one of the other policies.
分层分配-委托经理可以分配值，前提是他们已获得对名称空间该部分的控制权。IANA根据其他策略之一控制命名空间的更高级别。
FIRST COME FIRST SERVED - Anyone can obtain an assigned number, so long as they provide a point of contact and a brief description of what the value would be used for. For numbers, the exact value is generally assigned by the IANA; with names, specific names are usually requested.
先到先得-任何人都可以获得一个指定的号码，只要他们提供一个联系点，并简要说明该值的用途。对于数字，准确值通常由IANA指定；对于名称，通常需要特定的名称。
EXPERT REVIEW - approval by a Designated Expert is required.
专家审查-需要指定专家的批准。
SPECIFICATION REQUIRED - Values and their meaning must be documented in an RFC or other permanent and readily available reference, in sufficient detail so that interoperability between independent implementations is possible.
所需规范-值及其含义必须记录在RFC或其他永久性且随时可用的参考文件中，足够详细，以便独立实现之间的互操作性成为可能。
IESG APPROVAL - New assignments must be approved by the IESG, but there is no requirement that the request be documented in an RFC (though the IESG has discretion to request documents or other supporting materials on a case-by-case basis).
IESG批准-新任务必须经IESG批准，但不要求将请求记录在RFC中（尽管IESG有权根据具体情况申请文件或其他支持材料）。
IETF CONSENSUS - New values are assigned through the IETF consensus process. Specifically, new assignments are made via RFCs approved by the IESG. Typically, the IESG will seek input on prospective assignments from appropriate persons (e.g., a relevant Working Group if one exists).
IETF共识-通过IETF共识流程分配新值。具体而言，新任务通过IESG批准的RFC完成。通常情况下，IESG将寻求适当人员（例如，相关工作组，如果存在）对预期任务的投入。
STANDARDS ACTION - Values are assigned only for Standards Track RFCs approved by the IESG.
标准行动-仅为IESG批准的标准跟踪RFC分配值。
Protocol fields and possible values to fill them are defined in this set of documents. Protocol fields will be defined in the message definitions. As an example, SSH_MSG_CHANNEL_DATA is defined as follows.
协议字段和可能的填充值在这组文档中定义。协议字段将在消息定义中定义。例如，SSH_MSG_CHANNEL_数据定义如下。
byte SSH_MSG_CHANNEL_DATA uint32 recipient channel string data
字节SSH\U MSG\U通道数据uint32收件人通道字符串数据
Throughout these documents, when the fields are referenced, they will appear within single quotes. When values to fill those fields are referenced, they will appear within double quotes. Using the above example, possible values for 'data' are "foo" and "bar".
在这些文档中，当引用字段时，它们将出现在单引号中。当引用填充这些字段的值时，它们将出现在双引号内。使用上述示例，“数据”的可能值为“foo”和“bar”。
This entire document is the IANA considerations for the SSH protocol, as defined in [SSH-ARCH], [SSH-TRANS], [SSH-USERAUTH], [SSH-CONNECT]. This section contains conventions used in naming the namespaces, the initial state of the registry, and instructions for future assignments.
整个文档是[SSH-ARCH]、[SSH-TRANS]、[SSH-USERAUTH]、[SSH-CONNECT]中定义的SSH协议的IANA注意事项。本节包含命名名称空间时使用的约定、注册表的初始状态以及将来分配的说明。
The Message Number is a byte value that describes the payload of a packet.
消息编号是描述数据包有效负载的字节值。
Protocol packets have message numbers in the range 1 to 255. These numbers are allocated as follows:
协议数据包的消息编号范围为1到255。这些数字分配如下：
Transport layer protocol:
传输层协议：
1 to 19 Transport layer generic (e.g., disconnect, ignore, debug, etc.) 20 to 29 Algorithm negotiation 30 to 49 Key exchange method specific (numbers can be reused for different authentication methods)
1至19传输层通用（例如，断开连接、忽略、调试等）20至29算法协商30至49密钥交换方法特定（数字可用于不同的身份验证方法）
User authentication protocol:
用户身份验证协议：
50 to 59 User authentication generic 60 to 79 User authentication method specific (numbers can be reused for different authentication methods)
50到59用户身份验证通用60到79用户身份验证方法特定（数字可用于不同的身份验证方法）
Connection protocol:
连接协议：
80 to 89 Connection protocol generic 90 to 127 Channel related messages
80至89连接协议通用90至127通道相关消息
Reserved for client protocols:
为客户端协议保留：
128 to 191 Reserved
128至191保留
Local extensions:
本地扩展：
192 to 255 Local extensions
192到255个本地扩展
The following table identifies the initial assignments of the Message ID values.
下表确定了消息ID值的初始分配。
Message ID Value Reference
----------- ----- ---------
SSH_MSG_DISCONNECT 1 [SSH-TRANS]
SSH_MSG_IGNORE 2 [SSH-TRANS]
SSH_MSG_UNIMPLEMENTED 3 [SSH-TRANS]
SSH_MSG_DEBUG 4 [SSH-TRANS]
SSH_MSG_SERVICE_REQUEST 5 [SSH-TRANS]
SSH_MSG_SERVICE_ACCEPT 6 [SSH-TRANS]
SSH_MSG_KEXINIT 20 [SSH-TRANS]
SSH_MSG_NEWKEYS 21 [SSH-TRANS]
SSH_MSG_USERAUTH_REQUEST 50 [SSH-USERAUTH]
SSH_MSG_USERAUTH_FAILURE 51 [SSH-USERAUTH]
SSH_MSG_USERAUTH_SUCCESS 52 [SSH-USERAUTH]
SSH_MSG_USERAUTH_BANNER 53 [SSH-USERAUTH]
SSH_MSG_GLOBAL_REQUEST 80 [SSH-CONNECT]
SSH_MSG_REQUEST_SUCCESS 81 [SSH-CONNECT]
SSH_MSG_REQUEST_FAILURE 82 [SSH-CONNECT]
SSH_MSG_CHANNEL_OPEN 90 [SSH-CONNECT]
SSH_MSG_CHANNEL_OPEN_CONFIRMATION 91 [SSH-CONNECT]
SSH_MSG_CHANNEL_OPEN_FAILURE 92 [SSH-CONNECT]
SSH_MSG_CHANNEL_WINDOW_ADJUST 93 [SSH-CONNECT]
SSH_MSG_CHANNEL_DATA 94 [SSH-CONNECT]
SSH_MSG_CHANNEL_EXTENDED_DATA 95 [SSH-CONNECT]
SSH_MSG_CHANNEL_EOF 96 [SSH-CONNECT]
SSH_MSG_CHANNEL_CLOSE 97 [SSH-CONNECT]
SSH_MSG_CHANNEL_REQUEST 98 [SSH-CONNECT]
SSH_MSG_CHANNEL_SUCCESS 99 [SSH-CONNECT]
SSH_MSG_CHANNEL_FAILURE 100 [SSH-CONNECT]
Message ID Value Reference
----------- ----- ---------
SSH_MSG_DISCONNECT 1 [SSH-TRANS]
SSH_MSG_IGNORE 2 [SSH-TRANS]
SSH_MSG_UNIMPLEMENTED 3 [SSH-TRANS]
SSH_MSG_DEBUG 4 [SSH-TRANS]
SSH_MSG_SERVICE_REQUEST 5 [SSH-TRANS]
SSH_MSG_SERVICE_ACCEPT 6 [SSH-TRANS]
SSH_MSG_KEXINIT 20 [SSH-TRANS]
SSH_MSG_NEWKEYS 21 [SSH-TRANS]
SSH_MSG_USERAUTH_REQUEST 50 [SSH-USERAUTH]
SSH_MSG_USERAUTH_FAILURE 51 [SSH-USERAUTH]
SSH_MSG_USERAUTH_SUCCESS 52 [SSH-USERAUTH]
SSH_MSG_USERAUTH_BANNER 53 [SSH-USERAUTH]
SSH_MSG_GLOBAL_REQUEST 80 [SSH-CONNECT]
SSH_MSG_REQUEST_SUCCESS 81 [SSH-CONNECT]
SSH_MSG_REQUEST_FAILURE 82 [SSH-CONNECT]
SSH_MSG_CHANNEL_OPEN 90 [SSH-CONNECT]
SSH_MSG_CHANNEL_OPEN_CONFIRMATION 91 [SSH-CONNECT]
SSH_MSG_CHANNEL_OPEN_FAILURE 92 [SSH-CONNECT]
SSH_MSG_CHANNEL_WINDOW_ADJUST 93 [SSH-CONNECT]
SSH_MSG_CHANNEL_DATA 94 [SSH-CONNECT]
SSH_MSG_CHANNEL_EXTENDED_DATA 95 [SSH-CONNECT]
SSH_MSG_CHANNEL_EOF 96 [SSH-CONNECT]
SSH_MSG_CHANNEL_CLOSE 97 [SSH-CONNECT]
SSH_MSG_CHANNEL_REQUEST 98 [SSH-CONNECT]
SSH_MSG_CHANNEL_SUCCESS 99 [SSH-CONNECT]
SSH_MSG_CHANNEL_FAILURE 100 [SSH-CONNECT]
Requests for assignments of new message numbers in the range of 1 to 29, 50 to 59, and 80 to 127 MUST be done through the STANDARDS ACTION method, as described in [RFC2434].
如[RFC2434]中所述，必须通过标准操作方法完成分配范围为1至29、50至59和80至127的新消息编号的请求。
The meanings of message numbers in the range of 30 to 49 are specific to the key exchange method in use, and their meaning will be specified by the definition of that method.
30到49范围内的消息编号的含义特定于所使用的密钥交换方法，其含义将由该方法的定义指定。
The meanings of message numbers in the range of 60 to 79 are specific to the user authentication method in use, and their meaning will be specified by the definition of that method.
60到79范围内的消息编号的含义特定于所使用的用户身份验证方法，其含义将由该方法的定义指定。
Requests for assignments of new message numbers in the range of 128 to 191 MUST be done through the IETF CONSENSUS method, as described in [RFC2434].
如[RFC2434]所述，必须通过IETF协商一致的方法来完成分配128到191范围内的新消息编号的请求。
The IANA will not control the message numbers in the range of 192 through 255. This range will be left for PRIVATE USE.
IANA不会将消息编号控制在192到255之间。此范围将留给私人使用。
The Disconnection Message 'reason code' is a uint32 value. The associated Disconnection Message 'description' is a human-readable message that describes the disconnect reason.
断开消息“原因代码”是uint32值。关联的断开连接消息“description”是描述断开连接原因的可读消息。
Protocol packets containing the SSH_MSG_DISCONNECT message MUST have Disconnection Message 'reason code' values in the range of 0x00000001 to 0xFFFFFFFF. These are described in [SSH-TRANS].
包含SSH_MSG_DISCONNECT消息的协议数据包必须具有0x00000001到0xFFFFFF范围内的断开消息“原因码”值。这些在[SSH-TRANS]中进行了描述。
The following table identifies the initial assignments of the SSH_MSG_DISCONNECT 'description' and 'reason code' values.
下表列出了SSH_MSG_DISCONNECT“description”和“reason code”值的初始分配。
Symbolic Name reason code
------------- -----------
SSH_DISCONNECT_HOST_NOT_ALLOWED_TO_CONNECT 1
SSH_DISCONNECT_PROTOCOL_ERROR 2
SSH_DISCONNECT_KEY_EXCHANGE_FAILED 3
SSH_DISCONNECT_RESERVED 4
SSH_DISCONNECT_MAC_ERROR 5
SSH_DISCONNECT_COMPRESSION_ERROR 6
SSH_DISCONNECT_SERVICE_NOT_AVAILABLE 7
SSH_DISCONNECT_PROTOCOL_VERSION_NOT_SUPPORTED 8
SSH_DISCONNECT_HOST_KEY_NOT_VERIFIABLE 9
SSH_DISCONNECT_CONNECTION_LOST 10
SSH_DISCONNECT_BY_APPLICATION 11
SSH_DISCONNECT_TOO_MANY_CONNECTIONS 12
SSH_DISCONNECT_AUTH_CANCELLED_BY_USER 13
SSH_DISCONNECT_NO_MORE_AUTH_METHODS_AVAILABLE 14
SSH_DISCONNECT_ILLEGAL_USER_NAME 15
Symbolic Name reason code
------------- -----------
SSH_DISCONNECT_HOST_NOT_ALLOWED_TO_CONNECT 1
SSH_DISCONNECT_PROTOCOL_ERROR 2
SSH_DISCONNECT_KEY_EXCHANGE_FAILED 3
SSH_DISCONNECT_RESERVED 4
SSH_DISCONNECT_MAC_ERROR 5
SSH_DISCONNECT_COMPRESSION_ERROR 6
SSH_DISCONNECT_SERVICE_NOT_AVAILABLE 7
SSH_DISCONNECT_PROTOCOL_VERSION_NOT_SUPPORTED 8
SSH_DISCONNECT_HOST_KEY_NOT_VERIFIABLE 9
SSH_DISCONNECT_CONNECTION_LOST 10
SSH_DISCONNECT_BY_APPLICATION 11
SSH_DISCONNECT_TOO_MANY_CONNECTIONS 12
SSH_DISCONNECT_AUTH_CANCELLED_BY_USER 13
SSH_DISCONNECT_NO_MORE_AUTH_METHODS_AVAILABLE 14
SSH_DISCONNECT_ILLEGAL_USER_NAME 15
Disconnection Message 'reason code' values MUST be assigned sequentially. Requests for assignments of new Disconnection Message 'reason code' values, and their associated Disconnection Message 'description' text, in the range of 0x00000010 through 0xFDFFFFFF, MUST be done through the IETF CONSENSUS method, as described in [RFC2434]. The IANA will not assign Disconnection Message 'reason code' values in the range of 0xFE000000 through 0xFFFFFFFF. Disconnection Message 'reason code' values in that range are left for PRIVATE USE, as described in [RFC2434].
必须按顺序分配断开消息“原因代码”值。如[RFC2434]所述，必须通过IETF协商一致方法，请求分配0x00000010至0xFDFFFF范围内的新断开消息“原因码”值及其相关断开消息“说明”文本。IANA不会分配0xFE000000到0xFFFFFF范围内的断开消息“原因代码”值。如[RFC2434]所述，该范围内的断开消息“原因代码”值留作私人使用。
The Channel Connection Failure 'reason code' is a uint32 value. The associated Channel Connection Failure 'description' text is a human-readable message that describes the channel connection failure reason. This is described in [SSH-CONNECT].
通道连接故障“原因代码”是uint32值。关联的通道连接故障“描述”文本是一条人类可读的消息，用于描述通道连接故障原因。这在[SSH-CONNECT]中有描述。
Protocol packets containing the SSH_MSG_CHANNEL_OPEN_FAILURE message MUST have Channel Connection Failure 'reason code' values in the range of 0x00000001 to 0xFFFFFFFF.
包含SSH_MSG_CHANNEL_OPEN_故障消息的协议数据包的通道连接故障“原因码”值必须在0x00000001到0xFFFFFF之间。
The initial assignments for the 'reason code' values and 'description' values are given in the table below. Note that the values for the 'reason code' are given in decimal format for readability, but they are actually uint32 values.
下表给出了“原因代码”值和“说明”值的初始分配。请注意，“原因代码”的值是以十进制格式给出的，以便于阅读，但它们实际上是uint32值。
Symbolic Name reason code
------------- -----------
SSH_OPEN_ADMINISTRATIVELY_PROHIBITED 1
SSH_OPEN_CONNECT_FAILED 2
SSH_OPEN_UNKNOWN_CHANNEL_TYPE 3
SSH_OPEN_RESOURCE_SHORTAGE 4
Symbolic Name reason code
------------- -----------
SSH_OPEN_ADMINISTRATIVELY_PROHIBITED 1
SSH_OPEN_CONNECT_FAILED 2
SSH_OPEN_UNKNOWN_CHANNEL_TYPE 3
SSH_OPEN_RESOURCE_SHORTAGE 4
Channel Connection Failure 'reason code' values MUST be assigned sequentially. Requests for assignments of new Channel Connection Failure 'reason code' values, and their associated Channel Connection Failure 'description string', in the range of 0x00000005 to 0xFDFFFFFF MUST be done through the IETF CONSENSUS method, as described in [RFC2434]. The IANA will not assign Channel Connection
通道连接故障“原因代码”值必须按顺序分配。如[RFC2434]所述，必须通过IETF协商一致方法，请求分配0x00000005至0xFDFFFF范围内的新信道连接故障“原因码”值及其相关信道连接故障“描述字符串”。IANA不会分配通道连接
Failure 'reason code' values in the range of 0xFE000000 to 0xFFFFFFFF. Channel Connection Failure 'reason code' values in that range are left for PRIVATE USE, as described in [RFC2434].
0xFE000000到0xFFFFFF范围内的故障“原因代码”值。如[RFC2434]所述，该范围内的通道连接故障“原因代码”值留待私人使用。
While it is understood that the IANA will have no control over the range of 0xFE000000 to 0xFFFFFFFF, this range will be split in two parts and administered by the following conventions.
虽然IANA无法控制0xFE000000到0xFFFFFF的范围，但该范围将分为两部分，并由以下约定管理。
o The range of 0xFE000000 to 0xFEFFFFFF is to be used in conjunction with locally assigned channels. For example, if a channel is proposed with a 'channel type' of "example_session@example.com" but fails, then the server will respond with either a 'reason code' assigned by the IANA (as listed above and in the range of 0x00000001 to 0xFDFFFFFF), or with a locally assigned value in the range of 0xFE000000 to 0xFEFFFFFF. Naturally, if the server does not understand the proposed 'channel type', even if it is a locally defined 'channel type', then the 'reason code' MUST be 0x00000003, as described above. If the server does understand the 'channel type', but the channel still fails to open, then the server SHOULD respond with a locally assigned 'reason code' value that is consistent with the proposed local 'channel type'. It is assumed that practitioners will first attempt to use the IANA-assigned 'reason code' values and then document their locally assigned 'reason code' values.
o 0xFE000000到0xFEFFFF的范围将与本地分配的通道一起使用。例如，如果一个通道的“通道类型”为“示例_session@example.com“但是如果失败，那么服务器将使用IANA分配的‘原因码’（如上所列，在0x00000001到0xFDFFFF范围内）或本地分配的0xFE000000到0xFEFFFF范围内的值进行响应。当然，如果服务器不理解建议的“通道类型”，即使它是本地定义的“通道类型”，那么“原因代码”必须是0x00000003，如上所述。如果服务器确实了解“通道类型”，但通道仍然无法打开，则服务器应使用本地分配的“原因码”值进行响应，该值与建议的本地“通道类型”一致。假设从业者将首先尝试使用IANA指定的“原因代码”值，然后记录其本地指定的“原因代码”值。
o There are no restrictions or suggestions for the range starting with 0xFF. No interoperability is expected for anything used in this range. Essentially, it is for experimentation.
o 对于以0xFF开头的范围，没有任何限制或建议。此范围内使用的任何东西都不需要互操作性。从本质上讲，这是为了实验。
The Extended Channel Data Transfer 'data_type_code' is a uint32 value. The associated Extended Channel Data Transfer 'data' is a human-readable message that describes the type of data allowed to be transferred in the channel.
扩展通道数据传输“数据类型代码”是uint32值。关联的扩展通道数据传输“数据”是一条人类可读的消息，描述允许在通道中传输的数据类型。
Protocol packets containing the SSH_MSG_CHANNEL_EXTENDED_DATA message MUST have Extended Channel Data Transfer 'data_type_code' values in the range of 0x00000001 to 0xFFFFFFFF. This is described in [SSH-CONNECT].
包含SSH_MSG_CHANNEL_EXTENDED_数据消息的协议包必须具有0x00000001到0xFFFFFFFF范围内的扩展通道数据传输“数据类型_代码”值。这在[SSH-CONNECT]中有描述。
The initial assignments for the 'data_type_code' values and 'data' values are given in the table below. Note that the value for the 'data_type_code' is given in decimal format for readability, but the values are actually uint32 values.
下表给出了“数据类型代码”值和“数据”值的初始分配。请注意，“数据类型代码”的值是以十进制格式给出的，以便于阅读，但这些值实际上是uint32值。
Symbolic name data_type_code
------------- --------------
SSH_EXTENDED_DATA_STDERR 1
Symbolic name data_type_code
------------- --------------
SSH_EXTENDED_DATA_STDERR 1
Extended Channel Data Transfer 'data_type_code' values MUST be assigned sequentially. Requests for assignments of new Extended Channel Data Transfer 'data_type_code' values, and their associated Extended Channel Data Transfer 'data' strings, in the range of 0x00000002 to 0xFDFFFFFF, MUST be done through the IETF CONSENSUS method, as described in [RFC2434]. The IANA will not assign Extended Channel Data Transfer 'data_type_code' values in the range of 0xFE000000 to 0xFFFFFFFF. Extended Channel Data Transfer 'data_type_code' values in that range are left for PRIVATE USE, as described in [RFC2434].
扩展通道数据传输“数据类型代码”值必须按顺序分配。对于0x00000002至0xFDFFFF范围内的新扩展信道数据传输“数据类型代码”值及其相关扩展信道数据传输“数据”字符串的分配请求，必须通过IETF协商一致方法完成，如[RFC2434]所述。IANA不会分配0xFE000000到0xFFFFFF范围内的扩展通道数据传输“数据类型代码”值。如[RFC2434]所述，该范围内的扩展信道数据传输“数据类型代码”值留作私人使用。
SSH_MSG_CHANNEL_REQUEST messages with a "pty-req" string MUST contain 'encoded terminal modes'. The 'encoded terminal modes' value is a byte stream of opcode-argument pairs.
带有“pty req”字符串的SSH_MSG_CHANNEL_请求消息必须包含“编码终端模式”。“编码终端模式”值是操作码参数对的字节流。
Protocol packets containing the SSH_MSG_CHANNEL_REQUEST message with a "pty-req" string MUST contain an 'encoded terminal modes' value. The opcode values consist of a single byte and are in the range of 1 to 255. Opcodes 1 to 159 have a uint32 argument. Opcodes 160 to 255 are not yet defined.
包含带有“pty req”字符串的SSH_MSG_CHANNEL_请求消息的协议包必须包含“encoded terminal modes”值。操作码值由一个字节组成，范围为1到255。操作码1到159有一个uint32参数。操作码160至255尚未定义。
The following table identifies the initial assignments of the opcode values that are used in the 'encoded terminal modes' value.
下表确定了“编码终端模式”值中使用的操作码值的初始分配。
opcode mnemonic description
------ -------- -----------
0 TTY_OP_END Indicates end of options.
1 VINTR Interrupt character; 255 if none. Similarly
for the other characters. Not all of these
characters are supported on all systems.
2 VQUIT The quit character (sends SIGQUIT signal on
POSIX systems).
3 VERASE Erase the character to left of the cursor.
4 VKILL Kill the current input line.
5 VEOF End-of-file character (sends EOF from the
terminal).
6 VEOL End-of-line character in addition to
carriage return and/or linefeed.
7 VEOL2 Additional end-of-line character.
8 VSTART Continues paused output (normally
control-Q).
9 VSTOP Pauses output (normally control-S).
10 VSUSP Suspends the current program.
11 VDSUSP Another suspend character.
12 VREPRINT Reprints the current input line.
13 VWERASE Erases a word left of cursor.
14 VLNEXT Enter the next character typed literally,
even if it is a special character
15 VFLUSH Character to flush output.
16 VSWTCH Switch to a different shell layer.
17 VSTATUS Prints system status line (load, command,
pid, etc).
18 VDISCARD Toggles the flushing of terminal output.
30 IGNPAR The ignore parity flag. The parameter
SHOULD be 0 if this flag is FALSE,
and 1 if it is TRUE.
31 PARMRK Mark parity and framing errors.
32 INPCK Enable checking of parity errors.
33 ISTRIP Strip 8th bit off characters.
34 INLCR Map NL into CR on input.
35 IGNCR Ignore CR on input.
36 ICRNL Map CR to NL on input.
37 IUCLC Translate uppercase characters to
lowercase.
38 IXON Enable output flow control.
39 IXANY Any char will restart after stop.
40 IXOFF Enable input flow control.
41 IMAXBEL Ring bell on input queue full.
50 ISIG Enable signals INTR, QUIT, [D]SUSP.
51 ICANON Canonicalize input lines.
opcode mnemonic description
------ -------- -----------
0 TTY_OP_END Indicates end of options.
1 VINTR Interrupt character; 255 if none. Similarly
for the other characters. Not all of these
characters are supported on all systems.
2 VQUIT The quit character (sends SIGQUIT signal on
POSIX systems).
3 VERASE Erase the character to left of the cursor.
4 VKILL Kill the current input line.
5 VEOF End-of-file character (sends EOF from the
terminal).
6 VEOL End-of-line character in addition to
carriage return and/or linefeed.
7 VEOL2 Additional end-of-line character.
8 VSTART Continues paused output (normally
control-Q).
9 VSTOP Pauses output (normally control-S).
10 VSUSP Suspends the current program.
11 VDSUSP Another suspend character.
12 VREPRINT Reprints the current input line.
13 VWERASE Erases a word left of cursor.
14 VLNEXT Enter the next character typed literally,
even if it is a special character
15 VFLUSH Character to flush output.
16 VSWTCH Switch to a different shell layer.
17 VSTATUS Prints system status line (load, command,
pid, etc).
18 VDISCARD Toggles the flushing of terminal output.
30 IGNPAR The ignore parity flag. The parameter
SHOULD be 0 if this flag is FALSE,
and 1 if it is TRUE.
31 PARMRK Mark parity and framing errors.
32 INPCK Enable checking of parity errors.
33 ISTRIP Strip 8th bit off characters.
34 INLCR Map NL into CR on input.
35 IGNCR Ignore CR on input.
36 ICRNL Map CR to NL on input.
37 IUCLC Translate uppercase characters to
lowercase.
38 IXON Enable output flow control.
39 IXANY Any char will restart after stop.
40 IXOFF Enable input flow control.
41 IMAXBEL Ring bell on input queue full.
50 ISIG Enable signals INTR, QUIT, [D]SUSP.
51 ICANON Canonicalize input lines.
52 XCASE Enable input and output of uppercase characters by preceding their lowercase equivalents with "\". 53 ECHO Enable echoing. 54 ECHOE Visually erase chars. 55 ECHOK Kill character discards current line. 56 ECHONL Echo NL even if ECHO is off. 57 NOFLSH Don't flush after interrupt. 58 TOSTOP Stop background jobs from output. 59 IEXTEN Enable extensions. 60 ECHOCTL Echo control characters as ^(Char). 61 ECHOKE Visual erase for line kill. 62 PENDIN Retype pending input. 70 OPOST Enable output processing. 71 OLCUC Convert lowercase to uppercase. 72 ONLCR Map NL to CR-NL. 73 OCRNL Translate carriage return to newline (output). 74 ONOCR Translate newline to carriage return-newline (output). 75 ONLRET Newline performs a carriage return (output). 90 CS7 7 bit mode. 91 CS8 8 bit mode. 92 PARENB Parity enable. 93 PARODD Odd parity, else even.
52 XCASE通过在大写字符对应的小写字符前面加上“\”来启用大写字符的输入和输出。53回显启用回显。54回声视觉擦除字符。55 ECHOK Kill字符丢弃当前行。56 Echo NL Echo NL，即使Echo关闭。57 NOFLSH在中断后不刷新。58从输出停止后台作业。59 IEXTEN启用扩展。60个ECHOCTL回显控制字符作为^（字符）。61 ECHOKE目视擦除用于线路终止。62 PENDIN重新键入挂起的输入。70 OPOST启用输出处理。71 OLCUC将小写转换为大写。72 ONLCR将NL映射到CR-NL。73 OCRNL转换回车到换行符（输出）。74 ONOCR将换行符转换为回车换行符（输出）。75 ONLRET Newline执行回车（输出）。90 CS7 7位模式。91 CS8 8位模式。92 PARENB奇偶校验启用。93奇偶校验，否则为偶数。
128 TTY_OP_ISPEED Specifies the input baud rate in bits per second. 129 TTY_OP_OSPEED Specifies the output baud rate in bits per second.
128 TTY_OP_ISPEED以位/秒为单位指定输入波特率。129 TTY_OP_OSPEED以位/秒为单位指定输出波特率。
Requests for assignments of new opcodes and their associated arguments MUST be done through the IETF CONSENSUS method, as described in [RFC2434].
新操作码及其相关参数的分配请求必须通过IETF协商一致方法完成，如[RFC2434]所述。
In the following sections, the values for the name spaces are textual. The conventions and instructions to the IANA for future assignments are given in this section. The initial assignments are given in their respective sections.
在以下部分中，名称空间的值是文本的。本节给出了IANA未来任务的约定和说明。最初的作业在各自的章节中给出。
All names registered by the IANA in the following sections MUST be printable US-ASCII strings, and MUST NOT contain the characters at-sign ("@"), comma (","), whitespace, control characters (ASCII codes 32 or less), or the ASCII code 127 (DEL). Names are case-sensitive, and MUST NOT be longer than 64 characters.
IANA在以下章节中注册的所有名称必须是可打印的US-ASCII字符串，并且不得包含符号（“@”）、逗号（“，”）处的字符、空格、控制字符（ASCII代码32或更少）或ASCII代码127（DEL）。名称区分大小写，长度不得超过64个字符。
A provision is made here for locally extensible names. The IANA will not register, and will not control, names with the at-sign in them.
这里规定了本地可扩展名称。IANA不会注册，也不会控制带有at标志的姓名。
Names with the at-sign in them will have the format of "name@domainname" (without the double quotes) where the part preceding the at-sign is the name. The format of the part preceding the at-sign is not specified; however, these names MUST be printable US-ASCII strings, and MUST NOT contain the comma character (","), whitespace, control characters (ASCII codes 32 or less), or the ASCII code 127 (DEL). They MUST have only a single at-sign in them. The part following the at-sign MUST be a valid, fully qualified internet domain name [RFC1034] controlled by the person or organization defining the name. Names are case-sensitive, and MUST NOT be longer than 64 characters. It is up to each domain how it manages its local namespace. It has been noted that these names resemble STD 11 [RFC0822] email addresses. This is purely coincidental and has nothing to do with STD 11 [RFC0822]. An example of a locally defined name is "ourcipher-cbc@example.com" (without the double quotes).
带有at符号的名称的格式为“name@domainname“（不带双引号），其中at符号前的部分为名称。未规定at标志前面部分的格式；但是，这些名称必须是可打印的US-ASCII字符串，并且不得包含逗号字符（“，”）、空格、控制字符（ASCII代码32或更少）或ASCII代码127（DEL）。他们必须只有一个at标志。at标志后面的部分必须是由定义名称的个人或组织控制的有效、完全限定的internet域名[RFC1034]。名称区分大小写，长度不得超过64个字符。如何管理其本地名称空间取决于每个域。注意，这些名称类似于STD 11[RFC0822]电子邮件地址。这纯粹是巧合，与STD 11[RFC0822]无关。本地定义名称的一个示例是“ourcipher”-cbc@example.com“（不带双引号）。
Requests for assignments of new names MUST be done through the IETF CONSENSUS method, as described in [RFC2434].
如[RFC2434]所述，分配新名称的请求必须通过IETF协商一致方法完成。
The 'service name' is used to describe a protocol layer. The following table lists the initial assignments of the 'service name' values.
“服务名称”用于描述协议层。下表列出了“服务名称”值的初始分配。
Service Name Reference
------------- ---------
ssh-userauth [SSH-USERAUTH]
ssh-connection [SSH-CONNECT]
Service Name Reference
------------- ---------
ssh-userauth [SSH-USERAUTH]
ssh-connection [SSH-CONNECT]
The Authentication Method Name is used to describe an authentication method for the "ssh-userauth" service [SSH-USERAUTH]. The following table identifies the initial assignments of the Authentication Method Names.
身份验证方法名称用于描述“ssh-userauth”服务[ssh-userauth]的身份验证方法。下表标识了身份验证方法名称的初始分配。
Method Name Reference
------------ ---------
publickey [SSH-USERAUTH, Section 7]
password [SSH-USERAUTH, Section 8]
hostbased [SSH-USERAUTH, Section 9]
none [SSH-USERAUTH, Section 5.2]
Method Name Reference
------------ ---------
publickey [SSH-USERAUTH, Section 7]
password [SSH-USERAUTH, Section 8]
hostbased [SSH-USERAUTH, Section 9]
none [SSH-USERAUTH, Section 5.2]
The following table lists the initial assignments to the Connection Protocol Type and Request names.
下表列出了连接协议类型和请求名称的初始分配。
The following table lists the initial assignments of the Connection Protocol Channel Types.
下表列出了连接协议通道类型的初始分配。
Channel type Reference
------------ ---------
session [SSH-CONNECT, Section 6.1]
x11 [SSH-CONNECT, Section 6.3.2]
forwarded-tcpip [SSH-CONNECT, Section 7.2]
direct-tcpip [SSH-CONNECT, Section 7.2]
Channel type Reference
------------ ---------
session [SSH-CONNECT, Section 6.1]
x11 [SSH-CONNECT, Section 6.3.2]
forwarded-tcpip [SSH-CONNECT, Section 7.2]
direct-tcpip [SSH-CONNECT, Section 7.2]
The following table lists the initial assignments of the Connection Protocol Global Request Names.
下表列出了连接协议全局请求名称的初始分配。
Request type Reference
------------ ---------
tcpip-forward [SSH-CONNECT, Section 7.1]
cancel-tcpip-forward [SSH-CONNECT, Section 7.1]
Request type Reference
------------ ---------
tcpip-forward [SSH-CONNECT, Section 7.1]
cancel-tcpip-forward [SSH-CONNECT, Section 7.1]
The following table lists the initial assignments of the Connection Protocol Channel Request Names.
下表列出了连接协议通道请求名称的初始分配。
Request type Reference
------------ ---------
pty-req [SSH-CONNECT, Section 6.2]
x11-req [SSH-CONNECT, Section 6.3.1]
env [SSH-CONNECT, Section 6.4]
shell [SSH-CONNECT, Section 6.5]
exec [SSH-CONNECT, Section 6.5]
subsystem [SSH-CONNECT, Section 6.5]
window-change [SSH-CONNECT, Section 6.7]
xon-xoff [SSH-CONNECT, Section 6.8]
signal [SSH-CONNECT, Section 6.9]
exit-status [SSH-CONNECT, Section 6.10]
exit-signal [SSH-CONNECT, Section 6.10]
Request type Reference
------------ ---------
pty-req [SSH-CONNECT, Section 6.2]
x11-req [SSH-CONNECT, Section 6.3.1]
env [SSH-CONNECT, Section 6.4]
shell [SSH-CONNECT, Section 6.5]
exec [SSH-CONNECT, Section 6.5]
subsystem [SSH-CONNECT, Section 6.5]
window-change [SSH-CONNECT, Section 6.7]
xon-xoff [SSH-CONNECT, Section 6.8]
signal [SSH-CONNECT, Section 6.9]
exit-status [SSH-CONNECT, Section 6.10]
exit-signal [SSH-CONNECT, Section 6.10]
The following table lists the initial assignments of the Signal Names.
下表列出了信号名称的初始分配。
Signal Reference
------ ---------
ABRT [SSH-CONNECT]
ALRM [SSH-CONNECT]
FPE [SSH-CONNECT]
HUP [SSH-CONNECT]
ILL [SSH-CONNECT]
INT [SSH-CONNECT]
KILL [SSH-CONNECT]
PIPE [SSH-CONNECT]
QUIT [SSH-CONNECT]
SEGV [SSH-CONNECT]
TERM [SSH-CONNECT]
USR1 [SSH-CONNECT]
USR2 [SSH-CONNECT]
Signal Reference
------ ---------
ABRT [SSH-CONNECT]
ALRM [SSH-CONNECT]
FPE [SSH-CONNECT]
HUP [SSH-CONNECT]
ILL [SSH-CONNECT]
INT [SSH-CONNECT]
KILL [SSH-CONNECT]
PIPE [SSH-CONNECT]
QUIT [SSH-CONNECT]
SEGV [SSH-CONNECT]
TERM [SSH-CONNECT]
USR1 [SSH-CONNECT]
USR2 [SSH-CONNECT]
There are no initial assignments of the Connection Protocol Subsystem Names.
连接协议子系统名称没有初始分配。
The name "diffie-hellman-group1-sha1" is used for a key exchange method using an Oakley group, as defined in [RFC2409]. SSH maintains its own group identifier space, which is logically distinct from Oakley [RFC2412] and IKE; however, for one additional group, the Working Group adopted the number assigned by [RFC3526], using "diffie-hellman-group14-sha1" for the name of the second defined group. Implementations should treat these names as opaque identifiers and should not assume any relationship between the groups used by SSH and the groups defined for IKE.
名称“diffie-hellman-group1-sha1”用于使用[RFC2409]中定义的Oakley组的密钥交换方法。SSH维护自己的组标识符空间，这在逻辑上不同于Oakley[RFC2412]和IKE；然而，对于另一个组，工作组采用了[RFC3526]指定的编号，并使用“diffie-hellman-group14-sha1”作为第二个定义组的名称。实现应将这些名称视为不透明标识符，并且不应假定SSH使用的组与为IKE定义的组之间存在任何关系。
The following table identifies the initial assignments of the key exchange methods.
下表列出了密钥交换方法的初始分配。
Method name Reference
------------ ---------
diffie-hellman-group1-sha1 [SSH-TRANS, Section 8.1]
diffie-hellman-group14-sha1 [SSH-TRANS, Section 8.2]
Method name Reference
------------ ---------
diffie-hellman-group1-sha1 [SSH-TRANS, Section 8.1]
diffie-hellman-group14-sha1 [SSH-TRANS, Section 8.2]
The following table identifies the initial assignment of the Encryption Algorithm Names.
下表确定了加密算法名称的初始分配。
Encryption Algorithm Name Reference
------------------------- ---------
3des-cbc [SSH-TRANS, Section 6.3]
blowfish-cbc [SSH-TRANS, Section 6.3]
twofish256-cbc [SSH-TRANS, Section 6.3]
twofish-cbc [SSH-TRANS, Section 6.3]
twofish192-cbc [SSH-TRANS, Section 6.3]
twofish128-cbc [SSH-TRANS, Section 6.3]
aes256-cbc [SSH-TRANS, Section 6.3]
aes192-cbc [SSH-TRANS, Section 6.3]
aes128-cbc [SSH-TRANS, Section 6.3]
serpent256-cbc [SSH-TRANS, Section 6.3]
serpent192-cbc [SSH-TRANS, Section 6.3]
serpent128-cbc [SSH-TRANS, Section 6.3]
arcfour [SSH-TRANS, Section 6.3]
idea-cbc [SSH-TRANS, Section 6.3]
cast128-cbc [SSH-TRANS, Section 6.3]
none [SSH-TRANS, Section 6.3]
des-cbc [FIPS-46-3] HISTORIC; See
page 4 of [FIPS-46-3]
Encryption Algorithm Name Reference
------------------------- ---------
3des-cbc [SSH-TRANS, Section 6.3]
blowfish-cbc [SSH-TRANS, Section 6.3]
twofish256-cbc [SSH-TRANS, Section 6.3]
twofish-cbc [SSH-TRANS, Section 6.3]
twofish192-cbc [SSH-TRANS, Section 6.3]
twofish128-cbc [SSH-TRANS, Section 6.3]
aes256-cbc [SSH-TRANS, Section 6.3]
aes192-cbc [SSH-TRANS, Section 6.3]
aes128-cbc [SSH-TRANS, Section 6.3]
serpent256-cbc [SSH-TRANS, Section 6.3]
serpent192-cbc [SSH-TRANS, Section 6.3]
serpent128-cbc [SSH-TRANS, Section 6.3]
arcfour [SSH-TRANS, Section 6.3]
idea-cbc [SSH-TRANS, Section 6.3]
cast128-cbc [SSH-TRANS, Section 6.3]
none [SSH-TRANS, Section 6.3]
des-cbc [FIPS-46-3] HISTORIC; See
page 4 of [FIPS-46-3]
The following table identifies the initial assignments of the MAC Algorithm Names.
下表列出了MAC算法名称的初始分配。
MAC Algorithm Name Reference
------------------ ---------
hmac-sha1 [SSH-TRANS, Section 6.4]
hmac-sha1-96 [SSH-TRANS, Section 6.4]
hmac-md5 [SSH-TRANS, Section 6.4]
hmac-md5-96 [SSH-TRANS, Section 6.4]
none [SSH-TRANS, Section 6.4]
MAC Algorithm Name Reference
------------------ ---------
hmac-sha1 [SSH-TRANS, Section 6.4]
hmac-sha1-96 [SSH-TRANS, Section 6.4]
hmac-md5 [SSH-TRANS, Section 6.4]
hmac-md5-96 [SSH-TRANS, Section 6.4]
none [SSH-TRANS, Section 6.4]
The following table identifies the initial assignments of the Public Key Algorithm names.
下表列出了公钥算法名称的初始分配。
Public Key Algorithm Name Reference
------------------------- ---------
ssh-dss [SSH-TRANS, Section 6.6]
ssh-rsa [SSH-TRANS, Section 6.6]
pgp-sign-rsa [SSH-TRANS, Section 6.6]
pgp-sign-dss [SSH-TRANS, Section 6.6]
Public Key Algorithm Name Reference
------------------------- ---------
ssh-dss [SSH-TRANS, Section 6.6]
ssh-rsa [SSH-TRANS, Section 6.6]
pgp-sign-rsa [SSH-TRANS, Section 6.6]
pgp-sign-dss [SSH-TRANS, Section 6.6]
The following table identifies the initial assignments of the Compression Algorithm names.
下表列出了压缩算法名称的初始分配。
Compression Algorithm Name Reference
-------------------------- ---------
none [SSH-TRANS, Section 6.2]
zlib [SSH-TRANS, Section 6.2]
Compression Algorithm Name Reference
-------------------------- ---------
none [SSH-TRANS, Section 6.2]
zlib [SSH-TRANS, Section 6.2]
This protocol provides a secure encrypted channel over an insecure network.
此协议在不安全的网络上提供安全的加密通道。
Full security considerations for this protocol are provided in [SSH-ARCH].
[SSH-ARCH]中提供了此协议的完整安全注意事项。
[SSH-ARCH] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) Protocol Architecture", RFC 4251, January 2006.
[SSH-ARCH]Ylonen，T.和C.Lonvick，编辑，“安全外壳（SSH）协议架构”，RFC 4251，2006年1月。
[SSH-TRANS] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) Transport Layer Protocol", RFC 4253, January 2006.
[SSH-TRANS]Ylonen，T.和C.Lonvick，Ed.，“安全外壳（SSH）传输层协议”，RFC 4253，2006年1月。
[SSH-USERAUTH] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) Authentication Protocol", RFC 4252, January 2006.
[SSH-USERAUTH]Ylonen，T.和C.Lonvick，Ed.，“安全外壳（SSH）认证协议”，RFC 4252，2006年1月。
[SSH-CONNECT] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) Connection Protocol", RFC 4254, January 2006.
[SSH-CONNECT]Ylonen，T.和C.Lonvick，编辑，“安全外壳（SSH）连接协议”，RFC 42542006年1月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.
[RFC2409]Harkins，D.和D.Carrel，“互联网密钥交换（IKE）”，RFC 2409，1998年11月。
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[RFC2434]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 2434，1998年10月。
[RFC3526] Kivinen, T. and M. Kojo, "More Modular Exponential (MODP) Diffie-Hellman groups for Internet Key Exchange (IKE)", RFC 3526, May 2003.
[RFC3526]Kivinen，T.和M.Kojo，“互联网密钥交换（IKE）的更多模指数（MODP）Diffie-Hellman群”，RFC 3526，2003年5月。
[RFC0822] Crocker, D., "Standard for the format of ARPA Internet text messages", STD 11, RFC 822, August 1982.
[RFC0822]Crocker，D.，“ARPA互联网文本信息格式标准”，STD 11，RFC 822，1982年8月。
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987.
[RFC1034]Mockapetris，P.，“域名-概念和设施”，STD 13，RFC 1034，1987年11月。
[RFC2412] Orman, H., "The OAKLEY Key Determination Protocol", RFC 2412, November 1998.
[RFC2412]Orman，H.，“奥克利密钥确定协议”，RFC 2412，1998年11月。
[FIPS-46-3] US National Institute of Standards and Technology, "Data Encryption Standard (DES)", Federal Information Processing Standards Publication 46-3, October 1999.
[FIPS-46-3]美国国家标准与技术研究所，“数据加密标准（DES）”，联邦信息处理标准出版物46-3，1999年10月。
Authors' Addresses
作者地址
Sami Lehtinen SSH Communications Security Corp Valimotie 17 00380 Helsinki Finland
Sami Lehtinen SSH通信安全公司Valimotie 17 00380芬兰赫尔辛基
EMail: sjl@ssh.com
EMail: sjl@ssh.com
Chris Lonvick (editor) Cisco Systems, Inc. 12515 Research Blvd. Austin 78759 USA
Chris Lonvick（编辑）思科系统公司，研究大道12515号。美国奥斯汀78759
EMail: clonvick@cisco.com
EMail: clonvick@cisco.com
Trademark Notice
商标公告
"ssh" is a registered trademark in the United States and/or other countries.
“ssh”是美国和/或其他国家/地区的注册商标。
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2006).
版权所有（C）互联网协会（2006年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息是按“原样”提供的，贡献者、他/她所代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFC编辑器功能的资金由IETF行政支持活动（IASA）提供。