Network Working Group T. Ylonen
Request for Comments: 4254 SSH Communications Security Corp
Category: Standards Track C. Lonvick, Ed.
Cisco Systems, Inc.
January 2006
Network Working Group T. Ylonen
Request for Comments: 4254 SSH Communications Security Corp
Category: Standards Track C. Lonvick, Ed.
Cisco Systems, Inc.
January 2006
The Secure Shell (SSH) Connection Protocol
安全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
摘要
Secure Shell (SSH) is a protocol for secure remote login and other secure network services over an insecure network.
Secure Shell（SSH）是一种用于在不安全网络上安全远程登录和其他安全网络服务的协议。
This document describes the SSH Connection Protocol. It provides interactive login sessions, remote execution of commands, forwarded TCP/IP connections, and forwarded X11 connections. All of these channels are multiplexed into a single encrypted tunnel.
本文档介绍SSH连接协议。它提供交互式登录会话、远程执行命令、转发的TCP/IP连接和转发的X11连接。所有这些通道都被多路复用到一个加密隧道中。
The SSH Connection Protocol has been designed to run on top of the SSH transport layer and user authentication protocols.
SSH连接协议设计为在SSH传输层和用户身份验证协议之上运行。
Table of Contents
目录
1. Introduction ....................................................2
2. Contributors ....................................................3
3. Conventions Used in This Document ...............................3
4. Global Requests .................................................4
5. Channel Mechanism ...............................................5
5.1. Opening a Channel ..........................................5
5.2. Data Transfer ..............................................7
5.3. Closing a Channel ..........................................9
5.4. Channel-Specific Requests ..................................9
6. Interactive Sessions ...........................................10
6.1. Opening a Session .........................................10
6.2. Requesting a Pseudo-Terminal ..............................11
6.3. X11 Forwarding ............................................11
6.3.1. Requesting X11 Forwarding ..........................11
6.3.2. X11 Channels .......................................12
6.4. Environment Variable Passing ..............................12
6.5. Starting a Shell or a Command .............................13
6.6. Session Data Transfer .....................................14
6.7. Window Dimension Change Message ...........................14
6.8. Local Flow Control ........................................14
6.9. Signals ...................................................15
6.10. Returning Exit Status ....................................15
7. TCP/IP Port Forwarding .........................................16
7.1. Requesting Port Forwarding ................................16
7.2. TCP/IP Forwarding Channels ................................18
8. Encoding of Terminal Modes .....................................19
9. Summary of Message Numbers .....................................21
10. IANA Considerations ...........................................21
11. Security Considerations .......................................21
12. References ....................................................22
12.1. Normative References .....................................22
12.2. Informative References ...................................22
Authors' Addresses ................................................23
Trademark Notice ..................................................23
1. Introduction ....................................................2
2. Contributors ....................................................3
3. Conventions Used in This Document ...............................3
4. Global Requests .................................................4
5. Channel Mechanism ...............................................5
5.1. Opening a Channel ..........................................5
5.2. Data Transfer ..............................................7
5.3. Closing a Channel ..........................................9
5.4. Channel-Specific Requests ..................................9
6. Interactive Sessions ...........................................10
6.1. Opening a Session .........................................10
6.2. Requesting a Pseudo-Terminal ..............................11
6.3. X11 Forwarding ............................................11
6.3.1. Requesting X11 Forwarding ..........................11
6.3.2. X11 Channels .......................................12
6.4. Environment Variable Passing ..............................12
6.5. Starting a Shell or a Command .............................13
6.6. Session Data Transfer .....................................14
6.7. Window Dimension Change Message ...........................14
6.8. Local Flow Control ........................................14
6.9. Signals ...................................................15
6.10. Returning Exit Status ....................................15
7. TCP/IP Port Forwarding .........................................16
7.1. Requesting Port Forwarding ................................16
7.2. TCP/IP Forwarding Channels ................................18
8. Encoding of Terminal Modes .....................................19
9. Summary of Message Numbers .....................................21
10. IANA Considerations ...........................................21
11. Security Considerations .......................................21
12. References ....................................................22
12.1. Normative References .....................................22
12.2. Informative References ...................................22
Authors' Addresses ................................................23
Trademark Notice ..................................................23
The SSH Connection Protocol has been designed to run on top of the SSH transport layer and user authentication protocols ([SSH-TRANS] and [SSH-USERAUTH]). It provides interactive login sessions, remote execution of commands, forwarded TCP/IP connections, and forwarded X11 connections.
SSH连接协议设计为在SSH传输层和用户身份验证协议（[SSH-TRANS]和[SSH-USERAUTH]）之上运行。它提供交互式登录会话、远程执行命令、转发的TCP/IP连接和转发的X11连接。
The 'service name' for this protocol is "ssh-connection".
此协议的“服务名称”是“ssh连接”。
This document should be read only after reading the SSH architecture document [SSH-ARCH]. This document freely uses terminology and notation from the architecture document without reference or further explanation.
只有在阅读了SSH体系结构文档[SSH-ARCH]之后，才能阅读此文档。本文档免费使用架构（architecture）文档中的术语和符号，无需参考或进一步解释。
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].
当用于描述命名空间分配时，本文件中出现的关键词“私人使用”、“分层分配”、“先到先得”、“专家评审”、“所需规范”、“IESG批准”、“IETF共识”和“标准行动”应按照[RFC2434]中所述进行解释。
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”。
There are several kinds of requests that affect the state of the remote end globally, independent of any channels. An example is a request to start TCP/IP forwarding for a specific port. Note that both the client and server MAY send global requests at any time, and the receiver MUST respond appropriately. All such requests use the following format.
有几种请求会全局影响远程端的状态，与任何通道无关。例如，请求启动特定端口的TCP/IP转发。请注意，客户端和服务器都可以随时发送全局请求，并且接收方必须做出适当的响应。所有此类请求都使用以下格式。
byte SSH_MSG_GLOBAL_REQUEST
string request name in US-ASCII only
boolean want reply
.... request-specific data follows
byte SSH_MSG_GLOBAL_REQUEST
string request name in US-ASCII only
boolean want reply
.... request-specific data follows
The value of 'request name' follows the DNS extensibility naming convention outlined in [SSH-ARCH].
“请求名称”的值遵循[SSH-ARCH]中概述的DNS扩展性命名约定。
The recipient will respond to this message with SSH_MSG_REQUEST_SUCCESS or SSH_MSG_REQUEST_FAILURE if 'want reply' is TRUE.
如果'want reply'为TRUE，则收件人将使用SSH_MSG_REQUEST_SUCCESS或SSH_MSG_REQUEST_FAILURE响应此消息。
byte SSH_MSG_REQUEST_SUCCESS
.... response specific data
byte SSH_MSG_REQUEST_SUCCESS
.... response specific data
Usually, the 'response specific data' is non-existent.
通常，“响应特定数据”是不存在的。
If the recipient does not recognize or support the request, it simply responds with SSH_MSG_REQUEST_FAILURE.
如果收件人不识别或不支持该请求，它只会用SSH\u MSG\u request\u FAILURE响应。
byte SSH_MSG_REQUEST_FAILURE
字节SSH\u MSG\u请求\u失败
In general, the reply messages do not include request type identifiers. To make it possible for the originator of a request to identify to which request each reply refers, it is REQUIRED that replies to SSH_MSG_GLOBAL_REQUESTS MUST be sent in the same order as the corresponding request messages. For channel requests, replies that relate to the same channel MUST also be replied to in the right order. However, channel requests for distinct channels MAY be replied to out-of-order.
通常，回复消息不包括请求类型标识符。为了使请求的发起人能够识别每个回复所指的请求，要求对SSH_MSG_GLOBAL_请求的回复必须按照与相应请求消息相同的顺序发送。对于频道请求，与同一频道相关的回复也必须按正确的顺序进行回复。但是，针对不同通道的通道请求可能会被无序响应。
All terminal sessions, forwarded connections, etc., are channels. Either side may open a channel. Multiple channels are multiplexed into a single connection.
所有终端会话、转发连接等都是信道。任何一方都可以打开一条通道。多个通道被多路复用到单个连接中。
Channels are identified by numbers at each end. The number referring to a channel may be different on each side. Requests to open a channel contain the sender's channel number. Any other channel-related messages contain the recipient's channel number for the channel.
通道通过两端的编号进行标识。每侧的信道编号可能不同。打开频道的请求包含发件人的频道号。任何其他与频道相关的消息都包含该频道的收件人频道号。
Channels are flow-controlled. No data may be sent to a channel until a message is received to indicate that window space is available.
通道是流量控制的。在收到指示窗口空间可用的消息之前，不得向通道发送数据。
When either side wishes to open a new channel, it allocates a local number for the channel. It then sends the following message to the other side, and includes the local channel number and initial window size in the message.
当任何一方希望打开一个新频道时，它会为该频道分配一个本地号码。然后，它向另一端发送以下消息，并在消息中包含本地通道号和初始窗口大小。
byte SSH_MSG_CHANNEL_OPEN
string channel type in US-ASCII only
uint32 sender channel
uint32 initial window size
uint32 maximum packet size
.... channel type specific data follows
byte SSH_MSG_CHANNEL_OPEN
string channel type in US-ASCII only
uint32 sender channel
uint32 initial window size
uint32 maximum packet size
.... channel type specific data follows
The 'channel type' is a name, as described in [SSH-ARCH] and [SSH-NUMBERS], with similar extension mechanisms. The 'sender channel' is a local identifier for the channel used by the sender of this message. The 'initial window size' specifies how many bytes of channel data can be sent to the sender of this message without adjusting the window. The 'maximum packet size' specifies the maximum size of an individual data packet that can be sent to the sender. For example, one might want to use smaller packets for interactive connections to get better interactive response on slow links.
“通道类型”是一个名称，如[SSH-ARCH]和[SSH-NUMBERS]中所述，具有类似的扩展机制。“发件人通道”是此邮件的发件人使用的通道的本地标识符。“初始窗口大小”指定在不调整窗口的情况下可以将多少字节的通道数据发送到此消息的发送者。“最大数据包大小”指定可以发送给发送方的单个数据包的最大大小。例如，您可能希望使用较小的数据包进行交互式连接，以便在慢速链接上获得更好的交互式响应。
The remote side then decides whether it can open the channel, and responds with either SSH_MSG_CHANNEL_OPEN_CONFIRMATION or SSH_MSG_CHANNEL_OPEN_FAILURE.
然后，远程端决定是否可以打开通道，并用SSH\u MSG\u channel\u open\u确认或SSH\u MSG\u channel\u open\u失败来响应。
byte SSH_MSG_CHANNEL_OPEN_CONFIRMATION
uint32 recipient channel
uint32 sender channel
uint32 initial window size
uint32 maximum packet size
.... channel type specific data follows
byte SSH_MSG_CHANNEL_OPEN_CONFIRMATION
uint32 recipient channel
uint32 sender channel
uint32 initial window size
uint32 maximum packet size
.... channel type specific data follows
The 'recipient channel' is the channel number given in the original open request, and 'sender channel' is the channel number allocated by the other side.
“接收方通道”是原始开放请求中给出的通道号，“发送方通道”是另一方分配的通道号。
byte SSH_MSG_CHANNEL_OPEN_FAILURE uint32 recipient channel uint32 reason code string description in ISO-10646 UTF-8 encoding [RFC3629] string language tag [RFC3066]
字节SSH\u MSG\u CHANNEL\u OPEN\u故障uint32接收方通道uint32原因码字符串说明，采用ISO-10646 UTF-8编码[RFC3629]字符串语言标记[RFC3066]
If the recipient of the SSH_MSG_CHANNEL_OPEN message does not support the specified 'channel type', it simply responds with SSH_MSG_CHANNEL_OPEN_FAILURE. The client MAY show the 'description' string to the user. If this is done, the client software should take the precautions discussed in [SSH-ARCH].
如果SSH\u MSG\u CHANNEL\u OPEN消息的接收者不支持指定的“CHANNEL type”，它只会以SSH\u MSG\u CHANNEL\u OPEN\u失败作为响应。客户端可能会向用户显示“描述”字符串。如果这样做，客户端软件应该采取[SSH-ARCH]中讨论的预防措施。
The SSH_MSG_CHANNEL_OPEN_FAILURE 'reason code' values are defined in the following table. Note that the values for the 'reason code' are given in decimal format for readability, but they are actually uint32 values.
下表中定义了SSH\u MSG\u通道\u打开\u故障“原因码”值。请注意，“原因代码”的值是以十进制格式给出的，以便于阅读，但它们实际上是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
Requests for assignments of new SSH_MSG_CHANNEL_OPEN 'reason code' values (and associated 'description' text) 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 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].
如[RFC2434]所述，必须通过IETF协商一致方法，请求分配0x00000005到0xFDFFFF范围内的新SSH\u MSG\u通道\u OPEN“原因码”值（以及相关的“说明”文本）。IANA不会分配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 response will contain either a 'reason code' assigned by the IANA (as listed above and in the range of 0x00000001 to 0xFDFFFFFF) or 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 'reason code' is sent. 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 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 window size specifies how many bytes the other party can send before it must wait for the window to be adjusted. Both parties use the following message to adjust the window.
窗口大小指定另一方在必须等待窗口调整之前可以发送的字节数。双方使用以下消息调整窗口。
byte SSH_MSG_CHANNEL_WINDOW_ADJUST uint32 recipient channel uint32 bytes to add
字节SSH\u MSG\u通道\u窗口\u调整要添加的uint32收件人通道uint32字节
After receiving this message, the recipient MAY send the given number of bytes more than it was previously allowed to send; the window size is incremented. Implementations MUST correctly handle window sizes of up to 2^32 - 1 bytes. The window MUST NOT be increased above 2^32 - 1 bytes.
收到此消息后，收件人可能会发送比以前允许发送的字节数多的给定字节数；窗口大小将增加。实现必须正确处理最大为2^32-1字节的窗口大小。窗口不能增加到2^32-1字节以上。
Data transfer is done with messages of the following type.
数据传输使用以下类型的消息完成。
byte SSH_MSG_CHANNEL_DATA uint32 recipient channel string data
字节SSH\U MSG\U通道数据uint32收件人通道字符串数据
The maximum amount of data allowed is determined by the maximum packet size for the channel, and the current window size, whichever is smaller. The window size is decremented by the amount of data sent. Both parties MAY ignore all extra data sent after the allowed window is empty.
允许的最大数据量由信道的最大数据包大小和当前窗口大小决定，以较小者为准。窗口大小随发送的数据量而减小。双方可忽略允许窗口为空后发送的所有额外数据。
Implementations are expected to have some limit on the SSH transport layer packet size (any limit for received packets MUST be 32768 bytes or larger, as described in [SSH-TRANS]). The implementation of the SSH connection layer
预期实现对SSH传输层数据包大小有一些限制（如[SSH-TRANS]中所述，接收数据包的任何限制必须为32768字节或更大）。SSH连接层的实现
o MUST NOT advertise a maximum packet size that would result in transport packets larger than its transport layer is willing to receive.
o 不得公布可能导致传输数据包大于其传输层愿意接收的传输数据包的最大数据包大小。
o MUST NOT generate data packets larger than its transport layer is willing to send, even if the remote end would be willing to accept very large packets.
o 不得生成大于其传输层愿意发送的数据包，即使远程端愿意接受非常大的数据包。
Additionally, some channels can transfer several types of data. An example of this is stderr data from interactive sessions. Such data can be passed with SSH_MSG_CHANNEL_EXTENDED_DATA messages, where a separate integer specifies the type of data. The available types and their interpretation depend on the type of channel.
此外，一些通道可以传输多种类型的数据。这方面的一个例子是来自交互式会话的stderr数据。此类数据可以通过SSH_MSG_CHANNEL_EXTENDED_数据消息传递，其中一个单独的整数指定数据类型。可用类型及其解释取决于通道类型。
byte SSH_MSG_CHANNEL_EXTENDED_DATA uint32 recipient channel uint32 data_type_code string data
字节SSH\U MSG\U通道\U扩展\U数据uint32收件人通道uint32数据\U类型\U代码字符串数据
Data sent with these messages consumes the same window as ordinary data.
与这些消息一起发送的数据使用与普通数据相同的窗口。
Currently, only the following type is defined. 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]. As is noted, the actual instructions to the IANA are in [SSH-NUMBERS].
扩展通道数据传输“数据类型代码”值必须按顺序分配。必须通过[RFC2434]中所述的IETF协商一致方法，请求分配0x00000002至0xFDFFFF范围内的新扩展信道数据传输“数据类型代码”值及其相关扩展信道数据传输“数据”字符串。IANA不会分配0xFE000000到0xFFFFFF范围内的扩展通道数据传输“数据类型代码”值。如[RFC2434]所述，该范围内的扩展信道数据传输“数据类型代码”值留作私人使用。如前所述，IANA的实际指令在[SSH-NUMBERS]中。
When a party will no longer send more data to a channel, it SHOULD send SSH_MSG_CHANNEL_EOF.
当一方不再向一个通道发送更多数据时，它应该发送SSH\u MSG\u channel\u EOF。
byte SSH_MSG_CHANNEL_EOF uint32 recipient channel
uint32接收通道的字节SSH\U MSG\U通道EOU
No explicit response is sent to this message. However, the application may send EOF to whatever is at the other end of the channel. Note that the channel remains open after this message, and more data may still be sent in the other direction. This message does not consume window space and can be sent even if no window space is available.
没有对此消息发送明确的响应。但是，应用程序可能会将EOF发送到通道另一端的任何设备。请注意，此消息后通道保持打开状态，更多数据仍可能向另一个方向发送。此消息不占用窗口空间，即使没有可用的窗口空间，也可以发送此消息。
When either party wishes to terminate the channel, it sends SSH_MSG_CHANNEL_CLOSE. Upon receiving this message, a party MUST send back an SSH_MSG_CHANNEL_CLOSE unless it has already sent this message for the channel. The channel is considered closed for a party when it has both sent and received SSH_MSG_CHANNEL_CLOSE, and the party may then reuse the channel number. A party MAY send SSH_MSG_CHANNEL_CLOSE without having sent or received SSH_MSG_CHANNEL_EOF.
当任何一方希望终止通道时，它会发送SSH\u MSG\u channel\u CLOSE。收到此消息后，一方必须发回SSH_MSG_CHANNEL_CLOSE，除非它已经为该通道发送了此消息。当一方同时发送和接收SSH_MSG_channel_CLOSE时，该通道被视为已关闭，该方随后可以重用该通道号。一方可以发送SSH\u MSG\u CHANNEL\u CLOSE而不发送或接收SSH\u MSG\u CHANNEL\u EOF。
byte SSH_MSG_CHANNEL_CLOSE uint32 recipient channel
字节SSH\u MSG\u CHANNEL\u CLOSE uint32接收方通道
This message does not consume window space and can be sent even if no window space is available.
此消息不占用窗口空间，即使没有可用的窗口空间，也可以发送此消息。
It is RECOMMENDED that all data sent before this message be delivered to the actual destination, if possible.
如有可能，建议将此消息之前发送的所有数据发送到实际目的地。
Many 'channel type' values have extensions that are specific to that particular 'channel type'. An example is requesting a pty (pseudo terminal) for an interactive session.
许多“通道类型”值具有特定于该特定“通道类型”的扩展。例如，请求交互式会话的pty（伪终端）。
All channel-specific requests use the following format.
所有特定于通道的请求都使用以下格式。
byte SSH_MSG_CHANNEL_REQUEST
uint32 recipient channel
string request type in US-ASCII characters only
boolean want reply
.... type-specific data follows
byte SSH_MSG_CHANNEL_REQUEST
uint32 recipient channel
string request type in US-ASCII characters only
boolean want reply
.... type-specific data follows
If 'want reply' is FALSE, no response will be sent to the request. Otherwise, the recipient responds with either SSH_MSG_CHANNEL_SUCCESS, SSH_MSG_CHANNEL_FAILURE, or request-specific continuation messages. If the request is not recognized or is not supported for the channel, SSH_MSG_CHANNEL_FAILURE is returned.
如果“想要回复”为FALSE，则不会向请求发送响应。否则，收件人将以SSH_MSG_CHANNEL_SUCCESS、SSH_MSG_CHANNEL_FAILURE或请求特定的继续消息进行响应。如果请求未被识别或通道不支持，则返回SSH\u MSG\u channel\u FAILURE。
This message does not consume window space and can be sent even if no window space is available. The values of 'request type' are local to each channel type.
此消息不占用窗口空间，即使没有可用的窗口空间，也可以发送此消息。“请求类型”的值是每个通道类型的本地值。
The client is allowed to send further messages without waiting for the response to the request.
允许客户端在不等待请求响应的情况下发送更多消息。
'request type' names follow the DNS extensibility naming convention outlined in [SSH-ARCH] and [SSH-NUMBERS].
“请求类型”名称遵循[SSH-ARCH]和[SSH-NUMBERS]中概述的DNS扩展性命名约定。
byte SSH_MSG_CHANNEL_SUCCESS uint32 recipient channel
字节SSH\u MSG\u CHANNEL\u SUCCESS uint32接收方通道
byte SSH_MSG_CHANNEL_FAILURE uint32 recipient channel
字节SSH\u MSG\u通道故障uint32收件人通道
These messages do not consume window space and can be sent even if no window space is available.
这些消息不会占用窗口空间，即使没有可用的窗口空间，也可以发送这些消息。
A session is a remote execution of a program. The program may be a shell, an application, a system command, or some built-in subsystem. It may or may not have a tty, and may or may not involve X11 forwarding. Multiple sessions can be active simultaneously.
会话是程序的远程执行。程序可以是shell、应用程序、系统命令或某些内置子系统。它可能有也可能没有tty，可能涉及也可能不涉及X11转发。多个会话可以同时处于活动状态。
A session is started by sending the following message.
通过发送以下消息启动会话。
byte SSH_MSG_CHANNEL_OPEN string "session" uint32 sender channel uint32 initial window size uint32 maximum packet size
字节SSH\u MSG\u CHANNEL\u OPEN string“session”uint32发送方通道uint32初始窗口大小uint32最大数据包大小
Client implementations SHOULD reject any session channel open requests to make it more difficult for a corrupt server to attack the client.
客户端实现应拒绝任何会话通道打开请求，以使损坏的服务器更难攻击客户端。
A pseudo-terminal can be allocated for the session by sending the following message.
通过发送以下消息，可以为会话分配一个伪终端。
byte SSH_MSG_CHANNEL_REQUEST uint32 recipient channel string "pty-req" boolean want_reply string TERM environment variable value (e.g., vt100) uint32 terminal width, characters (e.g., 80) uint32 terminal height, rows (e.g., 24) uint32 terminal width, pixels (e.g., 640) uint32 terminal height, pixels (e.g., 480) string encoded terminal modes
字节SSH_MSG_CHANNEL_REQUEST uint32接收方通道字符串“pty req”布尔want_回复字符串术语环境变量值（例如vt100）uint32终端宽度、字符（例如80）uint32终端高度、行（例如24）uint32终端宽度、像素（例如640）uint32终端高度、像素（例如480）字符串编码终端模式
The 'encoded terminal modes' are described in Section 8. Zero dimension parameters MUST be ignored. The character/row dimensions override the pixel dimensions (when nonzero). Pixel dimensions refer to the drawable area of the window.
第8节描述了“编码终端模式”。必须忽略零维参数。字符/行尺寸替代像素尺寸（非零时）。像素尺寸指窗口的可绘制区域。
The dimension parameters are only informational.
标注参数仅供参考。
The client SHOULD ignore pty requests.
客户应忽略pty请求。
X11 forwarding may be requested for a session by sending a SSH_MSG_CHANNEL_REQUEST message.
可以通过发送SSH_MSG_CHANNEL_请求消息来请求会话的X11转发。
byte SSH_MSG_CHANNEL_REQUEST uint32 recipient channel string "x11-req" boolean want reply boolean single connection string x11 authentication protocol string x11 authentication cookie uint32 x11 screen number
字节SSH\u MSG\u CHANNEL\u REQUEST uint32接收方通道字符串“x11 req”布尔想要回复布尔单连接字符串x11身份验证协议字符串x11身份验证cookie uint32 x11屏幕号
It is RECOMMENDED that the 'x11 authentication cookie' that is sent be a fake, random cookie, and that the cookie be checked and replaced by the real cookie when a connection request is received.
建议发送的“x11身份验证cookie”是假的随机cookie，并且在收到连接请求时检查cookie并将其替换为真实cookie。
X11 connection forwarding should stop when the session channel is closed. However, already opened forwardings should not be automatically closed when the session channel is closed.
会话通道关闭时，X11连接转发应停止。但是，当会话通道关闭时，不应自动关闭已打开的转发。
If 'single connection' is TRUE, only a single connection should be forwarded. No more connections will be forwarded after the first, or after the session channel has been closed.
如果“single connection”为TRUE，则只应转发单个连接。在第一次或会话通道关闭后，将不再转发更多连接。
The 'x11 authentication protocol' is the name of the X11 authentication method used, e.g., "MIT-MAGIC-COOKIE-1".
“x11身份验证协议”是所使用的x11身份验证方法的名称，例如“MIT-MAGIC-COOKIE-1”。
The 'x11 authentication cookie' MUST be hexadecimal encoded.
“x11身份验证cookie”必须是十六进制编码的。
The X Protocol is documented in [SCHEIFLER].
X协议记录在[SCHEIFLER]中。
X11 channels are opened with a channel open request. The resulting channels are independent of the session, and closing the session channel does not close the forwarded X11 channels.
X11通道通过通道打开请求打开。结果通道独立于会话，关闭会话通道不会关闭转发的X11通道。
byte SSH_MSG_CHANNEL_OPEN string "x11" uint32 sender channel uint32 initial window size uint32 maximum packet size string originator address (e.g., "192.168.7.38") uint32 originator port
字节SSH\u MSG\u CHANNEL\u OPEN string“x11”uint32发送方通道uint32初始窗口大小uint32最大数据包大小字符串发起者地址（例如，“192.168.7.38”）uint32发起者端口
The recipient should respond with SSH_MSG_CHANNEL_OPEN_CONFIRMATION or SSH_MSG_CHANNEL_OPEN_FAILURE.
收件人应以SSH\u MSG\u CHANNEL\u OPEN\u确认或SSH\u MSG\u CHANNEL\u OPEN\u失败作为响应。
Implementations MUST reject any X11 channel open requests if they have not requested X11 forwarding.
如果未请求X11转发，则实现必须拒绝任何X11通道打开请求。
Environment variables may be passed to the shell/command to be started later. Uncontrolled setting of environment variables in a privileged process can be a security hazard. It is recommended that implementations either maintain a list of allowable variable names or only set environment variables after the server process has dropped sufficient privileges.
可以将环境变量传递给shell/命令，以便稍后启动。在特权流程中不受控制地设置环境变量可能会造成安全隐患。建议实现要么维护一个允许变量名列表，要么仅在服务器进程放弃足够权限后设置环境变量。
byte SSH_MSG_CHANNEL_REQUEST uint32 recipient channel string "env" boolean want reply string variable name string variable value
字节SSH\u MSG\u CHANNEL\u请求uint32收件人通道字符串“env”布尔值想要回复字符串变量名字符串变量值
Once the session has been set up, a program is started at the remote end. The program can be a shell, an application program, or a subsystem with a host-independent name. Only one of these requests can succeed per channel.
会话设置完成后，将在远程端启动一个程序。程序可以是shell、应用程序或具有独立于主机的名称的子系统。每个通道中只有一个请求可以成功。
byte SSH_MSG_CHANNEL_REQUEST uint32 recipient channel string "shell" boolean want reply
字节SSH\u MSG\u CHANNEL\u请求uint32收件人通道字符串“shell”布尔值想要回复
This message will request that the user's default shell (typically defined in /etc/passwd in UNIX systems) be started at the other end.
此消息将请求在另一端启动用户的默认shell（通常在UNIX系统的/etc/passwd中定义）。
byte SSH_MSG_CHANNEL_REQUEST uint32 recipient channel string "exec" boolean want reply string command
字节SSH\u MSG\u CHANNEL\u请求uint32收件人通道字符串“exec”布尔值想要回复字符串命令
This message will request that the server start the execution of the given command. The 'command' string may contain a path. Normal precautions MUST be taken to prevent the execution of unauthorized commands.
此消息将请求服务器开始执行给定命令。“命令”字符串可能包含路径。必须采取正常预防措施，防止执行未经授权的命令。
byte SSH_MSG_CHANNEL_REQUEST uint32 recipient channel string "subsystem" boolean want reply string subsystem name
字节SSH\u MSG\u CHANNEL\u请求uint32收件人通道字符串“subsystem”布尔值想要回复字符串子系统名称
This last form executes a predefined subsystem. It is expected that these will include a general file transfer mechanism, and possibly other features. Implementations may also allow configuring more such mechanisms. As the user's shell is usually used to execute the subsystem, it is advisable for the subsystem protocol to have a "magic cookie" at the beginning of the protocol transaction to distinguish it from arbitrary output generated by shell initialization scripts, etc. This spurious output from the shell may be filtered out either at the server or at the client.
最后一个表单执行预定义的子系统。预计这些将包括通用文件传输机制，以及可能的其他功能。实现还允许配置更多这样的机制。由于用户的shell通常用于执行子系统，建议子系统协议在协议事务开始时使用“魔法cookie”，以将其与shell初始化脚本生成的任意输出区分开来，外壳的这种虚假输出可以在服务器或客户端过滤掉。
The server SHOULD NOT halt the execution of the protocol stack when starting a shell or a program. All input and output from these SHOULD be redirected to the channel or to the encrypted tunnel.
启动shell或程序时，服务器不应停止协议堆栈的执行。所有的输入和输出都应该重定向到通道或加密隧道。
It is RECOMMENDED that the reply to these messages be requested and checked. The client SHOULD ignore these messages.
建议请求并检查对这些消息的回复。客户端应该忽略这些消息。
Subsystem names follow the DNS extensibility naming convention outlined in [SSH-NUMBERS].
子系统名称遵循[SSH-NUMBERS]中概述的DNS扩展性命名约定。
Data transfer for a session is done using SSH_MSG_CHANNEL_DATA and SSH_MSG_CHANNEL_EXTENDED_DATA packets and the window mechanism. The extended data type SSH_EXTENDED_DATA_STDERR has been defined for stderr data.
会话的数据传输是使用SSH_MSG_CHANNEL_数据和SSH_MSG_CHANNEL_EXTENDED_数据包以及窗口机制完成的。已为STDERR数据定义了扩展数据类型SSH_extended_data_STDERR。
When the window (terminal) size changes on the client side, it MAY send a message to the other side to inform it of the new dimensions.
当客户端上的窗口（终端）大小发生变化时，它可能会向另一端发送一条消息，通知它新的尺寸。
byte SSH_MSG_CHANNEL_REQUEST uint32 recipient channel string "window-change" boolean FALSE uint32 terminal width, columns uint32 terminal height, rows uint32 terminal width, pixels uint32 terminal height, pixels
字节SSH\u MSG\u CHANNEL\u REQUEST uint32接收方通道字符串“window change”布尔值FALSE uint32端子宽度、列uint32端子高度、行uint32端子宽度、像素uint32端子高度、像素
A response SHOULD NOT be sent to this message.
不应向此邮件发送响应。
On many systems, it is possible to determine if a pseudo-terminal is using control-S/control-Q flow control. When flow control is allowed, it is often desirable to do the flow control at the client end to speed up responses to user requests. This is facilitated by the following notification. Initially, the server is responsible for flow control. (Here, again, client means the side originating the session, and server means the other side.)
在许多系统上，可以确定伪终端是否使用control-S/control-Q流量控制。当允许流控制时，通常希望在客户端执行流控制以加快对用户请求的响应。以下通知有助于实现这一点。最初，服务器负责流控制。（这里，客户机是指发起会话的一方，服务器是指另一方。）
The message below is used by the server to inform the client when it can or cannot perform flow control (control-S/control-Q processing). If 'client can do' is TRUE, the client is allowed to do flow control using control-S and control-Q. The client MAY ignore this message.
服务器使用以下消息通知客户端何时可以或无法执行流控制（control-S/control-Q处理）。如果“客户端可以执行”为TRUE，则允许客户端使用control-S和control-Q执行流控制。客户端可以忽略此消息。
byte SSH_MSG_CHANNEL_REQUEST uint32 recipient channel string "xon-xoff" boolean FALSE boolean client can do
字节SSH\u MSG\u CHANNEL\u请求uint32收件人通道字符串“xon xoff”布尔值错误布尔值客户端可以执行
No response is sent to this message.
没有对此消息发送响应。
A signal can be delivered to the remote process/service using the following message. Some systems may not implement signals, in which case they SHOULD ignore this message.
可以使用以下消息向远程进程/服务发送信号。某些系统可能不执行信号，在这种情况下，它们应忽略此消息。
byte SSH_MSG_CHANNEL_REQUEST uint32 recipient channel string "signal" boolean FALSE string signal name (without the "SIG" prefix)
字节SSH\u MSG\u CHANNEL\u REQUEST uint32接收方通道字符串“signal”布尔值假字符串信号名称（不带“SIG”前缀）
'signal name' values will be encoded as discussed in the passage describing SSH_MSG_CHANNEL_REQUEST messages using "exit-signal" in this section.
“信号名称”值将按照本节中使用“退出信号”描述SSH\u MSG\u通道请求消息的段落中所述进行编码。
When the command running at the other end terminates, the following message can be sent to return the exit status of the command. Returning the status is RECOMMENDED. No acknowledgement is sent for this message. The channel needs to be closed with SSH_MSG_CHANNEL_CLOSE after this message.
当在另一端运行的命令终止时，可以发送以下消息以返回命令的退出状态。建议返回状态。此邮件不发送确认信息。此消息之后，需要使用SSH\u MSG\u channel\u CLOSE关闭通道。
The client MAY ignore these messages.
客户端可能会忽略这些消息。
byte SSH_MSG_CHANNEL_REQUEST uint32 recipient channel string "exit-status" boolean FALSE uint32 exit_status
字节SSH\u MSG\u通道请求uint32收件人通道字符串“退出状态”布尔值FALSE uint32退出状态
The remote command may also terminate violently due to a signal. Such a condition can be indicated by the following message. A zero 'exit_status' usually means that the command terminated successfully.
远程命令也可能因信号而剧烈终止。这种情况可通过以下消息指示。“退出状态”为零通常意味着命令成功终止。
byte SSH_MSG_CHANNEL_REQUEST uint32 recipient channel string "exit-signal" boolean FALSE string signal name (without the "SIG" prefix) boolean core dumped string error message in ISO-10646 UTF-8 encoding string language tag [RFC3066]
字节SSH\u MSG\u CHANNEL\u REQUEST uint32接收方通道字符串“exit signal”布尔错误字符串信号名称（不带“SIG”前缀）ISO-10646 UTF-8编码字符串语言标记中的布尔核心转储字符串错误消息[RFC3066]
The 'signal name' is one of the following (these are from [POSIX]).
“信号名称”是以下内容之一（来自[POSIX]）。
ABRT ALRM FPE HUP ILL INT KILL PIPE QUIT SEGV TERM USR1 USR2
ABRT ALRM FPE HUP井内压井管退出SEGV术语USR1 USR2
Additional 'signal name' values MAY be sent in the format "sig-name@xyz", where "sig-name" and "xyz" may be anything a particular implementer wants (except the "@" sign). However, it is suggested that if a 'configure' script is used, any non-standard 'signal name' values it finds be encoded as "SIG@xyz.config.guess", where "SIG" is the 'signal name' without the "SIG" prefix, and "xyz" is the host type, as determined by "config.guess".
其他“信号名称”值可以“sig”格式发送-name@xyz，其中“sig name”和“xyz”可以是特定实现者想要的任何东西（除了“@”符号）。但是，建议如果使用“配置”脚本，则发现的任何非标准“信号名称”值都应编码为“SIG@xyz.config.guess，其中“SIG”是不带“SIG”前缀的“信号名”，而“xyz”是由“config.guess”确定的主机类型。
The 'error message' contains an additional textual explanation of the error message. The message may consist of multiple lines separated by CRLF (Carriage Return - Line Feed) pairs. The client software MAY display this message to the user. If this is done, the client software should take the precautions discussed in [SSH-ARCH].
“错误消息”包含错误消息的附加文本解释。消息可能由多行组成，多行由CRLF（回车行馈送）对分隔。客户端软件可能会向用户显示此消息。如果这样做，客户端软件应该采取[SSH-ARCH]中讨论的预防措施。
A party need not explicitly request forwardings from its own end to the other direction. However, if it wishes that connections to a port on the other side be forwarded to the local side, it must explicitly request this.
一方无需明确要求从其自身端向另一方转发。但是，如果它希望将与另一端端口的连接转发到本地端，则必须明确请求。
byte SSH_MSG_GLOBAL_REQUEST string "tcpip-forward" boolean want reply string address to bind (e.g., "0.0.0.0") uint32 port number to bind
字节SSH\u MSG\u GLOBAL\u请求字符串“tcpip forward”布尔值希望回复字符串地址绑定（例如，“0.0.0.0”）uint32端口号绑定
The 'address to bind' and 'port number to bind' specify the IP address (or domain name) and port on which connections for forwarding are to be accepted. Some strings used for 'address to bind' have special-case semantics.
“要绑定的地址”和“要绑定的端口号”指定要接受转发连接的IP地址（或域名）和端口。用于“地址绑定”的某些字符串具有特殊的大小写语义。
o "" means that connections are to be accepted on all protocol families supported by the SSH implementation.
o “”表示SSH实现支持的所有协议系列都将接受连接。
o "0.0.0.0" means to listen on all IPv4 addresses.
o “0.0.0.0”表示侦听所有IPv4地址。
o "::" means to listen on all IPv6 addresses.
o “：：”表示侦听所有IPv6地址。
o "localhost" means to listen on all protocol families supported by the SSH implementation on loopback addresses only ([RFC3330] and [RFC3513]).
o “localhost”是指仅在环回地址上侦听SSH实现支持的所有协议系列（[RFC3330]和[RFC3513]）。
o "127.0.0.1" and "::1" indicate listening on the loopback interfaces for IPv4 and IPv6, respectively.
o “127.0.0.1”和“：：1”分别表示侦听IPv4和IPv6的环回接口。
Note that the client can still filter connections based on information passed in the open request.
请注意，客户端仍然可以根据打开请求中传递的信息过滤连接。
Implementations should only allow forwarding privileged ports if the user has been authenticated as a privileged user.
如果用户已作为特权用户进行身份验证，则实现应仅允许转发特权端口。
Client implementations SHOULD reject these messages; they are normally only sent by the client.
客户端实现应该拒绝这些消息；它们通常仅由客户端发送。
If a client passes 0 as port number to bind and has 'want reply' as TRUE, then the server allocates the next available unprivileged port number and replies with the following message; otherwise, there is no response-specific data.
如果客户端将0作为要绑定的端口号传递，并且“want reply”为TRUE，则服务器将分配下一个可用的非特权端口号，并使用以下消息进行回复；否则，没有响应特定的数据。
byte SSH_MSG_REQUEST_SUCCESS uint32 port that was bound on the server
字节SSH\u MSG\u REQUEST\u SUCCESS uint32服务器上绑定的端口
A port forwarding can be canceled with the following message. Note that channel open requests may be received until a reply to this message is received.
可以使用以下消息取消端口转发。请注意，在收到对此消息的回复之前，可能会收到通道打开请求。
byte SSH_MSG_GLOBAL_REQUEST string "cancel-tcpip-forward" boolean want reply string address_to_bind (e.g., "127.0.0.1") uint32 port number to bind
字节SSH\u MSG\u GLOBAL\u请求字符串“cancel tcpip forward”布尔值想要回复字符串地址\u to \u bind（例如，“127.0.0.1”）uint32端口号to bind
Client implementations SHOULD reject these messages; they are normally only sent by the client.
客户端实现应该拒绝这些消息；它们通常仅由客户端发送。
When a connection comes to a port for which remote forwarding has been requested, a channel is opened to forward the port to the other side.
当连接到请求远程转发的端口时，会打开一个通道将端口转发到另一端。
byte SSH_MSG_CHANNEL_OPEN string "forwarded-tcpip" uint32 sender channel uint32 initial window size uint32 maximum packet size string address that was connected uint32 port that was connected string originator IP address uint32 originator port
字节SSH\u MSG\u CHANNEL\u OPEN string“forwarded tcpip”uint32发送方通道uint32初始窗口大小uint32连接的最大数据包大小字符串地址uint32连接的端口是字符串发起方IP地址uint32发起方端口
Implementations MUST reject these messages unless they have previously requested a remote TCP/IP port forwarding with the given port number.
实现必须拒绝这些消息，除非它们以前使用给定的端口号请求远程TCP/IP端口转发。
When a connection comes to a locally forwarded TCP/IP port, the following packet is sent to the other side. Note that these messages MAY also be sent for ports for which no forwarding has been explicitly requested. The receiving side must decide whether to allow the forwarding.
当连接到本地转发的TCP/IP端口时，以下数据包被发送到另一端。请注意，这些消息也可以针对未明确请求转发的端口发送。接收方必须决定是否允许转发。
byte SSH_MSG_CHANNEL_OPEN string "direct-tcpip" uint32 sender channel uint32 initial window size uint32 maximum packet size string host to connect uint32 port to connect string originator IP address uint32 originator port
字节SSH\u MSG\u CHANNEL\u OPEN string“direct tcpip”uint32发送方通道uint32初始窗口大小uint32最大数据包大小字符串主机连接uint32端口连接字符串发起方IP地址uint32发起方端口
The 'host to connect' and 'port to connect' specify the TCP/IP host and port where the recipient should connect the channel. The 'host to connect' may be either a domain name or a numeric IP address.
“要连接的主机”和“要连接的端口”指定收件人应连接通道的TCP/IP主机和端口。“要连接的主机”可以是域名或数字IP地址。
The 'originator IP address' is the numeric IP address of the machine from where the connection request originates, and the 'originator port' is the port on the host from where the connection originated.
“发起人IP地址”是发起连接请求的机器的数字IP地址，“发起人端口”是发起连接的主机上的端口。
Forwarded TCP/IP channels are independent of any sessions, and closing a session channel does not in any way imply that forwarded connections should be closed.
转发的TCP/IP通道独立于任何会话，关闭会话通道并不意味着应该关闭转发的连接。
Client implementations SHOULD reject direct TCP/IP open requests for security reasons.
出于安全原因，客户端实现应拒绝直接TCP/IP开放请求。
All 'encoded terminal modes' (as passed in a pty request) are encoded into a byte stream. It is intended that the coding be portable across different environments. The stream consists of opcode-argument pairs wherein the opcode is a byte value. Opcodes 1 to 159 have a single uint32 argument. Opcodes 160 to 255 are not yet defined, and cause parsing to stop (they should only be used after any other data). The stream is terminated by opcode TTY_OP_END (0x00).
所有“编码终端模式”（在pty请求中传递）都编码到字节流中。其目的是使编码能够跨不同的环境进行移植。流由操作码参数对组成，其中操作码是字节值。操作码1到159有一个uint32参数。操作码160到255尚未定义，导致解析停止（应仅在任何其他数据之后使用）。流由操作码TTY_OP_END（0x00）终止。
The client SHOULD put any modes it knows about in the stream, and the server MAY ignore any modes it does not know about. This allows some degree of machine-independence, at least between systems that use a POSIX-like tty interface. The protocol can support other systems as well, but the client may need to fill reasonable values for a number of parameters so the server pty gets set to a reasonable mode (the server leaves all unspecified mode bits in their default values, and only some combinations make sense).
客户机应该在流中放入它知道的任何模式，而服务器可以忽略它不知道的任何模式。这允许一定程度的机器独立性，至少在使用类似POSIX的tty接口的系统之间。该协议也可以支持其他系统，但是客户端可能需要为一些参数填充合理的值，以便服务器pty被设置为合理的模式（服务器将所有未指定的模式位保留在其默认值中，并且只有一些组合才有意义）。
The naming of opcode values mostly follows the POSIX terminal mode flags. The following opcode values have been defined. Note that the values given below are in decimal format for readability, but they are actually byte values.
操作码值的命名主要遵循POSIX终端模式标志。已定义以下操作码值。请注意，为了便于阅读，下面给出的值是十进制格式，但它们实际上是字节值。
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.
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).
12 VREPRINT重新打印当前输入行。13 VWERASE删除光标左侧的一个单词。14 VLNEXT按字面意思输入下一个键入的字符，即使它是一个特殊字符15 VFLUSH字符以刷新输出。16 VSWTCH切换到不同的外壳层。17 VSTATUS打印系统状态行（加载、命令、pid等）。18 VDISCARD切换端子输出的冲洗。30忽略奇偶校验标志。如果此标志为FALSE，则参数应为0，如果为TRUE，则参数应为1。31 PARMRK标记奇偶校验和帧错误。32 INPCK启用奇偶校验错误检查。33 ISTRIP带第8位字符。34 INLCR在输入时将NL映射到CR。35 IGNCR忽略输入上的CR。36 ICRNL在输入时将CR映射到NL。37 IUCLC将大写字符转换为小写。38 IXON启用输出流量控制。39 IXANY char将在停止后重新启动。40 IXOFF启用输入流量控制。41输入队列中IMAXBEL铃声已满。50 ISIG启用信号INTR，QUIT，[D]SUSP。51关于规范化输入行。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 bit mode. 91 CS8 8 bit mode. 92 PARENB Parity enable. 93 PARODD Odd parity, else even.
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以位/秒为单位指定输出波特率。
The following is a summary of messages and their associated message number.
以下是消息及其关联消息编号的摘要。
SSH_MSG_GLOBAL_REQUEST 80 SSH_MSG_REQUEST_SUCCESS 81 SSH_MSG_REQUEST_FAILURE 82 SSH_MSG_CHANNEL_OPEN 90 SSH_MSG_CHANNEL_OPEN_CONFIRMATION 91 SSH_MSG_CHANNEL_OPEN_FAILURE 92 SSH_MSG_CHANNEL_WINDOW_ADJUST 93 SSH_MSG_CHANNEL_DATA 94 SSH_MSG_CHANNEL_EXTENDED_DATA 95 SSH_MSG_CHANNEL_EOF 96 SSH_MSG_CHANNEL_CLOSE 97 SSH_MSG_CHANNEL_REQUEST 98 SSH_MSG_CHANNEL_SUCCESS 99 SSH_MSG_CHANNEL_FAILURE 100
SSH\u MSG\u全局请求80 SSH\u MSG\u请求成功81 SSH\u MSG\u请求失败82 SSH\u MSG\u通道打开90 SSH\u MSG\u通道打开确认91 SSH\u MSG\u通道打开故障92 SSH\u MSG\u通道窗口调整93 SSH\u MSG\u通道数据94 SSH\u MSG\u通道扩展数据95 SSH\u MSG\u通道关闭96 SSH\u MSG\u通道请求98SSH\u MSG\u CHANNEL\u成功99 SSH\u MSG\u CHANNEL\u失败100
This document is part of a set. The IANA considerations for the SSH protocol as defined in [SSH-ARCH], [SSH-TRANS], [SSH-USERAUTH], and this document, are detailed in [SSH-NUMBERS].
本文件是一套文件的一部分。[SSH-ARCH]、[SSH-TRANS]、[SSH-USERAUTH]和本文档中定义的SSH协议的IANA注意事项在[SSH-NUMBERS]中有详细说明。
This protocol is assumed to run on top of a secure, authenticated transport. User authentication and protection against network-level attacks are assumed to be provided by the underlying protocols.
假定此协议在安全、经过身份验证的传输上运行。用户身份验证和网络级攻击防护假定由底层协议提供。
Full security considerations for this protocol are provided in [SSH-ARCH]. Specific to this document, it is RECOMMENDED that implementations disable all the potentially dangerous features (e.g., agent forwarding, X11 forwarding, and TCP/IP forwarding) if the host key has changed without notice or explanation.
[SSH-ARCH]中提供了此协议的完整安全注意事项。针对本文档，如果主机密钥在未经通知或解释的情况下更改，建议实施禁用所有潜在危险的功能（例如，代理转发、X11转发和TCP/IP转发）。
[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-NUMBERS] Lehtinen, S. and C. Lonvick, Ed., "The Secure Shell (SSH) Protocol Assigned Numbers", RFC 4250, January 2006.
[SSH-NUMBERS]Lehtinen，S.和C.Lonvick，Ed.，“安全外壳（SSH）协议分配编号”，RFC 4250，2006年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月。
[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月。
[RFC3066] Alvestrand, H., "Tags for the Identification of Languages", BCP 47, RFC 3066, January 2001.
[RFC3066]Alvestrand，H.，“语言识别标签”，BCP 47，RFC 3066，2001年1月。
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.
[RFC3629]Yergeau，F.，“UTF-8，ISO 10646的转换格式”，STD 63，RFC 3629，2003年11月。
[RFC3330] IANA, "Special-Use IPv4 Addresses", RFC 3330, September 2002.
[RFC3330]IANA，“特殊用途IPv4地址”，RFC33302002年9月。
[RFC3513] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6) Addressing Architecture", RFC 3513, April 2003.
[RFC3513]Hinden，R.和S.Deering，“互联网协议版本6（IPv6）寻址体系结构”，RFC 3513，2003年4月。
[SCHEIFLER] Scheifler, R., "X Window System : The Complete Reference to Xlib, X Protocol, Icccm, Xlfd, 3rd edition.", Digital Press ISBN 1555580882, February 1992.
[SCHEIFLER]SCHEIFLER，R.，“X窗口系统：Xlib的完整参考，X协议，Icccm，Xlfd，第三版”，数字出版社ISBN 1555580882，1992年2月。
[POSIX] ISO/IEC, 9945-1., "Information technology -- Portable Operating System Interface (POSIX)-Part 1: System Application Program Interface (API) C Language", ANSI/ IEE Std 1003.1, July 1996.
[POSIX]ISO/IEC，9945-1.，“信息技术——便携式操作系统接口（POSIX）——第1部分：系统应用程序接口（API）C语言”，ANSI/IEE Std 1003.11996年7月。
Authors' Addresses
作者地址
Tatu Ylonen SSH Communications Security Corp Valimotie 17 00380 Helsinki Finland
芬兰赫尔辛基塔图伊洛宁SSH通信安全公司Valimotie 17 00380
EMail: ylo@ssh.com
EMail: ylo@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）提供。