Network Working Group T. Ylonen
Request for Comments: 4251 SSH Communications Security Corp
Category: Standards Track C. Lonvick, Ed.
Cisco Systems, Inc.
January 2006
Network Working Group T. Ylonen
Request for Comments: 4251 SSH Communications Security Corp
Category: Standards Track C. Lonvick, Ed.
Cisco Systems, Inc.
January 2006
The Secure Shell (SSH) Protocol Architecture
安全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
摘要
The Secure Shell (SSH) Protocol is a protocol for secure remote login and other secure network services over an insecure network. This document describes the architecture of the SSH protocol, as well as the notation and terminology used in SSH protocol documents. It also discusses the SSH algorithm naming system that allows local extensions. The SSH protocol consists of three major components: The Transport Layer Protocol provides server authentication, confidentiality, and integrity with perfect forward secrecy. The User Authentication Protocol authenticates the client to the server. The Connection Protocol multiplexes the encrypted tunnel into several logical channels. Details of these protocols are described in separate documents.
Secure Shell（SSH）协议是一种用于在不安全网络上安全远程登录和其他安全网络服务的协议。本文档描述了SSH协议的体系结构，以及SSH协议文档中使用的符号和术语。它还讨论了允许本地扩展的SSH算法命名系统。SSH协议由三个主要组件组成：传输层协议提供服务器身份验证、机密性和完整性以及完美的前向保密性。用户身份验证协议向服务器验证客户端。连接协议将加密隧道多路复用到多个逻辑通道中。这些协议的细节在单独的文件中描述。
Table of Contents
目录
1. Introduction ....................................................3
2. Contributors ....................................................3
3. Conventions Used in This Document ...............................4
4. Architecture ....................................................4
4.1. Host Keys ..................................................4
4.2. Extensibility ..............................................6
4.3. Policy Issues ..............................................6
4.4. Security Properties ........................................7
4.5. Localization and Character Set Support .....................7
5. Data Type Representations Used in the SSH Protocols .............8
6. Algorithm and Method Naming ....................................10
7. Message Numbers ................................................11
8. IANA Considerations ............................................12
9. Security Considerations ........................................13
9.1. Pseudo-Random Number Generation ...........................13
9.2. Control Character Filtering ...............................14
9.3. Transport .................................................14
9.3.1. Confidentiality ....................................14
9.3.2. Data Integrity .....................................16
9.3.3. Replay .............................................16
9.3.4. Man-in-the-middle ..................................17
9.3.5. Denial of Service ..................................19
9.3.6. Covert Channels ....................................20
9.3.7. Forward Secrecy ....................................20
9.3.8. Ordering of Key Exchange Methods ...................20
9.3.9. Traffic Analysis ...................................21
9.4. Authentication Protocol ...................................21
9.4.1. Weak Transport .....................................21
9.4.2. Debug Messages .....................................22
9.4.3. Local Security Policy ..............................22
9.4.4. Public Key Authentication ..........................23
9.4.5. Password Authentication ............................23
9.4.6. Host-Based Authentication ..........................23
9.5. Connection Protocol .......................................24
9.5.1. End Point Security .................................24
9.5.2. Proxy Forwarding ...................................24
9.5.3. X11 Forwarding .....................................24
10. References ....................................................26
10.1. Normative References .....................................26
10.2. Informative References ...................................26
Authors' Addresses ................................................29
Trademark Notice ..................................................29
1. Introduction ....................................................3
2. Contributors ....................................................3
3. Conventions Used in This Document ...............................4
4. Architecture ....................................................4
4.1. Host Keys ..................................................4
4.2. Extensibility ..............................................6
4.3. Policy Issues ..............................................6
4.4. Security Properties ........................................7
4.5. Localization and Character Set Support .....................7
5. Data Type Representations Used in the SSH Protocols .............8
6. Algorithm and Method Naming ....................................10
7. Message Numbers ................................................11
8. IANA Considerations ............................................12
9. Security Considerations ........................................13
9.1. Pseudo-Random Number Generation ...........................13
9.2. Control Character Filtering ...............................14
9.3. Transport .................................................14
9.3.1. Confidentiality ....................................14
9.3.2. Data Integrity .....................................16
9.3.3. Replay .............................................16
9.3.4. Man-in-the-middle ..................................17
9.3.5. Denial of Service ..................................19
9.3.6. Covert Channels ....................................20
9.3.7. Forward Secrecy ....................................20
9.3.8. Ordering of Key Exchange Methods ...................20
9.3.9. Traffic Analysis ...................................21
9.4. Authentication Protocol ...................................21
9.4.1. Weak Transport .....................................21
9.4.2. Debug Messages .....................................22
9.4.3. Local Security Policy ..............................22
9.4.4. Public Key Authentication ..........................23
9.4.5. Password Authentication ............................23
9.4.6. Host-Based Authentication ..........................23
9.5. Connection Protocol .......................................24
9.5.1. End Point Security .................................24
9.5.2. Proxy Forwarding ...................................24
9.5.3. X11 Forwarding .....................................24
10. References ....................................................26
10.1. Normative References .....................................26
10.2. Informative References ...................................26
Authors' Addresses ................................................29
Trademark Notice ..................................................29
Secure Shell (SSH) is a protocol for secure remote login and other secure network services over an insecure network. It consists of three major components:
Secure Shell（SSH）是一种用于在不安全网络上安全远程登录和其他安全网络服务的协议。它由三个主要部分组成：
o The Transport Layer Protocol [SSH-TRANS] provides server authentication, confidentiality, and integrity. It may optionally also provide compression. The transport layer will typically be run over a TCP/IP connection, but might also be used on top of any other reliable data stream.
o 传输层协议[SSH-TRANS]提供服务器身份验证、机密性和完整性。它还可以选择性地提供压缩。传输层通常通过TCP/IP连接运行，但也可以在任何其他可靠数据流之上使用。
o The User Authentication Protocol [SSH-USERAUTH] authenticates the client-side user to the server. It runs over the transport layer protocol.
o 用户身份验证协议[SSH-USERAUTH]向服务器验证客户端用户。它通过传输层协议运行。
o The Connection Protocol [SSH-CONNECT] multiplexes the encrypted tunnel into several logical channels. It runs over the user authentication protocol.
o 连接协议[SSH-CONNECT]将加密隧道多路复用到多个逻辑通道中。它通过用户身份验证协议运行。
The client sends a service request once a secure transport layer connection has been established. A second service request is sent after user authentication is complete. This allows new protocols to be defined and coexist with the protocols listed above.
一旦建立了安全传输层连接，客户端就会发送服务请求。第二个服务请求在用户身份验证完成后发送。这允许定义新协议并与上面列出的协议共存。
The connection protocol provides channels that can be used for a wide range of purposes. Standard methods are provided for setting up secure interactive shell sessions and for forwarding ("tunneling") arbitrary TCP/IP ports and X11 connections.
连接协议提供了可用于多种用途的通道。提供了用于设置安全交互式shell会话和转发（“隧道”）任意TCP/IP端口和X11连接的标准方法。
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”。
Each server host SHOULD have a host key. Hosts MAY have multiple host keys using multiple different algorithms. Multiple hosts MAY share the same host key. If a host has keys at all, it MUST have at least one key that uses each REQUIRED public key algorithm (DSS [FIPS-186-2]).
每个服务器主机都应该有一个主机密钥。主机可能使用多个不同的算法具有多个主机密钥。多台主机可能共享同一主机密钥。如果主机有密钥，则必须至少有一个密钥使用每个必需的公钥算法（DSS[FIPS-186-2]）。
The server host key is used during key exchange to verify that the client is really talking to the correct server. For this to be possible, the client must have a priori knowledge of the server's public host key.
服务器主机密钥在密钥交换期间用于验证客户端是否真的在与正确的服务器通信。要做到这一点，客户机必须事先知道服务器的公共主机密钥。
Two different trust models can be used:
可以使用两种不同的信任模型：
o The client has a local database that associates each host name (as typed by the user) with the corresponding public host key. This method requires no centrally administered infrastructure, and no
o 客户端有一个本地数据库，该数据库将每个主机名（由用户键入）与相应的公共主机密钥相关联。此方法不需要集中管理的基础架构，也不需要
third-party coordination. The downside is that the database of name-to-key associations may become burdensome to maintain.
第三方协调。缺点是，从名称到关键关联的数据库可能变得难以维护。
o The host name-to-key association is certified by a trusted certification authority (CA). The client only knows the CA root key, and can verify the validity of all host keys certified by accepted CAs.
o 主机名到密钥关联由可信证书颁发机构（CA）认证。客户端只知道CA根密钥，并且可以验证由接受的CA认证的所有主机密钥的有效性。
The second alternative eases the maintenance problem, since ideally only a single CA key needs to be securely stored on the client. On the other hand, each host key must be appropriately certified by a central authority before authorization is possible. Also, a lot of trust is placed on the central infrastructure.
第二种方法简化了维护问题，因为在理想情况下，客户机上只需要安全地存储一个CA密钥。另一方面，每个主机密钥必须经过中央机构的适当认证，才能进行授权。此外，对中央基础设施的信任度也很高。
The protocol provides the option that the server name - host key association is not checked when connecting to the host for the first time. This allows communication without prior communication of host keys or certification. The connection still provides protection against passive listening; however, it becomes vulnerable to active man-in-the-middle attacks. Implementations SHOULD NOT normally allow such connections by default, as they pose a potential security problem. However, as there is no widely deployed key infrastructure available on the Internet at the time of this writing, this option makes the protocol much more usable during the transition time until such an infrastructure emerges, while still providing a much higher level of security than that offered by older solutions (e.g., telnet [RFC0854] and rlogin [RFC1282]).
该协议提供了一个选项，即首次连接到主机时不检查服务器名称-主机密钥关联。这允许在没有主机密钥或认证的情况下进行通信。该连接仍能防止被动监听；然而，它变得容易受到中间人主动攻击。默认情况下，实现通常不允许这种连接，因为它们会带来潜在的安全问题。然而，由于在撰写本文时，互联网上没有广泛部署的关键基础设施，因此该选项使协议在过渡期间更加可用，直到出现此类基础设施，同时仍然提供比旧解决方案（例如telnet[RFC0854]）更高级别的安全性和rlogin[RFC1282]）。
Implementations SHOULD try to make the best effort to check host keys. An example of a possible strategy is to only accept a host key without checking the first time a host is connected, save the key in a local database, and compare against that key on all future connections to that host.
实现应该尽最大努力检查主机密钥。一个可能的策略示例是，只接受主机密钥而不检查主机第一次连接时，将该密钥保存在本地数据库中，并在将来与该主机的所有连接上与该密钥进行比较。
Implementations MAY provide additional methods for verifying the correctness of host keys, e.g., a hexadecimal fingerprint derived from the SHA-1 hash [FIPS-180-2] of the public key. Such fingerprints can easily be verified by using telephone or other external communication channels.
实现可提供用于验证主机密钥的正确性的附加方法，例如，从公钥的SHA-1散列[FIPS-180-2]导出的十六进制指纹。这种指纹可以通过电话或其他外部通信渠道轻松验证。
All implementations SHOULD provide an option not to accept host keys that cannot be verified.
所有实现都应该提供一个选项，不接受无法验证的主机密钥。
The members of this Working Group believe that 'ease of use' is critical to end-user acceptance of security solutions, and no improvement in security is gained if the new solutions are not used. Thus, providing the option not to check the server host key is
该工作组的成员认为，“易用性”对于最终用户接受安全解决方案至关重要，如果不使用新的解决方案，安全性不会得到任何改善。因此，不需要提供不检查服务器主机密钥的选项
believed to improve the overall security of the Internet, even though it reduces the security of the protocol in configurations where it is allowed.
被认为可以提高互联网的整体安全性，即使在允许的配置中它会降低协议的安全性。
We believe that the protocol will evolve over time, and some organizations will want to use their own encryption, authentication, and/or key exchange methods. Central registration of all extensions is cumbersome, especially for experimental or classified features. On the other hand, having no central registration leads to conflicts in method identifiers, making interoperability difficult.
我们相信该协议将随着时间的推移而发展，一些组织将希望使用自己的加密、身份验证和/或密钥交换方法。所有扩展的中心注册都很麻烦，特别是对于实验或分类功能。另一方面，没有中央注册会导致方法标识符中的冲突，从而使互操作性变得困难。
We have chosen to identify algorithms, methods, formats, and extension protocols with textual names that are of a specific format. DNS names are used to create local namespaces where experimental or classified extensions can be defined without fear of conflicts with other implementations.
我们选择使用特定格式的文本名称来识别算法、方法、格式和扩展协议。DNS名称用于创建本地名称空间，可以在其中定义实验或分类扩展，而无需担心与其他实现冲突。
One design goal has been to keep the base protocol as simple as possible, and to require as few algorithms as possible. However, all implementations MUST support a minimal set of algorithms to ensure interoperability (this does not imply that the local policy on all hosts would necessarily allow these algorithms). The mandatory algorithms are specified in the relevant protocol documents.
一个设计目标是使基本协议尽可能简单，并要求尽可能少的算法。但是，所有实现都必须支持一组最小的算法以确保互操作性（这并不意味着所有主机上的本地策略都必须允许这些算法）。相关协议文件中规定了强制算法。
Additional algorithms, methods, formats, and extension protocols can be defined in separate documents. See Section 6, Algorithm Naming, for more information.
其他算法、方法、格式和扩展协议可以在单独的文档中定义。有关更多信息，请参见第6节“算法命名”。
The protocol allows full negotiation of encryption, integrity, key exchange, compression, and public key algorithms and formats. Encryption, integrity, public key, and compression algorithms can be different for each direction.
该协议允许对加密、完整性、密钥交换、压缩以及公钥算法和格式进行全面协商。每个方向的加密、完整性、公钥和压缩算法可能不同。
The following policy issues SHOULD be addressed in the configuration mechanisms of each implementation:
应在每个实施的配置机制中解决以下政策问题：
o Encryption, integrity, and compression algorithms, separately for each direction. The policy MUST specify which is the preferred algorithm (e.g., the first algorithm listed in each category).
o 加密、完整性和压缩算法，分别针对每个方向。策略必须指定首选算法（例如，每个类别中列出的第一个算法）。
o Public key algorithms and key exchange method to be used for host authentication. The existence of trusted host keys for different public key algorithms also affects this choice.
o 用于主机身份验证的公钥算法和密钥交换方法。不同公钥算法的可信主机密钥的存在也会影响这种选择。
o The authentication methods that are to be required by the server for each user. The server's policy MAY require multiple authentication for some or all users. The required algorithms MAY depend on the location from where the user is trying to gain access.
o 服务器为每个用户所需的身份验证方法。服务器的策略可能需要对部分或所有用户进行多次身份验证。所需的算法可能取决于用户试图访问的位置。
o The operations that the user is allowed to perform using the connection protocol. Some issues are related to security; for example, the policy SHOULD NOT allow the server to start sessions or run commands on the client machine, and MUST NOT allow connections to the authentication agent unless forwarding such connections has been requested. Other issues, such as which TCP/IP ports can be forwarded and by whom, are clearly issues of local policy. Many of these issues may involve traversing or bypassing firewalls, and are interrelated with the local security policy.
o 允许用户使用连接协议执行的操作。一些问题与安全有关；例如，策略不应允许服务器在客户端计算机上启动会话或运行命令，并且不得允许连接到身份验证代理，除非已请求转发此类连接。其他问题，例如哪些TCP/IP端口可以转发以及由谁转发，显然是本地政策的问题。其中许多问题可能涉及穿越或绕过防火墙，并且与本地安全策略相关。
The primary goal of the SSH protocol is to improve security on the Internet. It attempts to do this in a way that is easy to deploy, even at the cost of absolute security.
SSH协议的主要目标是提高Internet上的安全性。它试图以一种易于部署的方式实现这一点，即使以绝对安全性为代价。
o All encryption, integrity, and public key algorithms used are well-known, well-established algorithms.
o 使用的所有加密、完整性和公钥算法都是众所周知的、成熟的算法。
o All algorithms are used with cryptographically sound key sizes that are believed to provide protection against even the strongest cryptanalytic attacks for decades.
o 所有算法都与加密的声音密钥大小一起使用，这些密钥被认为可以提供保护，抵御几十年来最强大的密码分析攻击。
o All algorithms are negotiated, and in case some algorithm is broken, it is easy to switch to some other algorithm without modifying the base protocol.
o 所有算法都经过协商，如果某个算法被破坏，则可以很容易地切换到其他算法，而无需修改基本协议。
Specific concessions were made to make widespread, fast deployment easier. The particular case where this comes up is verifying that the server host key really belongs to the desired host; the protocol allows the verification to be left out, but this is NOT RECOMMENDED. This is believed to significantly improve usability in the short term, until widespread Internet public key infrastructures emerge.
作出了具体的让步，以便更容易地进行广泛、快速的部署。出现这种情况的特殊情况是验证服务器主机密钥确实属于所需主机；协议允许省略验证，但不建议这样做。这被认为可以在短期内显著提高可用性，直到出现广泛的互联网公钥基础设施。
For the most part, the SSH protocols do not directly pass text that would be displayed to the user. However, there are some places where such data might be passed. When applicable, the character set for
在大多数情况下，SSH协议不会直接将显示的文本传递给用户。但是，有些地方可能会传递此类数据。如果适用，则为的字符集
the data MUST be explicitly specified. In most places, ISO-10646 UTF-8 encoding is used [RFC3629]. When applicable, a field is also provided for a language tag [RFC3066].
必须明确指定数据。在大多数地方，使用ISO-10646 UTF-8编码[RFC3629]。如果适用，还为语言标记[RFC3066]提供了一个字段。
One big issue is the character set of the interactive session. There is no clear solution, as different applications may display data in different formats. Different types of terminal emulation may also be employed in the client, and the character set to be used is effectively determined by the terminal emulation. Thus, no place is provided for directly specifying the character set or encoding for terminal session data. However, the terminal emulation type (e.g., "vt100") is transmitted to the remote site, and it implicitly specifies the character set and encoding. Applications typically use the terminal type to determine what character set they use, or the character set is determined using some external means. The terminal emulation may also allow configuring the default character set. In any case, the character set for the terminal session is considered primarily a client local issue.
一个大问题是交互式会话的角色集。没有明确的解决方案，因为不同的应用程序可能以不同的格式显示数据。客户端中还可以使用不同类型的终端仿真，并且要使用的字符集由终端仿真有效地确定。因此，没有提供用于直接指定终端会话数据的字符集或编码的位置。然而，终端仿真类型（例如，“vt100”）被传输到远程站点，并且它隐式地指定了字符集和编码。应用程序通常使用终端类型来确定它们使用的字符集，或者使用一些外部手段来确定字符集。终端仿真还允许配置默认字符集。在任何情况下，终端会话的字符集主要被视为客户端本地问题。
Internal names used to identify algorithms or protocols are normally never displayed to users, and must be in US-ASCII.
用于识别算法或协议的内部名称通常不会显示给用户，并且必须使用US-ASCII。
The client and server user names are inherently constrained by what the server is prepared to accept. They might, however, occasionally be displayed in logs, reports, etc. They MUST be encoded using ISO 10646 UTF-8, but other encodings may be required in some cases. It is up to the server to decide how to map user names to accepted user names. Straight bit-wise, binary comparison is RECOMMENDED.
客户端和服务器用户名本质上受到服务器准备接受的内容的限制。但是，它们有时可能会显示在日志、报告等中。它们必须使用ISO10646 UTF-8编码，但在某些情况下可能需要其他编码。由服务器决定如何将用户名映射到已接受的用户名。建议直接进行二进制比较。
For localization purposes, the protocol attempts to minimize the number of textual messages transmitted. When present, such messages typically relate to errors, debugging information, or some externally configured data. For data that is normally displayed, it SHOULD be possible to fetch a localized message instead of the transmitted message by using a numerical code. The remaining messages SHOULD be configurable.
出于本地化的目的，该协议试图最小化传输的文本消息的数量。当存在时，此类消息通常与错误、调试信息或某些外部配置的数据有关。对于正常显示的数据，应该可以使用数字代码获取本地化消息，而不是传输的消息。其余的消息应该是可配置的。
byte
字节
A byte represents an arbitrary 8-bit value (octet). Fixed length data is sometimes represented as an array of bytes, written byte[n], where n is the number of bytes in the array.
字节表示任意8位值（八位字节）。固定长度数据有时表示为字节数组，即写入字节[n]，其中n是数组中的字节数。
boolean
布尔值
A boolean value is stored as a single byte. The value 0 represents FALSE, and the value 1 represents TRUE. All non-zero values MUST be interpreted as TRUE; however, applications MUST NOT store values other than 0 and 1.
布尔值存储为单个字节。值0表示FALSE，值1表示TRUE。所有非零值必须解释为真；但是，应用程序不能存储0和1以外的值。
uint32
uint32
Represents a 32-bit unsigned integer. Stored as four bytes in the order of decreasing significance (network byte order). For example: the value 699921578 (0x29b7f4aa) is stored as 29 b7 f4 aa.
表示32位无符号整数。按重要性递减顺序（网络字节顺序）存储为四个字节。例如：值699921578（0x29b7f4aa）存储为29 b7 f4 aa。
uint64
uint64
Represents a 64-bit unsigned integer. Stored as eight bytes in the order of decreasing significance (network byte order).
表示64位无符号整数。按重要性递减顺序（网络字节顺序）存储为八个字节。
string
一串
Arbitrary length binary string. Strings are allowed to contain arbitrary binary data, including null characters and 8-bit characters. They are stored as a uint32 containing its length (number of bytes that follow) and zero (= empty string) or more bytes that are the value of the string. Terminating null characters are not used.
任意长度的二进制字符串。字符串允许包含任意二进制数据，包括空字符和8位字符。它们存储为uint32，其中包含其长度（后面的字节数）和零（=空字符串）或更多字节，这些字节是字符串的值。不使用终止空字符。
Strings are also used to store text. In that case, US-ASCII is used for internal names, and ISO-10646 UTF-8 for text that might be displayed to the user. The terminating null character SHOULD NOT normally be stored in the string. For example: the US-ASCII string "testing" is represented as 00 00 00 07 t e s t i n g. The UTF-8 mapping does not alter the encoding of US-ASCII characters.
字符串也用于存储文本。在这种情况下，US-ASCII用于内部名称，ISO-10646 UTF-8用于可能显示给用户的文本。终止的空字符通常不应存储在字符串中。例如：US-ASCII字符串“testing”表示为00 07 t e s t i n g。UTF-8映射不会改变US-ASCII字符的编码。
mpint
mpint
Represents multiple precision integers in two's complement format, stored as a string, 8 bits per byte, MSB first. Negative numbers have the value 1 as the most significant bit of the first byte of the data partition. If the most significant bit would be set for a positive number, the number MUST be preceded by a zero byte. Unnecessary leading bytes with the value 0 or 255 MUST NOT be included. The value zero MUST be stored as a string with zero bytes of data.
以2的补码格式表示多个精度整数，存储为字符串，每个字节8位，MSB优先。负数的值1是数据分区第一个字节的最高有效位。如果将最高有效位设置为正数，则该数字前面必须有一个零字节。不得包含值为0或255的不必要的前导字节。值0必须存储为数据字节为零的字符串。
By convention, a number that is used in modular computations in Z_n SHOULD be represented in the range 0 <= x < n.
按照惯例，Z_n中模块计算中使用的数字应在0<=x<n的范围内表示。
Examples:
示例：
value (hex) representation (hex)
----------- --------------------
0 00 00 00 00
9a378f9b2e332a7 00 00 00 08 09 a3 78 f9 b2 e3 32 a7
80 00 00 00 02 00 80
-1234 00 00 00 02 ed cc
-deadbeef 00 00 00 05 ff 21 52 41 11
value (hex) representation (hex)
----------- --------------------
0 00 00 00 00
9a378f9b2e332a7 00 00 00 08 09 a3 78 f9 b2 e3 32 a7
80 00 00 00 02 00 80
-1234 00 00 00 02 ed cc
-deadbeef 00 00 00 05 ff 21 52 41 11
name-list
名单
A string containing a comma-separated list of names. A name-list is represented as a uint32 containing its length (number of bytes that follow) followed by a comma-separated list of zero or more names. A name MUST have a non-zero length, and it MUST NOT contain a comma (","). As this is a list of names, all of the elements contained are names and MUST be in US-ASCII. Context may impose additional restrictions on the names. For example, the names in a name-list may have to be a list of valid algorithm identifiers (see Section 6 below), or a list of [RFC3066] language tags. The order of the names in a name-list may or may not be significant. Again, this depends on the context in which the list is used. Terminating null characters MUST NOT be used, neither for the individual names, nor for the list as a whole.
包含以逗号分隔的名称列表的字符串。名称列表表示为uint32，包含其长度（后面的字节数），后跟以逗号分隔的零个或多个名称列表。名称的长度必须非零，且不得包含逗号（“，”）。因为这是一个名称列表，所以包含的所有元素都是名称，并且必须使用US-ASCII。上下文可能会对名称施加额外的限制。例如，名称列表中的名称可能必须是有效算法标识符列表（见下文第6节）或[RFC3066]语言标记列表。姓名列表中姓名的顺序可能重要，也可能不重要。同样，这取决于使用列表的上下文。无论是单个名称还是整个列表，都不能使用终止空字符。
Examples:
示例：
value representation (hex)
----- --------------------
(), the empty name-list 00 00 00 00
("zlib") 00 00 00 04 7a 6c 69 62
("zlib,none") 00 00 00 09 7a 6c 69 62 2c 6e 6f 6e 65
value representation (hex)
----- --------------------
(), the empty name-list 00 00 00 00
("zlib") 00 00 00 04 7a 6c 69 62
("zlib,none") 00 00 00 09 7a 6c 69 62 2c 6e 6f 6e 65
The SSH protocols refer to particular hash, encryption, integrity, compression, and key exchange algorithms or methods by name. There are some standard algorithms and methods that all implementations MUST support. There are also algorithms and methods that are defined in the protocol specification, but are OPTIONAL. Furthermore, it is expected that some organizations will want to use their own algorithms or methods.
SSH协议按名称引用特定的哈希、加密、完整性、压缩和密钥交换算法或方法。所有实现都必须支持一些标准算法和方法。协议规范中还定义了一些算法和方法，但这些算法和方法是可选的。此外，预计一些组织会希望使用自己的算法或方法。
In this protocol, all algorithm and method identifiers MUST be printable US-ASCII, non-empty strings no longer than 64 characters. Names MUST be case-sensitive.
在此协议中，所有算法和方法标识符必须是可打印的US-ASCII非空字符串，长度不超过64个字符。名称必须区分大小写。
There are two formats for algorithm and method names:
算法和方法名称有两种格式：
o Names that do not contain an at-sign ("@") are reserved to be assigned by IETF CONSENSUS. Examples include "3des-cbc", "sha-1", "hmac-sha1", and "zlib" (the doublequotes are not part of the name). Names of this format are only valid if they are first registered with the IANA. Registered names MUST NOT contain an 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.
o 不包含at符号（“@”）的名称保留由IETF协商一致分配。示例包括“3des cbc”、“sha-1”、“hmac-sha1”和“zlib”（双引号不是名称的一部分）。此格式的名称仅在首次向IANA注册时有效。注册名称不得包含at符号（@）、逗号（“，”）、空格、控制字符（ASCII代码32或更少）或ASCII代码127（DEL）。名称区分大小写，长度不得超过64个字符。
o Anyone can define additional algorithms or methods by using names in the format name@domainname, e.g., "ourcipher-cbc@example.com". 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 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 should be noted that these names resemble STD 11 [RFC0822] email addresses. This is purely coincidental and has nothing to do with STD 11 [RFC0822].
o 任何人都可以通过使用格式中的名称来定义其他算法或方法name@domainname，例如，“我们的密码”-cbc@example.com". 未规定at标志前面部分的格式；但是，这些名称必须是可打印的US-ASCII字符串，并且不得包含逗号字符（“，”）、空格、控制字符（ASCII代码32或更少）或ASCII代码127（DEL）。他们必须只有一个at标志。at符号后面的部分必须是由定义名称的个人或组织控制的有效、完全限定的域名[RFC1034]。名称区分大小写，长度不得超过64个字符。如何管理其本地名称空间取决于每个域。应注意，这些名称类似于STD 11[RFC0822]电子邮件地址。这纯粹是巧合，与STD 11[RFC0822]无关。
SSH packets have message numbers in the range 1 to 255. These numbers have been allocated as follows:
SSH数据包的消息编号范围为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个本地扩展
This document is part of a set. The instructions for the IANA for the SSH protocol, as defined in this document, [SSH-USERAUTH], [SSH-TRANS], and [SSH-CONNECT], are detailed in [SSH-NUMBERS]. The following is a brief summary for convenience, but note well that [SSH-NUMBERS] contains the actual instructions to the IANA, which may be superseded in the future.
本文件是一套文件的一部分。本文档[SSH-USERAUTH]、[SSH-TRANS]和[SSH-CONNECT]中定义的SSH协议IANA的说明在[SSH-NUMBERS]中有详细说明。为了方便起见，下面是一个简短的摘要，但请注意，[SSH-NUMBERS]包含了IANA的实际指令，这些指令可能在将来被取代。
Allocation of the following types of names in the SSH protocols is assigned by IETF consensus:
SSH协议中以下类型名称的分配由IETF协商一致分配：
o Service Names * Authentication Methods * Connection Protocol Channel Names * Connection Protocol Global Request Names * Connection Protocol Channel Request Names
o 服务名称*身份验证方法*连接协议通道名称*连接协议全局请求名称*连接协议通道请求名称
o Key Exchange Method Names
o 密钥交换方法名称
o Assigned Algorithm Names * Encryption Algorithm Names * MAC Algorithm Names * Public Key Algorithm Names * Compression Algorithm Names
o 分配的算法名称*加密算法名称*MAC算法名称*公钥算法名称*压缩算法名称
These names 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.
这些名称必须是可打印的US-ASCII字符串，并且不得包含符号（“@”）、逗号（“，”）处的字符、空格、控制字符（ASCII代码32或更少）或ASCII代码127（DEL）。名称区分大小写，长度不得超过64个字符。
Names with the at-sign ("@") are locally defined extensions and are not controlled by the IANA.
带有at符号（“@”）的名称是本地定义的扩展名，不受IANA控制。
Each category of names listed above has a separate namespace. However, using the same name in multiple categories SHOULD be avoided to minimize confusion.
上面列出的每一类名称都有一个单独的名称空间。但是，应避免在多个类别中使用相同的名称，以尽量减少混淆。
Message numbers (see Section 7) in the range of 0 to 191 are allocated via IETF CONSENSUS, as described in [RFC2434]. Message numbers in the 192 to 255 range (local extensions) are reserved for PRIVATE USE, also as described in [RFC2434].
如[RFC2434]所述，0至191范围内的消息编号（见第7节）通过IETF共识进行分配。192到255范围（本地扩展名）的消息编号保留供私人使用，也如[RFC2434]中所述。
In order to make the entire body of Security Considerations more accessible, Security Considerations for the transport, authentication, and connection documents have been gathered here.
为了使整个安全注意事项更易于访问，这里收集了传输、身份验证和连接文档的安全注意事项。
The transport protocol [SSH-TRANS] provides a confidential channel over an insecure network. It performs server host authentication, key exchange, encryption, and integrity protection. It also derives a unique session id that may be used by higher-level protocols.
传输协议[SSH-TRANS]在不安全的网络上提供机密通道。它执行服务器主机身份验证、密钥交换、加密和完整性保护。它还派生一个可由更高级别协议使用的唯一会话id。
The authentication protocol [SSH-USERAUTH] provides a suite of mechanisms that can be used to authenticate the client user to the server. Individual mechanisms specified in the authentication protocol use the session id provided by the transport protocol and/or depend on the security and integrity guarantees of the transport protocol.
身份验证协议[SSH-USERAUTH]提供了一套机制，可用于向服务器验证客户端用户。身份验证协议中指定的各个机制使用传输协议提供的会话id和/或依赖于传输协议的安全性和完整性保证。
The connection protocol [SSH-CONNECT] specifies a mechanism to multiplex multiple streams (channels) of data over the confidential and authenticated transport. It also specifies channels for accessing an interactive shell, for proxy-forwarding various external protocols over the secure transport (including arbitrary TCP/IP protocols), and for accessing secure subsystems on the server host.
连接协议[SSH-CONNECT]指定了一种机制，用于在机密和经过身份验证的传输上多路传输多个数据流（通道）。它还指定用于访问交互式shell、通过安全传输代理转发各种外部协议（包括任意TCP/IP协议）以及访问服务器主机上的安全子系统的通道。
This protocol binds each session key to the session by including random, session specific data in the hash used to produce session keys. Special care should be taken to ensure that all of the random numbers are of good quality. If the random data here (e.g., Diffie-Hellman (DH) parameters) are pseudo-random, then the pseudo-random number generator should be cryptographically secure (i.e., its next output not easily guessed even when knowing all previous outputs) and, furthermore, proper entropy needs to be added to the pseudo-random number generator. [RFC4086] offers suggestions for sources of random numbers and entropy. Implementers should note the importance of entropy and the well-meant, anecdotal warning about the difficulty in properly implementing pseudo-random number generating functions.
该协议通过在用于生成会话密钥的散列中包含随机的、特定于会话的数据，将每个会话密钥绑定到会话。应特别注意确保所有随机数的质量良好。如果此处的随机数据（例如Diffie-Hellman（DH）参数）是伪随机的，则伪随机数生成器应该是加密安全的（即，即使知道所有以前的输出也不容易猜测其下一个输出），此外，需要向伪随机数生成器添加适当的熵。[RFC4086]为随机数和熵的来源提供建议。实现者应该注意熵的重要性，以及关于正确实现伪随机数生成函数的困难的善意的轶事警告。
The amount of entropy available to a given client or server may sometimes be less than what is required. In this case, one must either resort to pseudo-random number generation regardless of insufficient entropy or refuse to run the protocol. The latter is preferable.
给定客户机或服务器的可用熵有时可能小于所需的熵。在这种情况下，无论熵是否足够，都必须使用伪随机数生成，或者拒绝运行协议。后者更可取。
When displaying text to a user, such as error or debug messages, the client software SHOULD replace any control characters (except tab, carriage return, and newline) with safe sequences to avoid attacks by sending terminal control characters.
当向用户显示文本（如错误或调试消息）时，客户端软件应使用安全序列替换任何控制字符（制表符、回车符和换行符除外），以通过发送终端控制字符避免攻击。
It is beyond the scope of this document and the Secure Shell Working Group to analyze or recommend specific ciphers other than the ones that have been established and accepted within the industry. At the time of this writing, commonly used ciphers include 3DES, ARCFOUR, twofish, serpent, and blowfish. AES has been published by The US Federal Information Processing Standards as [FIPS-197], and the cryptographic community has accepted AES as well. As always, implementers and users should check current literature to ensure that no recent vulnerabilities have been found in ciphers used within products. Implementers should also check to see which ciphers are considered to be relatively stronger than others and should recommend their use to users over relatively weaker ciphers. It would be considered good form for an implementation to politely and unobtrusively notify a user that a stronger cipher is available and should be used when a weaker one is actively chosen.
分析或推荐特定密码（行业内已建立和接受的密码除外）超出了本文件和Secure Shell工作组的范围。在撰写本文时，常用的密码包括3DES、ARCFOUR、twofish、蛇和河豚。AES已由美国联邦信息处理标准发布为[FIPS-197]，密码社区也接受AES。和往常一样，实现者和用户应该检查当前的文献，以确保在产品中使用的密码中没有发现最近的漏洞。实施者还应该检查哪些密码被认为比其他密码更强，并且应该向用户推荐使用它们，而不是使用相对较弱的密码。对于一个实现来说，礼貌而不唐突地通知用户一个更强的密码是可用的，并且应该在主动选择较弱的密码时使用，这将被认为是一种很好的形式。
The "none" cipher is provided for debugging and SHOULD NOT be used except for that purpose. Its cryptographic properties are sufficiently described in [RFC2410], which will show that its use does not meet the intent of this protocol.
“none”密码是为调试而提供的，除此之外不应使用。[RFC2410]中充分描述了其密码特性，这将表明其使用不符合本协议的意图。
The relative merits of these and other ciphers may also be found in current literature. Two references that may provide information on the subject are [SCHNEIER] and [KAUFMAN]. Both of these describe the CBC mode of operation of certain ciphers and the weakness of this scheme. Essentially, this mode is theoretically vulnerable to chosen cipher-text attacks because of the high predictability of the start of packet sequence. However, this attack is deemed difficult and not considered fully practicable, especially if relatively long block sizes are used.
这些密码和其他密码的相对优点也可以在当前的文献中找到。两个可能提供有关该主题信息的参考文献是[SCHNEIER]和[KAUFMAN]。这两种方案都描述了某些密码的CBC操作模式以及该方案的弱点。从本质上讲，由于数据包序列的开始具有很高的可预测性，因此这种模式在理论上容易受到选定密文攻击。然而，这种攻击被认为是困难的，并且不被认为是完全可行的，尤其是在使用相对较长的块大小的情况下。
Additionally, another CBC mode attack may be mitigated through the insertion of packets containing SSH_MSG_IGNORE. Without this technique, a specific attack may be successful. For this attack (commonly known as the Rogaway attack [ROGAWAY], [DAI], [BELLARE]) to work, the attacker would need to know the Initialization Vector (IV) of the next block that is going to be encrypted. In CBC mode that is the output of the encryption of the previous block. If the attacker does not have any way to see the packet yet (i.e., it is in the internal buffers of the SSH implementation or even in the kernel), then this attack will not work. If the last packet has been sent out to the network (i.e., the attacker has access to it), then he can use the attack.
此外，可以通过插入包含SSH_MSG_IGNORE的数据包来缓解另一种CBC模式攻击。如果没有这种技术，特定的攻击可能会成功。要使此攻击（通常称为Rogaway攻击[Rogaway]、[DAI]、[BELLARE]）起作用，攻击者需要知道下一个要加密的块的初始化向量（IV）。在CBC模式下，前一块加密的输出。如果攻击者还无法查看数据包（即，它位于SSH实现的内部缓冲区中，甚至在内核中），则此攻击将不起作用。如果最后一个数据包已发送到网络（即，攻击者可以访问该数据包），则他可以使用该攻击。
In the optimal case, an implementer would need to add an extra packet only if the packet has been sent out onto the network and there are no other packets waiting for transmission. Implementers may wish to check if there are any unsent packets awaiting transmission; unfortunately, it is not normally easy to obtain this information from the kernel or buffers. If there are no unsent packets, then a packet containing SSH_MSG_IGNORE SHOULD be sent. If a new packet is added to the stream every time the attacker knows the IV that is supposed to be used for the next packet, then the attacker will not be able to guess the correct IV, thus the attack will never be successful.
在最佳情况下，仅当数据包已发送到网络且没有其他数据包等待传输时，实现者才需要添加额外的数据包。实现者可能希望检查是否有任何未发送的数据包等待传输；不幸的是，从内核或缓冲区获取这些信息通常并不容易。如果没有未发送的数据包，则应发送包含SSH\u MSG\u IGNORE的数据包。如果每次攻击者知道下一个数据包应该使用的IV时，都向流中添加一个新数据包，那么攻击者将无法猜出正确的IV，因此攻击将永远不会成功。
As an example, consider the following case:
作为一个例子，考虑以下情况：
Client Server
------ ------
TCP(seq=x, len=500) ---->
contains Record 1
Client Server
------ ------
TCP(seq=x, len=500) ---->
contains Record 1
[500 ms passes, no ACK]
[500毫秒通过，无应答]
TCP(seq=x, len=1000) ---->
contains Records 1,2
TCP(seq=x, len=1000) ---->
contains Records 1,2
ACK
阿克
1. The Nagle algorithm + TCP retransmits mean that the two records get coalesced into a single TCP segment.
1. Nagle算法+TCP重传意味着两个记录合并成一个TCP段。
2. Record 2 is not at the beginning of the TCP segment and never will be because it gets ACKed.
2. 记录2不在TCP段的开头，也永远不会，因为它已被确认。
3. Yet, the attack is possible because Record 1 has already been seen.
3. 然而，攻击是可能的，因为记录1已经被看到。
As this example indicates, it is unsafe to use the existence of unflushed data in the TCP buffers proper as a guide to whether an empty packet is needed, since when the second write() is performed the buffers will contain the un-ACKed Record 1.
如本例所示，使用TCP缓冲区中是否存在未刷新的数据作为是否需要空数据包的指南是不安全的，因为当执行第二次写入（）时，缓冲区将包含未确认的记录1。
On the other hand, it is perfectly safe to have the following situation:
另一方面，出现以下情况是完全安全的：
Client Server
------ ------
TCP(seq=x, len=500) ---->
contains SSH_MSG_IGNORE
Client Server
------ ------
TCP(seq=x, len=500) ---->
contains SSH_MSG_IGNORE
TCP(seq=y, len=500) ---->
contains Data
TCP(seq=y, len=500) ---->
contains Data
Provided that the IV for the second SSH Record is fixed after the data for the Data packet is determined, then the following should be performed:
如果在确定数据包的数据后，第二条SSH记录的IV是固定的，则应执行以下操作：
read from user encrypt null packet encrypt data packet
读取用户加密空数据包加密数据包
This protocol does allow the Data Integrity mechanism to be disabled. Implementers SHOULD be wary of exposing this feature for any purpose other than debugging. Users and administrators SHOULD be explicitly warned anytime the "none" MAC is enabled.
此协议允许禁用数据完整性机制。实现者应该警惕为了调试以外的任何目的而公开此功能。无论何时启用“无”MAC，都应明确警告用户和管理员。
So long as the "none" MAC is not used, this protocol provides data integrity.
只要不使用“无”MAC，该协议就提供数据完整性。
Because MACs use a 32-bit sequence number, they might start to leak information after 2**32 packets have been sent. However, following the rekeying recommendations should prevent this attack. The transport protocol [SSH-TRANS] recommends rekeying after one gigabyte of data, and the smallest possible packet is 16 bytes. Therefore, rekeying SHOULD happen after 2**28 packets at the very most.
因为MAC使用32位序列号，所以在发送2**32数据包后，它们可能会开始泄漏信息。但是，遵循重新设置密钥的建议应该可以防止这种攻击。传输协议[SSH-TRANS]建议在1G数据之后重新键入，最小的数据包可能是16字节。因此，最长应在2**28个数据包之后进行密钥更新。
The use of a MAC other than "none" provides integrity and authentication. In addition, the transport protocol provides a unique session identifier (bound in part to pseudo-random data that is part of the algorithm and key exchange process) that can be used by higher level protocols to bind data to a given session and prevent
使用“无”以外的MAC提供完整性和身份验证。此外，传输协议还提供了一个唯一的会话标识符（部分绑定到作为算法和密钥交换过程一部分的伪随机数据），高级协议可以使用该标识符将数据绑定到给定会话并防止
replay of data from prior sessions. For example, the authentication protocol ([SSH-USERAUTH]) uses this to prevent replay of signatures from previous sessions. Because public key authentication exchanges are cryptographically bound to the session (i.e., to the initial key exchange), they cannot be successfully replayed in other sessions. Note that the session id can be made public without harming the security of the protocol.
重播以前会话中的数据。例如，身份验证协议（[SSH-USERAUTH]）使用它来防止重播以前会话中的签名。由于公钥身份验证交换以加密方式绑定到会话（即初始密钥交换），因此无法在其他会话中成功重播。请注意，会话id可以公开，而不会损害协议的安全性。
If two sessions have the same session id (hash of key exchanges), then packets from one can be replayed against the other. It must be stressed that the chances of such an occurrence are, needless to say, minimal when using modern cryptographic methods. This is all the more true when specifying larger hash function outputs and DH parameters.
如果两个会话具有相同的会话id（密钥交换的散列），那么来自一个会话的数据包可以针对另一个会话进行重放。必须强调的是，不用说，在使用现代密码方法时，发生这种情况的可能性极小。当指定更大的散列函数输出和DH参数时，更是如此。
Replay detection using monotonically increasing sequence numbers as input to the MAC, or HMAC in some cases, is described in [RFC2085], [RFC2246], [RFC2743], [RFC1964], [RFC2025], and [RFC4120]. The underlying construct is discussed in [RFC2104]. Essentially, a different sequence number in each packet ensures that at least this one input to the MAC function will be unique and will provide a nonrecurring MAC output that is not predictable to an attacker. If the session stays active long enough, however, this sequence number will wrap. This event may provide an attacker an opportunity to replay a previously recorded packet with an identical sequence number but only if the peers have not rekeyed since the transmission of the first packet with that sequence number. If the peers have rekeyed, then the replay will be detected since the MAC check will fail. For this reason, it must be emphasized that peers MUST rekey before a wrap of the sequence numbers. Naturally, if an attacker does attempt to replay a captured packet before the peers have rekeyed, then the receiver of the duplicate packet will not be able to validate the MAC and it will be discarded. The reason that the MAC will fail is because the receiver will formulate a MAC based upon the packet contents, the shared secret, and the expected sequence number. Since the replayed packet will not be using that expected sequence number (the sequence number of the replayed packet will have already been passed by the receiver), the calculated MAC will not match the MAC received with the packet.
[RFC2085]、[RFC2246]、[RFC2743]、[RFC1964]、[RFC2025]和[RFC4120]中描述了使用单调递增的序列号作为MAC或HMAC输入的重播检测。[RFC2104]中讨论了底层构造。本质上，每个数据包中的不同序列号确保MAC功能的至少一个输入是唯一的，并提供攻击者无法预测的非重现MAC输出。但是，如果会话保持活动状态的时间足够长，则此序列号将换行。此事件可能会使攻击者有机会重播先前记录的具有相同序列号的数据包，但前提是自传输具有该序列号的第一个数据包后，对等方尚未重新键入该序列号。如果对等方已重新键入密钥，则将检测到重播，因为MAC检查将失败。出于这个原因，必须强调的是，对等方必须在序列号换行之前重新键入。当然，如果攻击者在对等方重新键入密钥之前尝试重播捕获的数据包，则重复数据包的接收方将无法验证MAC，并且将丢弃该数据包。MAC将失败的原因是，接收机将基于分组内容、共享秘密和预期序列号制定MAC。由于重播分组将不使用该期望序列号（重播分组的序列号将已经被接收机传递），因此计算出的MAC将与接收到的MAC与分组不匹配。
This protocol makes no assumptions or provisions for an infrastructure or means for distributing the public keys of hosts. It is expected that this protocol will sometimes be used without first verifying the association between the server host key and the server host name. Such usage is vulnerable to man-in-the-middle attacks. This section describes this and encourages administrators
该协议不对用于分发主机公钥的基础设施或方法做出任何假设或规定。预计有时会在不首先验证服务器主机密钥和服务器主机名之间的关联的情况下使用此协议。这种用法容易受到中间人攻击。本节介绍了这一点，并鼓励管理员
and users to understand the importance of verifying this association before any session is initiated.
和用户了解在启动任何会话之前验证此关联的重要性。
There are three cases of man-in-the-middle attacks to consider. The first is where an attacker places a device between the client and the server before the session is initiated. In this case, the attack device is trying to mimic the legitimate server and will offer its public key to the client when the client initiates a session. If it were to offer the public key of the server, then it would not be able to decrypt or sign the transmissions between the legitimate server and the client unless it also had access to the private key of the host. The attack device will also, simultaneously to this, initiate a session to the legitimate server, masquerading itself as the client. If the public key of the server had been securely distributed to the client prior to that session initiation, the key offered to the client by the attack device will not match the key stored on the client. In that case, the user SHOULD be given a warning that the offered host key does not match the host key cached on the client. As described in Section 4.1, the user may be free to accept the new key and continue the session. It is RECOMMENDED that the warning provide sufficient information to the user of the client device so the user may make an informed decision. If the user chooses to continue the session with the stored public key of the server (not the public key offered at the start of the session), then the session-specific data between the attacker and server will be different between the client-to-attacker session and the attacker-to-server sessions due to the randomness discussed above. From this, the attacker will not be able to make this attack work since the attacker will not be able to correctly sign packets containing this session-specific data from the server, since he does not have the private key of that server.
有三例人在中间发作时要考虑。第一种情况是，攻击者在会话启动之前将设备放置在客户端和服务器之间。在这种情况下，攻击设备试图模仿合法服务器，并在客户端启动会话时向客户端提供其公钥。如果它提供服务器的公钥，那么它将无法对合法服务器和客户端之间的传输进行解密或签名，除非它还可以访问主机的私钥。攻击设备还将同时启动与合法服务器的会话，伪装成客户端。如果服务器的公钥在会话启动之前已安全分发给客户端，则攻击设备提供给客户端的密钥将与客户端上存储的密钥不匹配。在这种情况下，应该向用户发出警告，指出提供的主机密钥与客户端上缓存的主机密钥不匹配。如第4.1节所述，用户可以自由接受新密钥并继续会话。建议警告向客户端设备的用户提供足够的信息，以便用户可以做出明智的决定。如果用户选择使用存储的服务器公钥（而不是会话开始时提供的公钥）继续会话，则由于上述随机性，攻击者和服务器之间的会话特定数据在客户端到攻击者会话和攻击者到服务器会话之间会有所不同。因此，攻击者将无法使此攻击生效，因为攻击者无法从服务器正确签署包含此会话特定数据的数据包，因为他没有该服务器的私钥。
The second case that should be considered is similar to the first case in that it also happens at the time of connection, but this case points out the need for the secure distribution of server public keys. If the server public keys are not securely distributed, then the client cannot know if it is talking to the intended server. An attacker may use social engineering techniques to pass off server keys to unsuspecting users and may then place a man-in-the-middle attack device between the legitimate server and the clients. If this is allowed to happen, then the clients will form client-to-attacker sessions, and the attacker will form attacker-to-server sessions and will be able to monitor and manipulate all of the traffic between the clients and the legitimate servers. Server administrators are encouraged to make host key fingerprints available for checking by some means whose security does not rely on the integrity of the actual host keys. Possible mechanisms are discussed in Section 4.1 and may also include secured Web pages, physical pieces of paper,
应该考虑的第二种情况与第一种情况类似，因为它也发生在连接时，但这种情况指出需要安全分发服务器公钥。如果服务器公钥未安全分发，则客户端无法知道它是否正在与预期的服务器通信。攻击者可以使用社会工程技术将服务器密钥传递给毫无戒心的用户，然后将一个人置于合法服务器和客户端之间的中间攻击设备。如果允许这种情况发生，则客户端将形成客户端到攻击者的会话，攻击者将形成攻击者到服务器的会话，并能够监视和操纵客户端和合法服务器之间的所有通信量。鼓励服务器管理员通过某种安全性不依赖于实际主机密钥完整性的方法，使主机密钥指纹可用于检查。第4.1节讨论了可能的机制，还可能包括安全网页、物理纸张、，
etc. Implementers SHOULD provide recommendations on how best to do this with their implementation. Because the protocol is extensible, future extensions to the protocol may provide better mechanisms for dealing with the need to know the server's host key before connecting. For example, making the host key fingerprint available through a secure DNS lookup, or using Kerberos ([RFC4120]) over GSS-API ([RFC1964]) during key exchange to authenticate the server are possibilities.
等。实施者应就如何最好地在其实施中做到这一点提供建议。由于该协议是可扩展的，因此未来对该协议的扩展可能会提供更好的机制来处理在连接之前了解服务器主机密钥的需要。例如，可以通过安全DNS查找使主机密钥指纹可用，或者在密钥交换期间通过GSS-API（[RFC1964]）使用Kerberos（[RFC4120]）对服务器进行身份验证。
In the third man-in-the-middle case, attackers may attempt to manipulate packets in transit between peers after the session has been established. As described in Section 9.3.3, a successful attack of this nature is very improbable. As in Section 9.3.3, this reasoning does assume that the MAC is secure and that it is infeasible to construct inputs to a MAC algorithm to give a known output. This is discussed in much greater detail in Section 6 of [RFC2104]. If the MAC algorithm has a vulnerability or is weak enough, then the attacker may be able to specify certain inputs to yield a known MAC. With that, they may be able to alter the contents of a packet in transit. Alternatively, the attacker may be able to exploit the algorithm vulnerability or weakness to find the shared secret by reviewing the MACs from captured packets. In either of those cases, an attacker could construct a packet or packets that could be inserted into an SSH stream. To prevent this, implementers are encouraged to utilize commonly accepted MAC algorithms, and administrators are encouraged to watch current literature and discussions of cryptography to ensure that they are not using a MAC algorithm that has a recently found vulnerability or weakness.
在中间的第三种情况下，攻击者可能试图在会话建立后操纵对等方之间传输的数据包。如第9.3.3节所述，这种性质的攻击不太可能成功。如第9.3.3节所述，该推理确实假设MAC是安全的，并且不可能为MAC算法构造输入以提供已知输出。[RFC2104]第6节对此进行了更详细的讨论。如果MAC算法存在漏洞或足够弱，则攻击者可以指定某些输入以生成已知MAC。这样，他们就可以在传输过程中改变数据包的内容。或者，攻击者可以利用算法漏洞或弱点，通过查看捕获的数据包中的MAC来查找共享秘密。在这两种情况下，攻击者都可以构造一个或多个可插入SSH流的数据包。为了防止这种情况，鼓励实施者使用普遍接受的MAC算法，并鼓励管理员查看当前的文献和加密讨论，以确保他们没有使用最近发现漏洞或弱点的MAC算法。
In summary, the use of this protocol without a reliable association of the binding between a host and its host keys is inherently insecure and is NOT RECOMMENDED. However, it may be necessary in non-security-critical environments, and will still provide protection against passive attacks. Implementers of protocols and applications running on top of this protocol should keep this possibility in mind.
总之，如果主机与其主机密钥之间没有可靠的绑定关联，则使用此协议本质上是不安全的，因此不建议这样做。但是，它在非安全关键环境中可能是必要的，并且仍将提供被动攻击防护。在此协议之上运行的协议和应用程序的实现者应该记住这种可能性。
This protocol is designed to be used over a reliable transport. If transmission errors or message manipulation occur, the connection is closed. The connection SHOULD be re-established if this occurs. Denial of service attacks of this type (wire cutter) are almost impossible to avoid.
此协议旨在通过可靠的传输来使用。如果发生传输错误或消息操纵，则连接将关闭。如果发生这种情况，应重新建立连接。这种类型的拒绝服务攻击（wire cutter）几乎无法避免。
In addition, this protocol is vulnerable to denial of service attacks because an attacker can force the server to go through the CPU and memory intensive tasks of connection setup and key exchange without authenticating. Implementers SHOULD provide features that make this
此外，此协议容易受到拒绝服务攻击，因为攻击者可以在不进行身份验证的情况下强制服务器执行连接设置和密钥交换等CPU和内存密集型任务。实现者应该提供一些特性来实现这一点
more difficult, for example, only allowing connections from a subset of clients known to have valid users.
更困难的是，例如，只允许来自已知具有有效用户的客户端子集的连接。
The protocol was not designed to eliminate covert channels. For example, the padding, SSH_MSG_IGNORE messages, and several other places in the protocol can be used to pass covert information, and the recipient has no reliable way of verifying whether such information is being sent.
该协议不是为了消除隐蔽通道而设计的。例如，协议中的padding、SSH_MSG_IGNORE messages和其他几个位置可用于传递隐蔽信息，而接收方无法可靠地验证是否发送了此类信息。
It should be noted that the Diffie-Hellman key exchanges may provide perfect forward secrecy (PFS). PFS is essentially defined as the cryptographic property of a key-establishment protocol in which the compromise of a session key or long-term private key after a given session does not cause the compromise of any earlier session [ANSI-T1.523-2001]. SSH sessions resulting from a key exchange using the diffie-hellman methods described in the section Diffie-Hellman Key Exchange of [SSH-TRANS] (including "diffie-hellman-group1-sha1" and "diffie-hellman-group14-sha1") are secure even if private keying/authentication material is later revealed, but not if the session keys are revealed. So, given this definition of PFS, SSH does have PFS. However, this property is not commuted to any of the applications or protocols using SSH as a transport. The transport layer of SSH provides confidentiality for password authentication and other methods that rely on secret data.
应该注意的是，Diffie-Hellman密钥交换可以提供完美的前向保密性（PFS）。PFS本质上被定义为密钥建立协议的密码特性，其中给定会话后会话密钥或长期私钥的泄露不会导致任何早期会话的泄露[ANSI-T1.523-2001]。使用[SSH-TRANS]的diffie-hellman密钥交换（包括“diffie-hellman-group1-sha1”和“diffie-hellman-group14-sha1”）一节中所述的diffie-hellman方法进行密钥交换而产生的SSH会话是安全的，即使后来泄露了私钥/身份验证材料，但如果泄露了会话密钥，则不会。因此，根据PFS的这个定义，SSH确实有PFS。但是，此属性不会转换为使用SSH作为传输的任何应用程序或协议。SSH的传输层为密码身份验证和其他依赖机密数据的方法提供机密性。
Of course, if the DH private parameters for the client and server are revealed, then the session key is revealed, but these items can be thrown away after the key exchange completes. It's worth pointing out that these items should not be allowed to end up on swap space and that they should be erased from memory as soon as the key exchange completes.
当然，如果显示了客户端和服务器的DH私有参数，则会显示会话密钥，但这些项可以在密钥交换完成后丢弃。值得指出的是，不应允许这些项以交换空间结束，应在密钥交换完成后立即从内存中删除它们。
As stated in the section on Algorithm Negotiation of [SSH-TRANS], each device will send a list of preferred methods for key exchange. The most-preferred method is the first in the list. It is RECOMMENDED that the algorithms be sorted by cryptographic strength, strongest first. Some additional guidance for this is given in [RFC3766].
如[SSH-TRANS]算法协商部分所述，每个设备将发送密钥交换首选方法的列表。最首选的方法是列表中的第一种。建议按照密码强度对算法进行排序，首先是最强的。[RFC3766]中给出了有关这方面的一些附加指南。
Passive monitoring of any protocol may give an attacker some information about the session, the user, or protocol specific information that they would otherwise not be able to garner. For example, it has been shown that traffic analysis of an SSH session can yield information about the length of the password - [Openwall] and [USENIX]. Implementers should use the SSH_MSG_IGNORE packet, along with the inclusion of random lengths of padding, to thwart attempts at traffic analysis. Other methods may also be found and implemented.
对任何协议的被动监视都可能会向攻击者提供一些关于会话、用户或协议特定信息的信息，否则他们将无法获取这些信息。例如，已经证明，SSH会话的流量分析可以产生有关密码长度的信息-[Openwall]和[USENIX]。实现者应该使用SSH_MSG_IGNORE数据包，以及包含随机长度的填充，以阻止流量分析的尝试。还可以找到并实施其他方法。
The purpose of this protocol is to perform client user authentication. It assumes that this runs over a secure transport layer protocol, which has already authenticated the server machine, established an encrypted communications channel, and computed a unique session identifier for this session.
此协议的目的是执行客户端用户身份验证。它假定这通过安全传输层协议运行，该协议已经对服务器计算机进行了身份验证，建立了加密的通信通道，并为此会话计算了唯一的会话标识符。
Several authentication methods with different security characteristics are allowed. It is up to the server's local policy to decide which methods (or combinations of methods) it is willing to accept for each user. Authentication is no stronger than the weakest combination allowed.
允许使用几种具有不同安全特性的身份验证方法。由服务器的本地策略决定它愿意为每个用户接受哪些方法（或方法的组合）。身份验证不强于允许的最弱组合。
The server may go into a sleep period after repeated unsuccessful authentication attempts to make key search more difficult for attackers. Care should be taken so that this doesn't become a self-denial of service vector.
在多次不成功的身份验证尝试使攻击者更难搜索密钥后，服务器可能进入休眠期。应小心，以免成为自我拒绝服务载体。
If the transport layer does not provide confidentiality, authentication methods that rely on secret data SHOULD be disabled. If it does not provide strong integrity protection, requests to change authentication data (e.g., a password change) SHOULD be disabled to prevent an attacker from modifying the ciphertext without being noticed, or rendering the new authentication data unusable (denial of service).
如果传输层不提供机密性，则应禁用依赖机密数据的身份验证方法。如果不提供强大的完整性保护，则应禁用更改身份验证数据的请求（例如，密码更改），以防止攻击者在未被注意的情况下修改密文，或使新身份验证数据不可用（拒绝服务）。
The assumption stated above, that the Authentication Protocol only runs over a secure transport that has previously authenticated the server, is very important to note. People deploying SSH are reminded of the consequences of man-in-the-middle attacks if the client does not have a very strong a priori association of the server with the host key of that server. Specifically, for the case of the Authentication Protocol, the client may form a session to a man-in-
上面所述的假设，即身份验证协议仅在先前已对服务器进行身份验证的安全传输上运行，这一点非常重要。如果客户端没有服务器与该服务器的主机密钥的非常强的先验关联，部署SSH的人员将被提醒注意中间人攻击的后果。具体地，对于认证协议的情况，客户端可以形成与城域网的会话-
the-middle attack device and divulge user credentials such as their username and password. Even in the cases of authentication where no user credentials are divulged, an attacker may still gain information they shouldn't have by capturing key-strokes in much the same way that a honeypot works.
中间攻击设备并泄露用户凭据，如用户名和密码。即使在没有泄露用户凭据的身份验证情况下，攻击者也可能通过与蜜罐工作方式大致相同的方式捕获击键来获得不应该拥有的信息。
Special care should be taken when designing debug messages. These messages may reveal surprising amounts of information about the host if not properly designed. Debug messages can be disabled (during user authentication phase) if high security is required. Administrators of host machines should make all attempts to compartmentalize all event notification messages and protect them from unwarranted observation. Developers should be aware of the sensitive nature of some of the normal event and debug messages, and may want to provide guidance to administrators on ways to keep this information away from unauthorized people. Developers should consider minimizing the amount of sensitive information obtainable by users during the authentication phase, in accordance with the local policies. For this reason, it is RECOMMENDED that debug messages be initially disabled at the time of deployment and require an active decision by an administrator to allow them to be enabled. It is also RECOMMENDED that a message expressing this concern be presented to the administrator of a system when the action is taken to enable debugging messages.
设计调试消息时应特别小心。如果设计不当，这些消息可能会泄露大量有关主机的信息。如果需要高安全性，可以禁用调试消息（在用户身份验证阶段）。主机的管理员应尽一切努力划分所有事件通知消息，并保护它们免受不必要的观察。开发人员应该了解一些正常事件和调试消息的敏感性质，并可能希望向管理员提供有关如何使这些信息远离未经授权的人员的指导。开发人员应考虑根据本地策略在认证阶段最小化用户可获得的敏感信息量。因此，建议在部署时首先禁用调试消息，并要求管理员作出主动决定以允许启用它们。还建议在采取措施启用调试消息时，向系统管理员显示一条表示此问题的消息。
The implementer MUST ensure that the credentials provided validate the professed user and also MUST ensure that the local policy of the server permits the user the access requested. In particular, because of the flexible nature of the SSH connection protocol, it may not be possible to determine the local security policy, if any, that should apply at the time of authentication because the kind of service being requested is not clear at that instant. For example, local policy might allow a user to access files on the server, but not start an interactive shell. However, during the authentication protocol, it is not known whether the user will be accessing files, attempting to use an interactive shell, or even both. In any event, where local security policy for the server host exists, it MUST be applied and enforced correctly.
实现者必须确保提供的凭据验证了自称的用户，还必须确保服务器的本地策略允许用户访问请求的权限。特别是，由于SSH连接协议的灵活性，可能无法确定在进行身份验证时应应用的本地安全策略（如果有），因为此时请求的服务类型不清楚。例如，本地策略可能允许用户访问服务器上的文件，但不启动交互式shell。但是，在身份验证协议期间，不知道用户是否将访问文件、尝试使用交互式shell，甚至两者都不知道。在任何情况下，如果存在服务器主机的本地安全策略，则必须正确应用和实施该策略。
Implementers are encouraged to provide a default local policy and make its parameters known to administrators and users. At the discretion of the implementers, this default policy may be along the lines of anything-goes where there are no restrictions placed upon users, or it may be along the lines of excessively-restrictive, in
鼓励实现者提供默认的本地策略，并让管理员和用户知道其参数。根据实施者的判断，此默认策略可能遵循对用户没有任何限制的任何方式，也可能遵循过度限制的方式
which case, the administrators will have to actively make changes to the initial default parameters to meet their needs. Alternatively, it may be some attempt at providing something practical and immediately useful to the administrators of the system so they don't have to put in much effort to get SSH working. Whatever choice is made must be applied and enforced as required above.
在这种情况下，管理员必须主动更改初始默认参数以满足其需要。或者，也可以尝试为系统管理员提供一些实用且立即有用的东西，这样他们就不必投入太多精力来让SSH正常工作。无论做出何种选择，都必须按照上述要求实施。
The use of public key authentication assumes that the client host has not been compromised. It also assumes that the private key of the server host has not been compromised.
公钥身份验证的使用假定客户端主机未受到危害。它还假设服务器主机的私钥没有被泄露。
This risk can be mitigated by the use of passphrases on private keys; however, this is not an enforceable policy. The use of smartcards, or other technology to make passphrases an enforceable policy is suggested.
这种风险可以通过在私钥上使用密码短语来缓解；然而，这不是一项可执行的政策。建议使用智能卡或其他技术使密码短语成为可执行的策略。
The server could require both password and public key authentication; however, this requires the client to expose its password to the server (see the section on Password Authentication below.)
服务器可能需要密码和公钥身份验证；但是，这需要客户端向服务器公开其密码（请参阅下面关于密码身份验证的部分）
The password mechanism, as specified in the authentication protocol, assumes that the server has not been compromised. If the server has been compromised, using password authentication will reveal a valid username/password combination to the attacker, which may lead to further compromises.
身份验证协议中指定的密码机制假定服务器未受到危害。如果服务器已被破坏，使用密码身份验证将向攻击者显示有效的用户名/密码组合，这可能导致进一步的破坏。
This vulnerability can be mitigated by using an alternative form of authentication. For example, public key authentication makes no assumptions about security on the server.
可以通过使用另一种身份验证形式来缓解此漏洞。例如，公钥身份验证对服务器上的安全性不作任何假设。
Host-based authentication assumes that the client has not been compromised. There are no mitigating strategies, other than to use host-based authentication in combination with another authentication method.
基于主机的身份验证假定客户端未受到危害。除了将基于主机的身份验证与另一种身份验证方法结合使用之外，没有缓解策略。
End point security is assumed by the connection protocol. If the server has been compromised, any terminal sessions, port forwarding, or systems accessed on the host are compromised. There are no mitigating factors for this.
端点安全性由连接协议承担。如果服务器已受损，则主机上访问的任何终端会话、端口转发或系统都将受损。没有任何缓解因素。
If the client has been compromised, and the server fails to stop the attacker at the authentication protocol, all services exposed (either as subsystems or through forwarding) will be vulnerable to attack. Implementers SHOULD provide mechanisms for administrators to control which services are exposed to limit the vulnerability of other services. These controls might include controlling which machines and ports can be targeted in port-forwarding operations, which users are allowed to use interactive shell facilities, or which users are allowed to use exposed subsystems.
如果客户端已被破坏，并且服务器无法通过身份验证协议阻止攻击者，则所有暴露的服务（作为子系统或通过转发）都将容易受到攻击。实现者应该为管理员提供机制来控制暴露哪些服务，以限制其他服务的漏洞。这些控制可能包括控制哪些机器和端口可以作为端口转发操作的目标，哪些用户可以使用交互式shell工具，或者哪些用户可以使用公开的子系统。
The SSH connection protocol allows for proxy forwarding of other protocols such as SMTP, POP3, and HTTP. This may be a concern for network administrators who wish to control the access of certain applications by users located outside of their physical location. Essentially, the forwarding of these protocols may violate site-specific security policies, as they may be undetectably tunneled through a firewall. Implementers SHOULD provide an administrative mechanism to control the proxy forwarding functionality so that site-specific security policies may be upheld.
SSH连接协议允许代理转发其他协议，如SMTP、POP3和HTTP。对于希望控制位于物理位置之外的用户对某些应用程序的访问的网络管理员来说，这可能是一个问题。本质上，这些协议的转发可能违反特定于站点的安全策略，因为它们可能无法通过防火墙检测到。实现者应该提供管理机制来控制代理转发功能，以便支持特定于站点的安全策略。
In addition, a reverse proxy forwarding functionality is available, which, again, can be used to bypass firewall controls.
此外，还提供了反向代理转发功能，可再次用于绕过防火墙控制。
As indicated above, end-point security is assumed during proxy forwarding operations. Failure of end-point security will compromise all data passed over proxy forwarding.
如上所述，在代理转发操作期间假定了端点安全性。端点安全性故障将危及通过代理转发传递的所有数据。
Another form of proxy forwarding provided by the SSH connection protocol is the forwarding of the X11 protocol. If end-point security has been compromised, X11 forwarding may allow attacks against the X11 server. Users and administrators should, as a matter of course, use appropriate X11 security mechanisms to prevent unauthorized use of the X11 server. Implementers, administrators, and users who wish to further explore the security mechanisms of X11 are invited to read [SCHEIFLER] and analyze previously reported
SSH连接协议提供的另一种代理转发形式是X11协议的转发。如果端点安全性遭到破坏，X11转发可能允许攻击X11服务器。当然，用户和管理员应该使用适当的X11安全机制来防止未经授权使用X11服务器。希望进一步探索X11安全机制的实现者、管理员和用户将被邀请阅读[SCHEIFLER]并分析之前报告的内容
problems with the interactions between SSH forwarding and X11 in CERT vulnerabilities VU#363181 and VU#118892 [CERT].
证书漏洞VU#363181和VU#118892[CERT]中SSH转发和X11之间的交互问题。
X11 display forwarding with SSH, by itself, is not sufficient to correct well known problems with X11 security [VENEMA]. However, X11 display forwarding in SSH (or other secure protocols), combined with actual and pseudo-displays that accept connections only over local IPC mechanisms authorized by permissions or access control lists (ACLs), does correct many X11 security problems, as long as the "none" MAC is not used. It is RECOMMENDED that X11 display implementations default to allow the display to open only over local IPC. It is RECOMMENDED that SSH server implementations that support X11 forwarding default to allow the display to open only over local IPC. On single-user systems, it might be reasonable to default to allow the local display to open over TCP/IP.
单独使用SSH的X11显示转发不足以纠正X11安全性[VENEMA]的已知问题。但是，只要不使用“无”MAC，SSH（或其他安全协议）中的X11显示转发，加上仅通过权限或访问控制列表（ACL）授权的本地IPC机制接受连接的实际和伪显示，确实可以纠正许多X11安全问题。建议X11显示实现默认为只允许通过本地IPC打开显示。建议支持X11转发的SSH服务器实现默认允许仅通过本地IPC打开显示。在单用户系统上，默认允许本地显示通过TCP/IP打开可能是合理的。
Implementers of the X11 forwarding protocol SHOULD implement the magic cookie access-checking spoofing mechanism, as described in [SSH-CONNECT], as an additional mechanism to prevent unauthorized use of the proxy.
X11转发协议的实现者应实现[SSH-CONNECT]中所述的magic cookie访问检查欺骗机制，作为防止未经授权使用代理的附加机制。
[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月。
[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月。
[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月。
[RFC0854] Postel, J. and J. Reynolds, "Telnet Protocol Specification", STD 8, RFC 854, May 1983.
[RFC0854]Postel，J.和J.Reynolds，“Telnet协议规范”，STD 8，RFC 854，1983年5月。
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987.
[RFC1034]Mockapetris，P.，“域名-概念和设施”，STD 13，RFC 1034，1987年11月。
[RFC1282] Kantor, B., "BSD Rlogin", RFC 1282, December 1991.
[RFC1282]Kantor，B.，“BSD Rlogin”，RFC 1282，1991年12月。
[RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The Kerberos Network Authentication Service (V5)", RFC 4120, July 2005.
[RFC4120]Neuman，C.，Yu，T.，Hartman，S.，和K.Raeburn，“Kerberos网络身份验证服务（V5）”，RFC41202005年7月。
[RFC1964] Linn, J., "The Kerberos Version 5 GSS-API Mechanism", RFC 1964, June 1996.
[RFC1964]Linn，J.，“Kerberos版本5 GSS-API机制”，RFC19641996年6月。
[RFC2025] Adams, C., "The Simple Public-Key GSS-API Mechanism (SPKM)", RFC 2025, October 1996.
[RFC2025]Adams，C.，“简单公钥GSS-API机制（SPKM）”，RFC 20252996年10月。
[RFC2085] Oehler, M. and R. Glenn, "HMAC-MD5 IP Authentication with Replay Prevention", RFC 2085, February 1997.
[RFC2085]Oehler，M.和R.Glenn，“具有重放预防的HMAC-MD5 IP认证”，RFC 2085，1997年2月。
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997.
[RFC2104]Krawczyk，H.，Bellare，M.，和R.Canetti，“HMAC：用于消息认证的键控哈希”，RFC 2104，1997年2月。
[RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999.
[RFC2246]Dierks，T.和C.Allen，“TLS协议版本1.0”，RFC2246，1999年1月。
[RFC2410] Glenn, R. and S. Kent, "The NULL Encryption Algorithm and Its Use With IPsec", RFC 2410, November 1998.
[RFC2410]Glenn，R.和S.Kent，“空加密算法及其在IPsec中的使用”，RFC 2410，1998年11月。
[RFC2743] Linn, J., "Generic Security Service Application Program Interface Version 2, Update 1", RFC 2743, January 2000.
[RFC2743]Linn，J.，“通用安全服务应用程序接口版本2，更新1”，RFC 2743，2000年1月。
[RFC3766] Orman, H. and P. Hoffman, "Determining Strengths For Public Keys Used For Exchanging Symmetric Keys", BCP 86, RFC 3766, April 2004.
[RFC3766]Orman，H.和P.Hoffman，“确定用于交换对称密钥的公钥的强度”，BCP 86，RFC 3766，2004年4月。
[RFC4086] Eastlake, D., 3rd, Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005.
[RFC4086]伊斯特莱克，D.，3，席勒，J.和S.克罗克，“安全的随机性要求”，BCP 106，RFC 4086，2005年6月。
[FIPS-180-2] US National Institute of Standards and Technology, "Secure Hash Standard (SHS)", Federal Information Processing Standards Publication 180-2, August 2002.
[FIPS-180-2]美国国家标准与技术研究所，“安全哈希标准（SHS）”，联邦信息处理标准出版物180-22002年8月。
[FIPS-186-2] US National Institute of Standards and Technology, "Digital Signature Standard (DSS)", Federal Information Processing Standards Publication 186- 2, January 2000.
[FIPS-186-2]美国国家标准与技术研究所，“数字签名标准（DSS）”，联邦信息处理标准出版物186-22000年1月。
[FIPS-197] US National Institute of Standards and Technology, "Advanced Encryption Standard (AES)", Federal Information Processing Standards Publication 197, November 2001.
[FIPS-197]美国国家标准与技术研究所，“高级加密标准（AES）”，联邦信息处理标准出版物197，2001年11月。
[ANSI-T1.523-2001] American National Standards Institute, Inc., "Telecom Glossary 2000", ANSI T1.523-2001, February 2001.
[ANSI-T1.523-2001]美国国家标准协会，“2000年电信术语表”，ANSI T1.523-2001，2001年2月。
[SCHNEIER] Schneier, B., "Applied Cryptography Second Edition: protocols algorithms and source in code in C", John Wiley and Sons, New York, NY, 1996.
[SCHNEIER]SCHNEIER，B.，“应用密码学第二版：C语言中的协议、算法和源代码”，John Wiley and Sons，纽约，纽约，1996年。
[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月。
[KAUFMAN] Kaufman, C., Perlman, R., and M. Speciner, "Network Security: PRIVATE Communication in a PUBLIC World", Prentice Hall Publisher, 1995.
[KAUFMAN]KAUFMAN，C.，Perlman，R.，和M.Speciner，“网络安全：公共世界中的私人通信”，Prentice Hall出版社，1995年。
[CERT] CERT Coordination Center, The., "http://www.cert.org/nav/index_red.html".
[证书]证书协调中心http://www.cert.org/nav/index_red.html".
[VENEMA] Venema, W., "Murphy's Law and Computer Security", Proceedings of 6th USENIX Security Symposium, San Jose CA http://www.usenix.org/publications/library/ proceedings/sec96/venema.html, July 1996.
[VENEMA]VENEMA，W.，“墨菲定律与计算机安全”，第六届USENIX安全研讨会论文集，加利福尼亚州圣何塞http://www.usenix.org/publications/library/ 会议记录/sec96/venema.html，1996年7月。
[ROGAWAY] Rogaway, P., "Problems with Proposed IP Cryptography", Unpublished paper http://www.cs.ucdavis.edu/~rogaway/ papers/draft-rogaway-ipsec-comments-00.txt, 1996.
[ROGAWAY]ROGAWAY，P.，“拟议IP加密的问题”，未发表论文http://www.cs.ucdavis.edu/~rogaway/papers/draft-rogaway-ipsec-comments-00.txt，1996年。
[DAI] Dai, W., "An attack against SSH2 protocol", Email to the SECSH Working Group ietf-ssh@netbsd.org ftp:// ftp.ietf.org/ietf-mail-archive/secsh/2002- 02.mail, Feb 2002.
[DAI]DAI，W.，“对SSH2协议的攻击”，给SECSH工作组ietf的电子邮件-ssh@netbsd.orgftp://ftp.ietf.org/ietf-mail-archive/secsh/2002-02.mail，2002年2月。
[BELLARE] Bellaire, M., Kohno, T., and C. Namprempre, "Authenticated Encryption in SSH: Fixing the SSH Binary Packet Protocol", Proceedings of the 9th ACM Conference on Computer and Communications Security, Sept 2002.
[BELLARE]Bellaire，M.，Kohno，T.，和C.Namprempre，“SSH中的认证加密：修复SSH二进制数据包协议”，第九届ACM计算机和通信安全会议记录，2002年9月。
[Openwall] Solar Designer and D. Song, "SSH Traffic Analysis Attacks", Presentation given at HAL2001 and NordU2002 Conferences, Sept 2001.
[Openwall]Solar Designer和D.Song，“SSH流量分析攻击”，在HAL2001和NordU2002会议上的演讲，2001年9月。
[USENIX] Song, X.D., Wagner, D., and X. Tian, "Timing Analysis of Keystrokes and SSH Timing Attacks", Paper given at 10th USENIX Security Symposium, 2001.
[USENIX]Song，X.D.，Wagner，D.，和X.Tian，“击键和SSH定时攻击的定时分析”，在2001年第十届USENIX安全研讨会上发表的论文。
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）提供。