Network Working Group D. Harrington
Request for Comments: 5592 Huawei Technologies (USA)
Category: Standards Track J. Salowey
Cisco Systems
W. Hardaker
Cobham Analytic Solutions
June 2009
Network Working Group D. Harrington
Request for Comments: 5592 Huawei Technologies (USA)
Category: Standards Track J. Salowey
Cisco Systems
W. Hardaker
Cobham Analytic Solutions
June 2009
Secure Shell Transport Model for the Simple Network Management Protocol (SNMP)
简单网络管理协议（SNMP）的安全外壳传输模型
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) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2009 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
本文件受BCP 78和IETF信托在本文件出版之日生效的与IETF文件有关的法律规定的约束(http://trustee.ietf.org/license-info). 请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
本文件可能包含2008年11月10日之前发布或公开的IETF文件或IETF贡献中的材料。控制某些材料版权的人员可能未授予IETF信托允许在IETF标准流程之外修改此类材料的权利。在未从控制此类材料版权的人员处获得充分许可的情况下，不得在IETF标准流程之外修改本文件，也不得在IETF标准流程之外创建其衍生作品，除了将其格式化以RFC形式发布或将其翻译成英语以外的其他语言。
Abstract
摘要
This memo describes a Transport Model for the Simple Network Management Protocol (SNMP), using the Secure Shell (SSH) protocol.
本备忘录描述了使用Secure Shell（SSH）协议的简单网络管理协议（SNMP）的传输模型。
This memo also defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for monitoring and managing the Secure Shell Transport Model for SNMP.
本备忘录还定义了管理信息库（MIB）的一部分，用于基于TCP/IP的Internet中的网络管理协议。特别是，它定义了用于监视和管理SNMP的安全外壳传输模型的对象。
Table of Contents
目录
1. Introduction ....................................................3
1.1. The Internet-Standard Management Framework .................3
1.2. Conventions ................................................3
1.3. Modularity .................................................5
1.4. Motivation .................................................5
1.5. Constraints ................................................6
2. The Secure Shell Protocol .......................................7
3. How SSHTM Fits into the Transport Subsystem .....................8
3.1. Security Capabilities of this Model ........................8
3.1.1. Threats .............................................8
3.1.2. Message Authentication ..............................9
3.1.3. Authentication Protocol Support ....................10
3.1.4. SSH Subsystem ......................................11
3.2. Security Parameter Passing ................................12
3.3. Notifications and Proxy ...................................12
4. Cached Information and References ..............................13
4.1. Secure Shell Transport Model Cached Information ...........13
4.1.1. tmSecurityName .....................................13
4.1.2. tmSessionID ........................................14
4.1.3. Session State ......................................14
5. Elements of Procedure ..........................................14
5.1. Procedures for an Incoming Message ........................15
5.2. Procedures for Sending an Outgoing Message ................17
5.3. Establishing a Session ....................................18
5.4. Closing a Session .........................................20
6. MIB Module Overview ............................................21
6.1. Structure of the MIB Module ...............................21
6.2. Textual Conventions .......................................21
6.3. Relationship to Other MIB Modules .........................21
6.3.1. MIB Modules Required for IMPORTS ...................21
7. MIB Module Definition ..........................................22
8. Operational Considerations .....................................29
9. Security Considerations ........................................30
9.1. Skipping Public Key Verification ..........................31
9.2. Notification Authorization Considerations .................31
9.3. SSH User and Key Selection ................................31
1. Introduction ....................................................3
1.1. The Internet-Standard Management Framework .................3
1.2. Conventions ................................................3
1.3. Modularity .................................................5
1.4. Motivation .................................................5
1.5. Constraints ................................................6
2. The Secure Shell Protocol .......................................7
3. How SSHTM Fits into the Transport Subsystem .....................8
3.1. Security Capabilities of this Model ........................8
3.1.1. Threats .............................................8
3.1.2. Message Authentication ..............................9
3.1.3. Authentication Protocol Support ....................10
3.1.4. SSH Subsystem ......................................11
3.2. Security Parameter Passing ................................12
3.3. Notifications and Proxy ...................................12
4. Cached Information and References ..............................13
4.1. Secure Shell Transport Model Cached Information ...........13
4.1.1. tmSecurityName .....................................13
4.1.2. tmSessionID ........................................14
4.1.3. Session State ......................................14
5. Elements of Procedure ..........................................14
5.1. Procedures for an Incoming Message ........................15
5.2. Procedures for Sending an Outgoing Message ................17
5.3. Establishing a Session ....................................18
5.4. Closing a Session .........................................20
6. MIB Module Overview ............................................21
6.1. Structure of the MIB Module ...............................21
6.2. Textual Conventions .......................................21
6.3. Relationship to Other MIB Modules .........................21
6.3.1. MIB Modules Required for IMPORTS ...................21
7. MIB Module Definition ..........................................22
8. Operational Considerations .....................................29
9. Security Considerations ........................................30
9.1. Skipping Public Key Verification ..........................31
9.2. Notification Authorization Considerations .................31
9.3. SSH User and Key Selection ................................31
9.4. Conceptual Differences between USM and SSHTM ..............31
9.5. The 'none' MAC Algorithm ..................................32
9.6. Use with SNMPv1/v2c Messages ..............................32
9.7. MIB Module Security .......................................32
10. IANA Considerations ...........................................33
11. Acknowledgments ...............................................33
12. References ....................................................34
12.1. Normative References .....................................34
12.2. Informative References ...................................35
9.4. Conceptual Differences between USM and SSHTM ..............31
9.5. The 'none' MAC Algorithm ..................................32
9.6. Use with SNMPv1/v2c Messages ..............................32
9.7. MIB Module Security .......................................32
10. IANA Considerations ...........................................33
11. Acknowledgments ...............................................33
12. References ....................................................34
12.1. Normative References .....................................34
12.2. Informative References ...................................35
This memo describes a Transport Model for the Simple Network Management Protocol, using the Secure Shell (SSH) protocol [RFC4251] within a Transport Subsystem [RFC5590]. The Transport Model specified in this memo is referred to as the Secure Shell Transport Model (SSHTM).
本备忘录描述了简单网络管理协议的传输模型，在传输子系统[RFC5590]中使用安全外壳（SSH）协议[RFC4251]。本备忘录中指定的传输模型称为安全外壳传输模型（SSHTM）。
This memo also defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for monitoring and managing the Secure Shell Transport Model for SNMP.
本备忘录还定义了管理信息库（MIB）的一部分，用于基于TCP/IP的Internet中的网络管理协议。特别是，它定义了用于监视和管理SNMP的安全外壳传输模型的对象。
It is important to understand the SNMP architecture [RFC3411] and the terminology of the architecture to understand where the Transport Model described in this memo fits into the architecture and interacts with other subsystems within the architecture.
了解SNMP体系结构[RFC3411]和该体系结构的术语对于理解本备忘录中描述的传输模型在体系结构中的位置以及与体系结构中其他子系统的交互非常重要。
For a detailed overview of the documents that describe the current Internet-Standard Management Framework, please refer to section 7 of RFC 3410 [RFC3410].
有关描述当前互联网标准管理框架的文件的详细概述，请参阅RFC 3410[RFC3410]第7节。
Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. MIB objects are generally accessed through the Simple Network Management Protocol (SNMP). Objects in the MIB are defined using the mechanisms defined in the Structure of Management Information (SMI). This memo specifies a MIB module that is compliant to the SMIv2, which is described in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 [RFC2580].
托管对象通过虚拟信息存储（称为管理信息库或MIB）进行访问。MIB对象通常通过简单网络管理协议（SNMP）进行访问。MIB中的对象是使用管理信息结构（SMI）中定义的机制定义的。本备忘录规定了符合SMIv2的MIB模块，如STD 58、RFC 2578[RFC2578]、STD 58、RFC 2579[RFC2579]和STD 58、RFC 2580[RFC2580]所述。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
Lowercase versions of the keywords should be read as in normal English. They will usually, but not always, be used in a context that relates to compatibility with the RFC 3411 architecture or the subsystem defined here but that might have no impact on on-the-wire compatibility. These terms are used as guidance for designers of proposed IETF models to make the designs compatible with RFC 3411 subsystems and Abstract Service Interfaces (ASIs). Implementers are free to implement differently. Some usages of these lowercase terms are simply normal English usage.
关键字的小写版本应该像普通英语一样阅读。它们通常（但不总是）用于与RFC 3411体系结构或此处定义的子系统的兼容性相关的上下文中，但可能不会影响导线兼容性。这些术语用作建议IETF模型设计者的指南，以使设计与RFC 3411子系统和抽象服务接口（ASI）兼容。实现者可以自由地以不同的方式实现。这些小写术语的一些用法只是普通的英语用法。
For consistency with SNMP-related specifications, this document favors terminology as defined in STD 62, rather than favoring terminology that is consistent with non-SNMP specifications. This is consistent with the IESG decision to not require the SNMPv3 terminology be modified to match the usage of other non-SNMP specifications when SNMPv3 was advanced to Full Standard.
为了与SNMP相关规范保持一致，本文件支持STD 62中定义的术语，而不是与非SNMP规范一致的术语。这与IESG的决定是一致的，即当SNMPv3升级到完整标准时，不要求修改SNMPv3术语以匹配其他非SNMP规范的使用。
"Authentication" in this document typically refers to the English meaning of "serving to prove the authenticity of" the message, not data source authentication or peer identity authentication.
本文档中的“身份验证”通常指“用于证明”消息真实性的英文含义，而不是数据源身份验证或对等身份验证。
The terms "manager" and "agent" are not used in this document because, in the RFC 3411 architecture, all SNMP entities have the capability of acting as manager, agent, or both depending on the SNMP application types supported in the implementation. Where distinction is required, the application names of command generator, command responder, notification originator, notification receiver, and proxy forwarder are used. See "SNMP Applications" [RFC3413] for further information.
本文档中不使用术语“管理器”和“代理”，因为在RFC 3411体系结构中，根据实施中支持的SNMP应用程序类型，所有SNMP实体都具有充当管理器和/或代理的能力。如果需要区分，则使用命令生成器、命令响应者、通知发起人、通知接收方和代理转发器的应用程序名称。有关更多信息，请参阅“SNMP应用程序”[RFC3413]。
The User-based Security Model (USM) [RFC3414] is a mandatory-to-implement Security Model in STD 62. While the SSH and USM specifications frequently refer to a user, the terminology preferred in [RFC3411] and in this memo is "principal". A principal is the "who" on whose behalf services are provided or processing takes place. A principal can be, among other things, an individual acting in a particular role, a set of individuals each acting in a particular role, an application or a set of applications, or a combination of these within an administrative domain.
基于用户的安全模型（USM）[RFC3414]是STD 62中实现安全模型的必备工具。尽管SSH和USM规范经常提及用户，但[RFC3411]和本备忘录中首选的术语是“主体”。委托人是代表其提供服务或进行处理的“谁”。除其他外，委托人可以是以特定角色行事的个人、以特定角色行事的一组个人、一个应用程序或一组应用程序，或者是管理域内这些应用程序的组合。
Throughout this document, the terms "client" and "server" are used to refer to the two ends of the SSH transport connection. The client actively opens the SSH connection, and the server passively listens for the incoming SSH connection. Either SNMP entity may act as client or as server, as discussed further below.
在本文档中，术语“客户机”和“服务器”用于表示SSH传输连接的两端。客户端主动打开SSH连接，服务器被动侦听传入的SSH连接。SNMP实体可以充当客户端或服务器，如下所述。
The reader is expected to have read and understood the description of the SNMP architecture, as defined in [RFC3411], and the Transport Subsystem architecture extension specified in "Transport Subsystem for the Simple Network Management Protocol (SNMP)" [RFC5590].
读者应已阅读并理解[RFC3411]中定义的SNMP体系结构的描述，以及“简单网络管理协议（SNMP）的传输子系统”中指定的传输子系统体系结构扩展[RFC5590]。
This memo describes the Secure Shell Transport Model for SNMP, a specific SNMP Transport Model to be used within the SNMP Transport Subsystem to provide authentication, encryption, and integrity checking of SNMP messages.
本备忘录描述了SNMP的安全外壳传输模型，这是一种特定的SNMP传输模型，在SNMP传输子系统中用于提供SNMP消息的身份验证、加密和完整性检查。
In keeping with the RFC 3411 design decision to use self-contained documents, this document defines the elements of procedure and associated MIB module objects that are needed for processing the Secure Shell Transport Model for SNMP.
根据RFC 3411使用自包含文档的设计决策，本文档定义了处理SNMP安全外壳传输模型所需的过程元素和相关MIB模块对象。
This modularity of specification is not meant to be interpreted as imposing any specific requirements on implementation.
规范的模块化并不意味着对实现强加任何特定的要求。
Version 3 of the Simple Network Management Protocol (SNMPv3) added security to the protocol. The User-based Security Model (USM) [RFC3414] was designed to be independent of other existing security infrastructures to ensure it could function when third-party authentication services were not available, such as in a broken network. As a result, USM utilizes a separate user and key-management infrastructure. Operators have reported that having to deploy another user and key-management infrastructure in order to use SNMPv3 is a reason for not deploying SNMPv3.
简单网络管理协议（SNMPv3）的第3版增加了协议的安全性。基于用户的安全模型（USM）[RFC3414]被设计为独立于其他现有安全基础设施，以确保在第三方身份验证服务不可用时（例如在断开的网络中）能够正常工作。因此，USM利用了一个独立的用户和密钥管理基础架构。运营商报告说，必须部署另一个用户和密钥管理基础设施才能使用SNMPv3是不部署SNMPv3的原因之一。
This memo describes a Transport Model that will make use of the existing and commonly deployed Secure Shell security infrastructure. This Transport Model is designed to meet the security and operational needs of network administrators, maximize usability in operational environments to achieve high deployment success, and at the same time minimize implementation and deployment costs to minimize deployment time.
本备忘录描述了一种传输模型，该模型将利用现有的和通常部署的安全外壳安全基础设施。此传输模型旨在满足网络管理员的安全和操作需求，最大限度地提高操作环境中的可用性以实现高部署成功率，同时最大限度地降低实施和部署成本以缩短部署时间。
This document addresses the requirement for the SSH client to authenticate the SSH server and for the SSH server to authenticate the SSH client, and describes how SNMP can make use of the authenticated identities in authorization policies for data access, in a manner that is independent of any specific Access Control Model.
本文档介绍了SSH客户端对SSH服务器进行身份验证和SSH服务器对SSH客户端进行身份验证的要求，并描述了SNMP如何以独立于任何特定访问控制模型的方式在数据访问的授权策略中使用经身份验证的标识。
This document addresses the requirement to utilize client-authentication and key-exchange methods that support different security infrastructures and provide different security properties. This document describes how to use client authentication as described in "The Secure Shell (SSH) Authentication Protocol" [RFC4252]. The SSH Transport Model should work with any of the ssh-userauth methods, including the "publickey", "password", "hostbased", "none", "keyboard-interactive", "gssapi-with-mic", ."gssapi-keyex", "gssapi", and "external-keyx" (see the SSH Protocol Parameters registry maintained by IANA). The use of the "none" authentication method is NOT RECOMMENDED, as described in this document's Security Considerations. Local accounts may be supported through the use of the publickey, hostbased, or password methods. The password method allows for integration with a deployed password infrastructure, such as Authentication, Authorization, and Accounting (AAA) servers using the RADIUS protocol [RFC2865]. The SSH Transport Model SHOULD be able to take advantage of future-defined ssh-userauth methods, such as those that might make use of X.509 certificate credentials.
本文档阐述了使用支持不同安全基础结构并提供不同安全属性的客户端身份验证和密钥交换方法的要求。本文档描述了如何使用“安全Shell（SSH）身份验证协议”[RFC4252]中描述的客户端身份验证。SSH传输模型应与任何SSH userauth方法一起工作，包括“公钥”、“密码”、“基于主机”、“无”、“键盘交互”、“带麦克风的gssapi”、“gssapi keyex”、“gssapi”和“外部keyx”（请参阅IANA维护的SSH协议参数注册表）。如本文档的安全注意事项所述，不建议使用“无”身份验证方法。可以通过使用公钥、基于主机或密码方法来支持本地帐户。密码方法允许与已部署的密码基础设施集成，例如使用RADIUS协议的身份验证、授权和记帐（AAA）服务器[RFC2865]。SSH传输模型应该能够利用将来定义的SSH userauth方法，例如那些可能使用X.509证书凭据的方法。
It is desirable to use mechanisms that could unify the approach for administrative security for SNMPv3 and command line interfaces (CLI) and other management interfaces. The use of security services provided by Secure Shell is the approach commonly used for the CLI and is the approach being adopted for use with NETCONF [RFC4742]. This memo describes a method for invoking and running the SNMP protocol within a Secure Shell (SSH) session as an SSH Subsystem.
希望使用能够统一SNMPv3和命令行界面（CLI）以及其他管理界面的管理安全方法的机制。使用Secure Shell提供的安全服务是CLI常用的方法，也是NETCONF[RFC4742]使用的方法。本备忘录描述了在安全Shell（SSH）会话中作为SSH子系统调用和运行SNMP协议的方法。
This memo describes how SNMP can be used within a Secure Shell (SSH) session, using the SSH connection protocol [RFC4254] over the SSH transport protocol, and using ssh-userauth [RFC4252] for authentication.
本备忘录描述了如何在安全Shell（SSH）会话中使用SNMP，通过SSH传输协议使用SSH连接协议[RFC4254]，并使用SSH userauth[RFC4252]进行身份验证。
There are a number of challenges to be addressed to map Secure Shell authentication method parameters into the SNMP architecture so that SNMP continues to work without any surprises. These are discussed in detail below.
要将安全Shell身份验证方法参数映射到SNMP体系结构中，使SNMP继续工作而不会出现任何意外情况，需要解决许多难题。下文将详细讨论这些问题。
The design of this SNMP Transport Model is influenced by the following constraints:
此SNMP传输模型的设计受以下约束的影响：
1. In times of network stress, the transport protocol and its underlying security mechanisms SHOULD NOT depend upon the ready availability of other network services (e.g., Network Time Protocol (NTP) or AAA protocols).
1. 在网络压力下，传输协议及其底层安全机制不应依赖于其他网络服务（例如，网络时间协议（NTP）或AAA协议）的可用性。
2. When the network is not under stress, the Transport Model and its underlying security mechanisms MAY depend upon the ready availability of other network services.
2. 当网络没有压力时，传输模型及其底层安全机制可能取决于其他网络服务的可用性。
3. It may not be possible for the Transport Model to determine when the network is under stress.
3. 传输模型可能无法确定网络何时处于压力之下。
4. A Transport Model SHOULD NOT require changes to the SNMP architecture.
4. 传输模型不应要求更改SNMP体系结构。
5. A Transport Model SHOULD NOT require changes to the underlying security protocol.
5. 传输模型不应要求更改基础安全协议。
SSH is a protocol for secure remote login and other secure network services over an insecure network. It consists of three major protocol components and add-on methods for user authentication:
SSH是一种用于在不安全网络上安全远程登录和其他安全网络服务的协议。它由三个主要的协议组件和用于用户身份验证的附加方法组成：
o The Transport Layer Protocol [RFC4253] provides server authentication and message 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 传输层协议[RFC4253]提供服务器身份验证、消息机密性和完整性。它还可以选择性地提供压缩。传输层通常通过TCP/IP连接运行，但也可能用于任何其他可靠数据流之上。
o The User Authentication Protocol [RFC4252] authenticates the client-side principal to the server. It runs over the Transport Layer Protocol.
o 用户身份验证协议[RFC4252]向服务器验证客户端主体。它通过传输层协议运行。
o The Connection Protocol [RFC4254] multiplexes the encrypted tunnel into several logical channels. It runs over the transport after successfully authenticating the principal.
o 连接协议[RFC4254]将加密隧道多路复用到多个逻辑通道中。它在成功验证主体后在传输上运行。
o Generic Message Exchange Authentication [RFC4256] is a general purpose authentication method for the SSH protocol, suitable for interactive authentications where the authentication data should be entered via a keyboard.
o 通用消息交换身份验证[RFC4256]是SSH协议的通用身份验证方法，适用于交互式身份验证，其中身份验证数据应通过键盘输入。
o "Generic Security Service Application Program Interface (GSS-API) Authentication and Key Exchange for the Secure Shell (SSH) Protocol" [RFC4462] describes methods for using the GSS-API for authentication and key exchange in SSH. It defines an SSH user-authentication method that uses a specified GSS-API mechanism to authenticate a user; it also defines a family of SSH key-exchange methods that use GSS-API to authenticate a Diffie-Hellman key exchange.
o “通用安全服务应用程序接口（GSS-API）安全外壳（SSH）协议的身份验证和密钥交换”[RFC4462]描述了在SSH中使用GSS-API进行身份验证和密钥交换的方法。它定义了一种SSH用户身份验证方法，该方法使用指定的GSS-API机制对用户进行身份验证；它还定义了一系列SSH密钥交换方法，这些方法使用GSS-API对Diffie-Hellman密钥交换进行身份验证。
The client sends a service request once a secure, transport-layer connection has been established. A second service request is sent after client 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连接的标准方法。
A Transport Model is a component of the Transport Subsystem [RFC5590] within the SNMP architecture. The SSH Transport Model thus fits between the underlying SSH transport layer and the Message Dispatcher [RFC3411].
传输模型是SNMP体系结构中传输子系统[RFC5590]的一个组件。因此，SSH传输模型适合于底层SSH传输层和消息调度器[RFC3411]。
The SSH Transport Model will establish a channel between itself and the SSH Transport Model of another SNMP engine. The sending Transport Model passes unencrypted messages from the Dispatcher to SSH to be encrypted, and the receiving Transport Model accepts decrypted incoming messages from SSH and passes them to the Dispatcher.
SSH传输模型将在自身和另一个SNMP引擎的SSH传输模型之间建立通道。发送传输模型将未加密的消息从Dispatcher传递到要加密的SSH，接收传输模型接受来自SSH的解密传入消息并将其传递给Dispatcher。
After an SSH Transport Model channel is established, then SNMP messages can conceptually be sent through the channel from one SNMP Message Dispatcher to another SNMP Message Dispatcher. Multiple SNMP messages MAY be passed through the same channel.
建立SSH传输模型通道后，从概念上讲，可以通过通道将SNMP消息从一个SNMP消息调度程序发送到另一个SNMP消息调度程序。多个SNMP消息可以通过同一通道传递。
The SSH Transport Model of an SNMP engine will perform the translation between SSH-specific security parameters and SNMP-specific, model-independent parameters.
SNMP引擎的SSH传输模型将在SSH特定的安全参数和SNMP特定的、与模型无关的参数之间执行转换。
The Secure Shell Transport Model provides protection against the threats identified by the RFC 3411 architecture [RFC3411]:
安全外壳传输模型针对RFC 3411体系结构[RFC3411]识别的威胁提供保护：
1. Modification of Information - SSH provides for verification that the contents of each message have not been modified during its transmission through the network by digitally signing each SSH packet.
1. 修改信息—SSH通过对每个SSH数据包进行数字签名，验证每条消息在通过网络传输期间的内容是否未被修改。
2. Masquerade - SSH provides for verification of the identity of the SSH server and the identity of the SSH client.
2. Masquerade-SSH用于验证SSH服务器的身份和SSH客户端的身份。
SSH provides for verification of the identity of the SSH server through the SSH transport protocol server authentication [RFC4253]. This allows an operator or management station to ensure the authenticity of the SNMP engine that provides MIB data.
SSH通过SSH传输协议服务器身份验证[RFC4253]来验证SSH服务器的身份。这允许操作员或管理站确保提供MIB数据的SNMP引擎的真实性。
SSH provides a number of mechanisms for verification of the identity of the SSH client-side principal using the Secure Shell Authentication Protocol [RFC4252]. These include public key, password, and host-based mechanisms. This allows the SNMP Access Control Subsystem to ensure that only authorized principals have access to potentially sensitive data.
SSH提供了许多机制，用于使用安全Shell身份验证协议[RFC4252]验证SSH客户端主体的身份。这些机制包括公钥、密码和基于主机的机制。这允许SNMP访问控制子系统确保只有经过授权的主体才能访问潜在的敏感数据。
Verification of the client's principal identity is important for use with the SNMP Access Control Subsystem to ensure that only authorized principals have access to potentially sensitive data.
验证客户端的主体身份对于与SNMP访问控制子系统一起使用非常重要，以确保只有经过授权的主体才能访问潜在的敏感数据。
The SSH user identity is provided to the Transport Model, so it can be used to map to an SNMP model-independent securityName for use with SNMP access control and notification configuration. (The identity may undergo various transforms before it maps to the securityName.)
SSH用户标识提供给传输模型，因此可以使用它映射到与SNMP模型无关的securityName，以便与SNMP访问控制和通知配置一起使用。（标识在映射到securityName之前可能会经历各种转换。）
3. Message Stream Modification - SSH protects against malicious re-ordering or replaying of messages within a single SSH session by using sequence numbers and integrity checks. SSH protects against replay of messages across SSH sessions by ensuring that the cryptographic keys used for encryption and integrity checks are generated afresh for each session.
3. 消息流修改-SSH通过使用序列号和完整性检查，防止在单个SSH会话中恶意重新排序或重播消息。SSH通过确保为每个会话重新生成用于加密和完整性检查的加密密钥，防止跨SSH会话重播消息。
4. Disclosure - SSH provides protection against the disclosure of information to unauthorized recipients or eavesdroppers by allowing for encryption of all traffic between SNMP engines.
4. 披露-SSH允许对SNMP引擎之间的所有通信进行加密，从而防止信息泄露给未经授权的收件人或窃听者。
The RFC 3411 architecture recognizes three levels of security:
RFC 3411体系结构可识别三个安全级别：
- without authentication and without privacy (noAuthNoPriv)
- 没有身份验证和隐私（noAuthNoPriv）
- with authentication but without privacy (authNoPriv)
- 具有身份验证但不具有隐私（authNoPriv）
- with authentication and with privacy (authPriv)
- 具有身份验证和隐私（authPriv）
The Secure Shell protocol provides support for encryption and data integrity. While it is technically possible to support no authentication and no encryption in SSH, it is NOT RECOMMENDED by [RFC4253].
Secure Shell协议支持加密和数据完整性。虽然在SSH中不支持身份验证和加密在技术上是可行的，但[RFC4253]不建议这样做。
The SSH Transport Model determines from SSH the identity of the authenticated principal and the type and address associated with an incoming message, and provides this information to SSH for an outgoing message. The SSH transport-layer algorithms used to provide authentication, data integrity, and encryption SHOULD NOT be exposed to the SSH Transport Model layer. The SNMPv3 WG deliberately avoided this and settled for an assertion by the Security Model that the requirements of securityLevel were met. The SSH Transport Model has no mechanisms by which it can test whether an underlying SSH connection provides auth or priv, so the SSH Transport Model trusts that the underlying SSH connection has been properly configured to support authPriv security characteristics.
SSH传输模型通过SSH确定经过身份验证的主体的身份以及与传入消息关联的类型和地址，并为传出消息向SSH提供此信息。用于提供身份验证、数据完整性和加密的SSH传输层算法不应向SSH传输模型层公开。SNMPv3工作组故意避免了这一点，并接受了安全模型的断言，即满足了securityLevel的要求。SSH传输模型没有可以测试底层SSH连接是否提供auth或priv的机制，因此SSH传输模型相信底层SSH连接已正确配置为支持authPriv安全特性。
An SSH Transport-Model-compliant implementation MUST use an SSH connection that provides authentication, data integrity, and encryption that meets the highest level of SNMP security (authPriv). Outgoing messages specified with a securityLevel of noAuthNoPriv or authNoPriv are actually sent by the SSH Transport Model with authPriv-level protection.
符合SSH传输模型的实现必须使用SSH连接，该连接提供符合最高SNMP安全级别（authPriv）的身份验证、数据完整性和加密。使用securityLevel noAuthNoPriv或authNoPriv指定的传出消息实际上由具有authPriv级别保护的SSH传输模型发送。
The security protocols used in the Secure Shell Authentication Protocol [RFC4252] and the Secure Shell Transport Layer Protocol [RFC4253] are considered acceptably secure at the time of writing. However, the procedures allow for new authentication and privacy methods to be specified at a future time if the need arises.
在撰写本文时，安全外壳认证协议[RFC4252]和安全外壳传输层协议[RFC4253]中使用的安全协议被认为是可接受的安全协议。但是，如果需要，这些程序允许在将来指定新的身份验证和隐私方法。
The SSH Transport Model should support any server- or client-authentication mechanism supported by SSH. This includes the three authentication methods described in the SSH Authentication Protocol document [RFC4252] (publickey, password, and host-based), keyboard interactive, and others.
SSH传输模型应该支持SSH支持的任何服务器或客户端身份验证机制。这包括SSH身份验证协议文档[RFC4252]中描述的三种身份验证方法（公钥、密码和基于主机）、键盘交互和其他方法。
The password-authentication mechanism allows for integration with deployed password-based infrastructure. It is possible to hand a password to a service such as RADIUS [RFC2865] or Diameter [RFC3588] for validation. The validation could be done using the user name and user password attributes. It is also possible to use a different password-validation protocol such as the Challenge Handshake Authentication Protocol (CHAP) [RFC1994] or digest authentication [RFC5090] to integrate with RADIUS or Diameter. At some point in the processing, these mechanisms require the password to be made available as cleartext on the device that is authenticating the password, which might introduce threats to the authentication infrastructure.
密码身份验证机制允许与部署的基于密码的基础架构集成。可以将密码交给RADIUS[RFC2865]或Diameter[RFC3588]等服务进行验证。可以使用用户名和用户密码属性进行验证。还可以使用不同的密码验证协议，例如质询握手验证协议（CHAP）[RFC1994]或摘要验证[RFC5090]来与RADIUS或Diameter集成。在处理过程中的某个时刻，这些机制要求在验证密码的设备上以明文形式提供密码，这可能会对验证基础设施造成威胁。
GSS-API key exchange [RFC4462] provides a framework for the addition of client-authentication mechanisms that support different security infrastructures and provide different security properties. Additional authentication mechanisms, such as one that supports X.509 certificates, may be added to SSH in the future.
GSS-API密钥交换[RFC4462]提供了一个框架，用于添加支持不同安全基础架构并提供不同安全属性的客户端身份验证机制。将来可能会将其他身份验证机制（例如支持X.509证书的机制）添加到SSH中。
This document describes the use of an SSH Subsystem for SNMP to make SNMP usage distinct from other usages.
本文档描述了SNMP的SSH子系统的使用，以使SNMP的使用与其他使用不同。
An SSH Subsystem of type "snmp" is opened by the SSH Transport Model during the elements of procedure for an outgoing SNMP message. Since the sender of a message initiates the creation of an SSH session if needed, the SSH session will already exist for an incoming message; otherwise, the incoming message would never reach the SSH Transport Model.
在传出snmp消息的过程元素期间，SSH传输模型将打开类型为“snmp”的SSH子系统。由于消息的发送方在需要时启动SSH会话的创建，因此传入消息的SSH会话将已经存在；否则，传入消息将永远不会到达SSH传输模型。
Implementations may choose to instantiate SSH sessions in anticipation of outgoing messages. This approach might be useful to ensure that an SSH session to a given target can be established before it becomes important to send a message over the SSH session. Of course, there is no guarantee that a pre-established session will still be valid when needed.
实现可以选择实例化SSH会话，以预期传出消息。这种方法可能有助于确保在通过SSH会话发送消息变得重要之前，可以建立到给定目标的SSH会话。当然，不能保证预先建立的会话在需要时仍然有效。
SSH sessions are uniquely identified within the SSH Transport Model by the combination of tmTransportAddress and tmSecurityName associated with each session.
SSH会话在SSH传输模型中通过与每个会话关联的tmTransportAddress和tmSecurityName的组合进行唯一标识。
Because naming policies might differ between administrative domains, many SSH client software packages support a user@hostname:port addressing syntax that operators can use to align non-equivalent account names. The SnmpSSHAddress Textual Convention echos this common SSH notation.
由于管理域之间的命名策略可能不同，因此许多SSH客户端软件包支持user@hostname：操作员可用于对齐非等效帐户名的端口寻址语法。SnmpSSHAddress文本约定呼应了这种常见的SSH表示法。
When this notation is used in an SnmpSSHAddress, the SSH connection should be established with an SSH user name matching the "user" portion of the notation when establishing a session with the remote SSH server. The user name must be encoded in UTF-8 (per [RFC4252]). The "user" portion may or may not match the tmSecurityName parameter passed from the Security Model. If no "user@" portion is specified in the SnmpSSHAddress, then the SSH connection should be established using the tmSecurityName as the SSH user name when establishing a session with the remote SSH server.
当在SnmpSSHAddress中使用此符号时，应使用与远程SSH服务器建立会话时与符号的“用户”部分匹配的SSH用户名建立SSH连接。用户名必须用UTF-8编码（根据[RFC4252]）。“用户”部分可能与从安全模型传递的tmSecurityName参数匹配，也可能与之不匹配。如果在SnmpSSHAddress中未指定“user@”部分，则在与远程SSH服务器建立会话时，应使用tmSecurityName作为SSH用户名来建立SSH连接。
The SnmpSSHAddress and tmSecurityName associated with an SSH session MUST remain constant during the life of the session. Different SnmpSSHAddress values (with different hostnames, "user@" prefix names, and/or port numbers) will each result in individual SSH sessions.
与SSH会话关联的SnmpSSHAddress和tmSecurityName必须在会话生命周期内保持不变。不同的SnmpSSHAddress值（具有不同的主机名、“user@”前缀名和/或端口号）将分别导致单独的SSH会话。
For incoming messages, SSH-specific security parameters are translated by the Transport Model into security parameters independent of the Transport and Security Models. The Transport Model accepts messages from the SSH Subsystem, records the transport-related and SSH-security-related information, including the authenticated identity, in a cache referenced by tmStateReference, and passes the WholeMsg and the tmStateReference to the Dispatcher using the receiveMessage() ASI (Abstract Service Interface).
对于传入消息，SSH特定的安全参数由传输模型转换为独立于传输和安全模型的安全参数。传输模型接受来自SSH子系统的消息，将传输相关信息和SSH安全相关信息（包括经过身份验证的标识）记录在由tmStateReference引用的缓存中，并使用receiveMessage（）ASI（抽象服务接口）将整个MSG和tmStateReference传递给调度程序。
For outgoing messages, the Transport Model takes input provided by the Dispatcher in the sendMessage() ASI. The SSH Transport Model converts that information into suitable security parameters for SSH, establishes sessions as needed, and passes messages to the SSH Subsystem for sending.
对于传出消息，传输模型将接收发送器在sendMessage（）ASI中提供的输入。SSH传输模型将该信息转换为适合SSH的安全参数，根据需要建立会话，并将消息传递给SSH子系统进行发送。
SSH connections may be initiated by command generators or by notification originators. Command generators are frequently operated by a human, but notification originators are usually unmanned automated processes. As a result, it may be necessary to provision authentication credentials on the SNMP engine containing the notification originator or to use a third-party key provider, such as Kerberos, so the engine can successfully authenticate to an engine containing a notification receiver.
SSH连接可以由命令生成器或通知发起者启动。命令生成器通常由人工操作，但通知发起者通常是无人操作的自动化流程。因此，可能需要在包含通知发起人的SNMP引擎上提供身份验证凭据，或者使用第三方密钥提供程序（如Kerberos），以便引擎能够成功地向包含通知接收方的引擎进行身份验证。
The targets to whom notifications or proxy requests should be sent is typically determined and configured by a network administrator. The SNMP-NOTIFICATION-MIB contains a list of targets to which notifications should be sent. The SNMP-TARGET-MIB module [RFC3413] contains objects for defining these management targets, including transport domains and addresses and security parameters, for applications such as notification generators and proxy forwarders.
通知或代理请求应发送到的目标通常由网络管理员确定和配置。SNMP-NOTIFICATION-MIB包含应向其发送通知的目标列表。SNMP-TARGET-MIB模块[RFC3413]包含用于为通知生成器和代理转发器等应用程序定义这些管理目标的对象，包括传输域、地址和安全参数。
For the SSH Transport Model, transport type and address are configured in the snmpTargetAddrTable, and the securityName and securityLevel parameters are configured in the snmpTargetParamsTable. The default approach is for an administrator to statically preconfigure this information to identify the targets authorized to receive notifications or received proxied messages. Local access-
对于SSH传输模型，传输类型和地址在SNMPTargetADRDR表中配置，securityName和securityLevel参数在snmpTargetParamsTable中配置。默认方法是管理员静态预配置此信息，以标识授权接收通知或接收代理消息的目标。本地访问-
control processing needs to be performed by a notification originator before notifications are actually sent, and this processing is done using the configured securityName. An important characteristic of this is that authorization is done prior to determining if the connection can succeed. Thus, the locally configured securityName is entirely trusted within the notification originator.
在实际发送通知之前，控制处理需要由通知发起人执行，并且此处理是使用配置的securityName完成的。这方面的一个重要特征是，在确定连接是否成功之前进行授权。因此，本地配置的securityName在通知发起人中完全受信任。
The SNMP-TARGET-MIB and NOTIFICATION-MIB MIB modules may be configured using SNMP or other implementation-dependent mechanisms, such as CLI scripting or loading a configuration file. It may be necessary to provide additional implementation-specific configuration of SSH parameters.
SNMP-TARGET-MIB和NOTIFICATION-MIB MIB模块可以使用SNMP或其他依赖于实现的机制（例如CLI脚本编写或加载配置文件）进行配置。可能需要提供SSH参数的其他特定于实现的配置。
When performing SNMP processing, there are two levels of state information that may need to be retained: the immediate state linking a request-response pair and a potentially longer-term state relating to transport and security. "Transport Subsystem for the Simple Network Management Protocol" [RFC5590] defines general requirements for caches and references.
在执行SNMP处理时，可能需要保留两个级别的状态信息：链接请求-响应对的即时状态和与传输和安全性相关的潜在长期状态。“简单网络管理协议的传输子系统”[RFC5590]定义了缓存和引用的一般要求。
This document defines additional cache requirements related to the Secure Shell Transport Model.
本文档定义了与Secure Shell传输模型相关的其他缓存要求。
The Secure Shell Transport Model has specific responsibilities regarding the cached information. See the Elements of Procedure in Section 5 for detailed processing instructions on the use of the tmStateReference fields by the SSH Transport Model.
安全Shell传输模型对缓存的信息负有特定的责任。有关SSH传输模型使用tmStateReference字段的详细处理说明，请参见第5节中的过程元素。
The tmSecurityName MUST be a human-readable name (in snmpAdminString format) representing the identity that has been set according to the procedures in Section 5. The tmSecurityName MUST be constant for all traffic passing through an SSHTM session. Messages MUST NOT be sent through an existing SSH session that was established using a different tmSecurityName.
tmSecurityName必须是人类可读的名称（SNMPAdministring格式），表示根据第5节中的过程设置的标识。对于通过SSHTM会话的所有流量，tmSecurityName必须为常量。消息不得通过使用其他tmSecurityName建立的现有SSH会话发送。
On the SSH server side of a connection:
在连接的SSH服务器端：
The tmSecurityName should be the SSH user name. How the SSH user name is extracted from the SSH layer is implementation-dependent.
tmSecurityName应该是SSH用户名。如何从SSH层提取SSH用户名取决于实现。
The SSH protocol is not always clear on whether the user name field must be filled in, so for some implementations, such as those using GSSAPI authentication, it may be necessary to use a mapping algorithm to transform an SSH identity to a tmSecurityName or to transform a tmSecurityName to an SSH identity.
SSH协议并不总是清楚是否必须填写用户名字段，因此对于某些实现，例如使用GSSAPI身份验证的实现，可能需要使用映射算法将SSH标识转换为tmSecurityName或将tmSecurityName转换为SSH标识。
In other cases, the user name may not be verified by the server, so for these implementations, it may be necessary to obtain the user name from other credentials exchanged during the SSH exchange.
在其他情况下，服务器可能不会验证用户名，因此对于这些实现，可能需要从SSH交换期间交换的其他凭据中获取用户名。
On the SSH client side of a connection:
在连接的SSH客户端上：
The tmSecurityName is presented to the SSH Transport Model by the application (possibly because of configuration specified in the SNMP-TARGET-MIB).
tmSecurityName由应用程序提供给SSH传输模型（可能是因为SNMP-TARGET-MIB中指定的配置）。
The securityName MAY be derived from the tmSecurityName by a Security Model and MAY be used to configure notifications and access controls in MIB modules. Transport Models SHOULD generate a predictable tmSecurityName so operators will know what to use when configuring MIB modules that use securityNames derived from tmSecurityNames.
securityName可通过安全模型从tmSecurityName派生，并可用于配置MIB模块中的通知和访问控制。传输模型应生成可预测的tmSecurityName，以便操作员在配置使用从tmSecurityName派生的SecurityName的MIB模块时知道使用什么。
The tmSessionID MUST be recorded per message at the time of receipt. When tmSameSecurity is set, the recorded tmSessionID can be used to determine whether the SSH session available for sending a corresponding outgoing message is the same SSH session as was used when receiving the incoming message (e.g., a response to a request).
必须在收到每条消息时记录TMSSessionID。设置tmSameSecurity时，记录的TMSSessionID可用于确定可用于发送相应传出消息的SSH会话是否与接收传入消息时使用的SSH会话相同（例如，对请求的响应）。
The per-session state that is referenced by tmStateReference may be saved across multiple messages in a Local Configuration Datastore. Additional session/connection state information might also be stored in a Local Configuration Datastore.
tmStateReference引用的每会话状态可以跨本地配置数据存储中的多条消息保存。其他会话/连接状态信息也可能存储在本地配置数据存储中。
Abstract Service Interfaces have been defined by [RFC3411] and further augmented by [RFC5590] to describe the conceptual data flows between the various subsystems within an SNMP entity. The Secure Shell Transport Model uses some of these conceptual data flows when communicating between subsystems.
抽象服务接口由[RFC3411]定义，并由[RFC5590]进一步扩展，以描述SNMP实体内各子系统之间的概念数据流。安全Shell传输模型在子系统之间进行通信时使用其中一些概念数据流。
To simplify the elements of procedure, the release of state information is not always explicitly specified. As a general rule, if state information is available when a message gets discarded, the message-state information should also be released, and if state information is available when a session is closed, the session-state information should also be released.
为了简化过程的元素，并不总是明确指定状态信息的发布。作为一般规则，如果消息被丢弃时状态信息可用，则还应释放消息状态信息，如果会话关闭时状态信息可用，则还应释放会话状态信息。
An error indication in statusInformation will typically include the Object Identifier (OID) and value for an incremented error counter. This may be accompanied by the requested securityLevel and the tmStateReference. Per-message context information is not accessible to Transport Models, so for the returned counter OID and value, contextEngine would be set to the local value of snmpEngineID and contextName to the default context for error counters.
statusInformation中的错误指示通常包括对象标识符（OID）和递增错误计数器的值。这可能伴随着请求的securityLevel和tmStateReference。传输模型无法访问每条消息的上下文信息，因此对于返回的计数器OID和值，contextEngine将设置为snmpEngineID的本地值，contextName将设置为错误计数器的默认上下文。
1. The SSH Transport Model queries the SSH engine, in an implementation-dependent manner, to determine the address the message originated from, the user name authenticated by SSH, and a session identifier.
1. SSH传输模型以依赖于实现的方式查询SSH引擎，以确定消息来源的地址、SSH验证的用户名以及会话标识符。
2. Determine the tmTransportAddress to be associated with the incoming message:
2. 确定要与传入消息关联的tmTransportAddress：
A. If this is a client-side SSH session, then the tmTransportAddress is set to the tmTransportAddress used to establish the session. It MUST exactly include any "user@" prefix associated with the address provided to the openSession() ASI.
A.如果这是一个客户端SSH会话，则tmTransportAddress设置为用于建立会话的tmTransportAddress。它必须完全包含与提供给openSession（）ASI的地址相关联的任何“user@”前缀。
B. If this is a server-side SSH session and this is the first message received over the session, then the tmTransportAddress is set to the address the message originated from, determined in an implementation-dependent way. This value MUST be constant for the entire SSH session, and future messages received MUST result in the tmTransportAddress being set to the same value.
B.如果这是一个服务器端SSH会话，并且这是通过会话接收到的第一条消息，那么tmTransportAddress将被设置为消息的源地址，并以依赖于实现的方式确定。对于整个SSH会话，该值必须是常量，将来收到的消息必须将tmTransportAddress设置为相同的值。
C. If this is a server-side SSH session and this is not the first message received over the session, then the tmTransportAddress is set to the previously established tmTransportAddress for the session (the value from step B, determined from a previous incoming message).
C.如果这是一个服务器端SSH会话，并且这不是通过该会话接收到的第一条消息，则tmTransportAddress将设置为先前为该会话建立的tmTransportAddress（步骤B中的值，由先前传入的消息确定）。
3. Determine the tmSecurityName to be associated with the incoming message:
3. 确定要与传入消息关联的tmSecurityName：
A. If this is a client-side SSH session, then the tmSecurityName MUST be set to the tmSecurityName used to establish the session.
A.如果这是客户端SSH会话，则必须将tmSecurityName设置为用于建立会话的tmSecurityName。
B. If this is a server-side SSH session and this is the first message received over the session, then the tmSecurityName is set to the SSH user name. How the SSH user name is extracted from the SSH layer is implementation-dependent. This value MUST be constant for the entire SSH session, and future messages received MUST result in the tmSecurityName being set to the same value.
B.如果这是一个服务器端SSH会话，并且这是通过该会话收到的第一条消息，那么tmSecurityName将设置为SSH用户名。如何从SSH层提取SSH用户名取决于实现。对于整个SSH会话，该值必须是常量，并且将来收到的消息必须将tmSecurityName设置为相同的值。
C. If this is a server-side SSH session and this is not the first message received over the session, then the tmSecurityName is set to the previously established tmSecurityName for the session (the value from step B, determined from a previous incoming message).
C.如果这是一个服务器端SSH会话，并且这不是通过该会话接收到的第一条消息，则将tmSecurityName设置为先前为该会话建立的tmSecurityName（步骤B中的值，根据先前传入的消息确定）。
4. Create a tmStateReference cache for subsequent reference to the information.
4. 创建一个引用缓存，以便后续引用该信息。
tmTransportDomain = snmpSSHDomain
tmTransportDomain = snmpSSHDomain
tmTransportAddress = the derived tmTransportAddress from step 2.
tmTransportAddress=步骤2中派生的tmTransportAddress。
tmSecurityName = the derived tmSecurityName from step 3.
tmSecurityName=从步骤3派生的tmSecurityName。
tmTransportSecurityLevel = "authPriv" (authentication and confidentiality MUST be used to comply with this Transport Model.)
tmTransportSecurityLevel=“authPriv”（必须使用身份验证和机密性来遵守此传输模型。）
tmSessionID = an implementation-dependent value that can be used to detect when a session has closed and been replaced by another session. The value in tmStateReference MUST uniquely identify the session over which the message was received. This session identifier MUST NOT be reused until there are no references to it remaining.
TMSSessionId=一个依赖于实现的值，可用于检测会话何时关闭并被另一个会话替换。tmStateReference中的值必须唯一标识接收消息的会话。在没有对该会话标识符的引用之前，不得重用该会话标识符。
Then the Transport Model passes the message to the Dispatcher using the following ASI:
然后，传输模型使用以下ASI将消息传递给调度程序：
statusInformation =
receiveMessage(
IN transportDomain -- snmpSSHDomain
IN transportAddress -- the tmTransportAddress for the message
IN wholeMessage -- the whole SNMP message from SSH
IN wholeMessageLength -- the length of the SNMP message
IN tmStateReference -- (NEW) transport info
)
statusInformation =
receiveMessage(
IN transportDomain -- snmpSSHDomain
IN transportAddress -- the tmTransportAddress for the message
IN wholeMessage -- the whole SNMP message from SSH
IN wholeMessageLength -- the length of the SNMP message
IN tmStateReference -- (NEW) transport info
)
The Dispatcher passes the information to the Transport Model using the ASI defined in the Transport Subsystem:
调度员使用传输子系统中定义的ASI将信息传递给传输模型：
statusInformation =
sendMessage(
IN destTransportDomain -- transport domain to be used
IN destTransportAddress -- transport address to be used
IN outgoingMessage -- the message to send
IN outgoingMessageLength -- its length
IN tmStateReference -- (NEW) transport info
)
statusInformation =
sendMessage(
IN destTransportDomain -- transport domain to be used
IN destTransportAddress -- transport address to be used
IN outgoingMessage -- the message to send
IN outgoingMessageLength -- its length
IN tmStateReference -- (NEW) transport info
)
The SSH Transport Model performs the following tasks.
SSH传输模型执行以下任务。
1. If tmStateReference does not refer to a cache containing values for tmTransportDomain, tmTransportAddress, tmSecurityName, tmRequestedSecurityLevel, and tmSameSecurity, then increment the snmpSshtmSessionInvalidCaches counter, discard the message, and return the error indication in the statusInformation. Processing of this message stops.
1. 如果tmStateReference未引用包含tmTransportDomain、tmTransportAddress、TMSSecurityName、tmRequestedSecurityLevel和tmSameSecurity值的缓存，则递增snmpSshtmSessionInvalidCaches计数器，丢弃消息，并在状态信息中返回错误指示。此消息的处理将停止。
2. Extract the tmTransportDomain, tmTransportAddress, tmSecurityName, tmRequestedSecurityLevel, tmSameSecurity, and tmSessionID from the tmStateReference.
2. 从tmStateReference中提取tmTransportDomain、tmTransportAddress、TMSSecurityName、tmRequestedSecurityLevel、tmSameSecurity和TMSSessionID。
3. Identify an SSH session over which to send the messages:
3. 确定要通过其发送消息的SSH会话：
A. If tmSameSecurity is true and there is no existing session with a matching tmSessionID, tmSecurityName, and tmTransportAddress, then increment the snmpSshtmSessionNoSessions counter, discard the message, and return the error indication in the statusInformation. Processing of this message stops.
A.如果tmSameSecurity为true，且不存在具有匹配的TMSSessionID、TMSSecurityName和tmTransportAddress的现有会话，则递增snmpSshtmSessionNoSessions计数器，丢弃消息，并在状态信息中返回错误指示。此消息的处理将停止。
B. If there is a session with a matching tmSessionID, tmTransportAddress, and tmSecurityName, then select that session.
B.如果存在具有匹配的TMSSessionID、tmTransportAddress和tmSecurityName的会话，则选择该会话。
C. If there is a session that matches the tmTransportAddress and tmSecurityName, then select that session.
C.如果存在与tmTransportAddress和tmSecurityName匹配的会话，则选择该会话。
D. If the above steps failed to select a session to use, then call openSession() with the tmStateReference as a parameter.
D.如果上述步骤未能选择要使用的会话，则使用tmStateReference作为参数调用openSession（）。
+ If openSession fails, then discard the message, release tmStateReference, and pass the error indication returned by openSession back to the calling module. Processing of this message stops.
+ 如果openSession失败，则丢弃消息，释放tmStateReference，并将openSession返回的错误指示传递回调用模块。此消息的处理将停止。
+ If openSession succeeds, then record the destTransportDomain, destTransportAddress, tmSecurityname, and tmSessionID in an implementation-dependent manner. This will be needed when processing an incoming message.
+ 如果openSession成功，则以依赖于实现的方式记录destTransportDomain、destTransportAddress、tmSecurityname和TMSSessionID。在处理传入消息时，需要这样做。
4. Pass the wholeMessage to SSH for encapsulation as data in an SSH message over the identified SSH session. Any necessary additional SSH-specific parameters should be provided in an implementation-dependent manner.
4. 将整个消息传递给SSH，以便通过标识的SSH会话将其封装为SSH消息中的数据。应以依赖于实现的方式提供任何必要的附加SSH特定参数。
The Secure Shell Transport Model provides the following Abstract Service Interface (ASI) to describe the data passed between the SSH Transport Model and the SSH service. It is an implementation decision how such data is passed.
Secure Shell传输模型提供以下抽象服务接口（ASI）来描述SSH传输模型和SSH服务之间传递的数据。如何传递此类数据是一个实现决策。
statusInformation =
openSession(
IN tmStateReference -- transport information to be used
OUT tmStateReference -- transport information to be used
IN maxMessageSize -- of the sending SNMP entity
)
statusInformation =
openSession(
IN tmStateReference -- transport information to be used
OUT tmStateReference -- transport information to be used
IN maxMessageSize -- of the sending SNMP entity
)
The following describes the procedure to follow to establish a session between a client and server to run SNMP over SSH. This process is used by any SNMP engine establishing a session for subsequent use.
以下描述了在客户端和服务器之间建立会话以通过SSH运行SNMP的过程。此过程由任何建立会话以供后续使用的SNMP引擎使用。
This will be done automatically for an SNMP application that initiates a transaction, such as a command generator, a notification originator, or a proxy forwarder.
对于启动事务的SNMP应用程序（如命令生成器、通知发起人或代理转发器），这将自动完成。
1. Increment the snmpSshtmSessionOpens counter.
1. 递增snmpSshtmSessionOpens计数器。
2. Using tmTransportAddress, the client will establish an SSH transport connection using the SSH transport protocol, authenticate the server, and exchange keys for message integrity and encryption. The transportAddress associated with a session MUST remain constant during the lifetime of the SSH session. Implementations may need to cache the transportAddress passed to the openSession API for later use when performing incoming message processing (see Section 5.1).
2. 使用tmTransportAddress，客户端将使用SSH传输协议建立SSH传输连接，对服务器进行身份验证，并交换消息完整性和加密的密钥。在SSH会话的生存期内，与会话关联的transportAddress必须保持不变。实现可能需要缓存传递给openSession API的transportAddress，以便以后在执行传入消息处理时使用（请参阅第5.1节）。
1. To authenticate the server, the client usually stores pairs (tmTransportAddress, server host public key) in an implementation-dependent manner.
1. 为了验证服务器，客户机通常以依赖于实现的方式存储对（tmTransportAddress、服务器主机公钥）。
2. The other parameters of the transport connection are provided in an implementation-dependent manner.
2. 传输连接的其他参数以依赖于实现的方式提供。
3. If the attempt to establish a connection is unsuccessful or if server-authentication fails, then snmpSshtmSessionOpenErrors is incremented, an openSession error indication is returned, and openSession processing stops.
3. 如果尝试建立连接失败或服务器身份验证失败，则snmpSshtmSessionOpenErrors将递增，返回openSession错误指示，openSession处理将停止。
3. The client will then invoke an SSH authentication service to authenticate the principal, such as that described in the SSH authentication protocol [RFC4252].
3. 然后，客户端将调用SSH身份验证服务来验证主体，如SSH身份验证协议[RFC4252]中所述。
1. If the tmTransportAddress field contains a user name followed by an '@' character (US-ASCII 0x40), that user name string should be presented to the SSH server as the "user name" for user-authentication purposes. If there is no user name in the tmTransportAddress, then the tmSecurityName should be used as the user name.
1. 如果tmTransportAddress字段包含一个用户名，后跟一个“@”字符（US-ASCII 0x40），则该用户名字符串应作为“用户名”呈现给SSH服务器，以便进行用户身份验证。如果tmTransportAddress中没有用户名，则应使用tmSecurityName作为用户名。
2. The credentials used to authenticate the SSH principal are determined in an implementation-dependent manner.
2. 用于验证SSH主体的凭据是以依赖于实现的方式确定的。
3. In an implementation-specific manner, invoke the SSH user-authentication service using the calculated user name.
3. 以特定于实现的方式，使用计算出的用户名调用SSH用户身份验证服务。
4. If the user authentication is unsuccessful, then the transport connection is closed, the snmpSshtmSessionUserAuthFailures counter is incremented, an error indication is returned to the calling module, and processing stops for this message.
4. 如果用户身份验证失败，则传输连接关闭，snmpSshtmSessionUserAuthFailures计数器递增，错误指示返回给调用模块，并停止处理此消息。
4. The client should invoke the "ssh-connection" service (also known as the SSH connection protocol [RFC4254]), and request a channel of type "session". If unsuccessful, the transport connection is closed, the snmpSshtmSessionNoChannels counter is incremented, an error indication is returned to the calling module, and processing stops for this message.
4. 客户端应调用“ssh连接”服务（也称为ssh连接协议[RFC4254]），并请求“会话”类型的通道。如果不成功，传输连接将关闭，snmpSshtmSessionNoChannels计数器将递增，错误指示将返回给调用模块，并停止处理此消息。
5. The client invokes "snmp" as an SSH Subsystem, as indicated in the "subsystem" parameter. If unsuccessful, the transport connection is closed, the snmpSshtmSessionNoSubsystems counter is incremented, an error indication is returned to the calling module, and processing stops for this message.
5. 客户端将“snmp”作为SSH子系统调用，如“Subsystem”参数中所示。如果失败，传输连接将关闭，snmpSshtmSessionNoSubsystems计数器将递增，错误指示将返回给调用模块，并停止处理此消息。
In order to allow SNMP traffic to be easily identified and filtered by firewalls and other network devices, servers associated with SNMP entities using the Secure Shell Transport Model MUST default to providing access to the "snmp" SSH Subsystem if the SSH session is established using the IANA-assigned TCP ports (5161 and 5162). Servers SHOULD be configurable to allow access to the SNMP SSH Subsystem over other ports.
为了允许防火墙和其他网络设备轻松识别和过滤SNMP通信，如果使用IANA分配的TCP端口（5161和5162）建立SSH会话，则与使用安全外壳传输模型的SNMP实体关联的服务器必须默认提供对“SNMP”SSH子系统的访问。服务器应可配置为允许通过其他端口访问SNMP SSH子系统。
6. Set tmSessionID in the tmStateReference cache to an implementation-dependent value to identify the session.
6. 将tmStateReference缓存中的TMSSessionId设置为依赖于实现的值，以标识会话。
7. The tmSecurityName used to establish the SSH session must be the only tmSecurityName used with the session. Incoming messages for the session MUST be associated with this tmSecurityName value. How this is accomplished is implementation-dependent.
7. 用于建立SSH会话的tmSecurityName必须是会话中使用的唯一tmSecurityName。会话的传入消息必须与此tmSecurityName值关联。如何实现这一点取决于实现。
The Secure Shell Transport Model provides the following ASI to close a session:
Secure Shell传输模型提供以下ASI来关闭会话：
statusInformation = closeSession( IN tmSessionID -- session ID of session to be closed )
statusInformation=closeSession（在TMSSessionID中——要关闭的会话的会话ID）
The following describes the procedure to follow to close a session between a client and server. This process is followed by any SNMP engine to close an SSH session. It is implementation-dependent when a session should be closed. The calling code should release the associated tmStateReference.
以下描述关闭客户端和服务器之间的会话所遵循的过程。此过程之后是任何SNMP引擎关闭SSH会话。会话何时关闭取决于实现。调用代码应该释放关联的引用。
1. Increment the snmpSshtmSessionCloses counter.
1. 递增snmpsshtmsessioncloss计数器。
2. If there is no session corresponding to tmSessionID, then closeSession processing is complete.
2. 如果没有与TMSSessionID对应的会话，则closeSession处理完成。
3. Have SSH close the session associated with tmSessionID.
3. 让SSH关闭与TMSSessionID关联的会话。
This MIB module provides management of the Secure Shell Transport Model. It defines an OID to identify the SNMP-over-SSH transport domain, a Textual Convention for SSH Addresses, and several statistics counters.
此MIB模块提供安全外壳传输模型的管理。它定义了一个OID来标识SNMP over SSH传输域、SSH地址的文本约定以及几个统计计数器。
Objects in this MIB module are arranged into subtrees. Each subtree is organized as a set of related objects. The overall structure and assignment of objects to their subtrees, and the intended purpose of each subtree, is shown below.
此MIB模块中的对象被排列到子树中。每个子树都组织为一组相关对象。下面显示了对象的总体结构和对其子树的分配，以及每个子树的预期用途。
Generic and Common Textual Conventions used in this document can be
found summarized at http://www.ops.ietf.org/mib-common-tcs.html
Generic and Common Textual Conventions used in this document can be
found summarized at http://www.ops.ietf.org/mib-common-tcs.html
Some management objects defined in other MIB modules are applicable to an entity implementing the SSH Transport Model. In particular, it is assumed that an entity implementing the SNMP-SSH-TM-MIB will implement the SNMPv2-MIB [RFC3418] and the SNMP-FRAMEWORK-MIB [RFC3411]. It is expected that an entity implementing this MIB will also support the Transport Security Model [RFC5591] and, therefore, implement the SNMP-TSM-MIB.
其他MIB模块中定义的一些管理对象适用于实现SSH传输模型的实体。具体而言，假设实现SNMP-SSH-TM-MIB的实体将实现SNMPv2 MIB[RFC3418]和SNMP-FRAMEWORK-MIB[RFC3411]。预计实现此MIB的实体也将支持传输安全模型[RFC5591]，因此，实现SNMP-TSM-MIB。
This MIB module is for monitoring SSH Transport Model information.
此MIB模块用于监视SSH传输模型信息。
The following MIB module imports items from [RFC2578], [RFC2579], and [RFC2580].
以下MIB模块从[RFC2578]、[RFC2579]和[RFC2580]导入项目。
This MIB module also references [RFC1033], [RFC4252], [RFC3490], and [RFC3986].
该MIB模块还引用[RFC1033]、[RFC4252]、[RFC3490]和[RFC3986]。
This document uses TDomain Textual Conventions for the SNMP-internal MIB modules defined here for compatibility with the RFC 3413 MIB modules and the RFC 3411 Abstract Service Interfaces.
本文档使用此处定义的SNMP内部MIB模块的主要文本约定，以与RFC 3413 MIB模块和RFC 3411抽象服务接口兼容。
SNMP-SSH-TM-MIB DEFINITIONS ::= BEGIN
SNMP-SSH-TM-MIB DEFINITIONS ::= BEGIN
IMPORTS MODULE-IDENTITY, OBJECT-TYPE, OBJECT-IDENTITY, mib-2, snmpDomains, Counter32 FROM SNMPv2-SMI -- RFC 2578 TEXTUAL-CONVENTION FROM SNMPv2-TC -- RFC 2579 MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF -- RFC 2580 ;
从SNMPv2 SMI导入模块标识、对象类型、对象标识、mib-2、snmpDomains、计数器32——从SNMPv2 TC导入RFC 2578文本约定——从SNMPv2 CONF导入RFC 2579模块符合性、从SNMPv2 CONF导入对象组——RFC 2580；
snmpSshtmMIB MODULE-IDENTITY LAST-UPDATED "200906090000Z" ORGANIZATION "ISMS Working Group" CONTACT-INFO "WG-EMail: isms@lists.ietf.org Subscribe: isms-request@lists.ietf.org
snmpSshtmMIB模块标识最后更新的“200906090000Z”组织“ISMS工作组”联系方式工作组电子邮件：isms@lists.ietf.org订阅：isms-request@lists.ietf.org
Chairs: Juergen Quittek NEC Europe Ltd. Network Laboratories Kurfuersten-Anlage 36 69115 Heidelberg Germany +49 6221 90511-15 quittek@netlab.nec.de
主席：Juergen Quittek NEC欧洲有限公司网络实验室Kurfuersten Anlage 36 69115德国海德堡+49 6221 90511-15quittek@netlab.nec.de
Juergen Schoenwaelder Jacobs University Bremen Campus Ring 1 28725 Bremen Germany +49 421 200-3587 j.schoenwaelder@jacobs-university.de
Juergen Schoenwaeld Jacobs大学不来梅校区环128725德国不来梅+49 421 200-3587 j。schoenwaelder@jacobs-德国大学
Co-editors: David Harrington Huawei Technologies USA 1700 Alma Drive Plano Texas 75075
联合编辑：David Harrington Huawei Technologies USA 1700 Alma Drive Plano Texas 75075
USA +1 603-436-8634 ietfdbh@comcast.net
美国+1 603-436-8634ietfdbh@comcast.net
Joseph Salowey Cisco Systems 2901 3rd Ave Seattle, WA 98121 USA jsalowey@cisco.com
美国华盛顿州西雅图第三大道2901号Joseph Salowey Cisco Systems 98121jsalowey@cisco.com
Wes Hardaker Cobham Analytic Solutions P.O. Box 382 Davis, CA 95617 USA +1 530 792 1913 ietf@hardakers.net " DESCRIPTION "The Secure Shell Transport Model MIB.
Wes Hardaker Cobham分析解决方案美国加利福尼亚州戴维斯382号信箱95617+1 530 792 1913ietf@hardakers.net“说明”安全外壳传输模型MIB。
Copyright (c) 2009 IETF Trust and the persons identified as authors of the code. All rights reserved.
版权所有（c）2009 IETF信托基金和被确定为代码作者的人员。版权所有。
Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met:
在满足以下条件的情况下，允许以源代码和二进制格式重新分发和使用，无论是否修改：
- Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer.
- 源代码的重新分发必须保留上述版权声明、此条件列表和以下免责声明。
- Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution.
- 以二进制形式重新分发时，必须在分发时提供的文档和/或其他材料中复制上述版权声明、本条件列表和以下免责声明。
- Neither the name of Internet Society, IETF or IETF Trust, nor the names of specific contributors, may be used to endorse or promote products derived from this software without specific prior written permission.
- 未经事先书面许可，不得使用互联网协会、IETF或IETF Trust的名称或特定贡献者的名称来认可或推广源自本软件的产品。
THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS 'AS IS' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
本软件由版权所有者和贡献者“按原样”提供，不承担任何明示或暗示的担保，包括但不限于适销性和特定用途适用性的暗示担保。在任何情况下，版权所有人或贡献者均不对任何直接、间接、附带、，
SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
无论是在合同、严格责任还是侵权行为（包括疏忽或其他）中，以任何责任理论造成的特殊、惩戒性或间接损害（包括但不限于采购替代货物或服务；使用、数据或利润损失；或业务中断）因使用本软件而产生的任何后果，即使告知可能发生此类损害。
This version of this MIB module is part of RFC 5592; see the RFC itself for full legal notices."
此版本的MIB模块是RFC 5592的一部分；有关完整的法律通知，请参见RFC本身。”
REVISION "200906090000Z" DESCRIPTION "The initial version, published in RFC 5592."
修订版“200906090000Z”说明“初始版本，在RFC 5592中发布。”
::= { mib-2 189 }
::= { mib-2 189 }
-- ---------------------------------------------------------- --
-- subtrees in the SNMP-SSH-TM-MIB
-- ---------------------------------------------------------- --
-- ---------------------------------------------------------- --
-- subtrees in the SNMP-SSH-TM-MIB
-- ---------------------------------------------------------- --
snmpSshtmNotifications OBJECT IDENTIFIER ::= { snmpSshtmMIB 0 }
snmpSshtmObjects OBJECT IDENTIFIER ::= { snmpSshtmMIB 1 }
snmpSshtmConformance OBJECT IDENTIFIER ::= { snmpSshtmMIB 2 }
snmpSshtmNotifications OBJECT IDENTIFIER ::= { snmpSshtmMIB 0 }
snmpSshtmObjects OBJECT IDENTIFIER ::= { snmpSshtmMIB 1 }
snmpSshtmConformance OBJECT IDENTIFIER ::= { snmpSshtmMIB 2 }
-- -------------------------------------------------------------
-- Objects
-- -------------------------------------------------------------
-- -------------------------------------------------------------
-- Objects
-- -------------------------------------------------------------
snmpSSHDomain OBJECT-IDENTITY STATUS current DESCRIPTION "The SNMP-over-SSH transport domain. The corresponding transport address is of type SnmpSSHAddress.
snmpSSHDomain OBJECT-IDENTITY STATUS current DESCRIPTION“SNMP over SSH传输域。相应的传输地址为SnmpSSHAddress类型。
When an SNMP entity uses the snmpSSHDomain Transport Model, it must be capable of accepting messages up to and including 8192 octets in size. Implementation of larger values is encouraged whenever possible.
当SNMP实体使用snmpSSHDomain传输模型时，它必须能够接受大小不超过8192个八位字节的消息。尽可能鼓励实施更大的价值观。
The securityName prefix to be associated with the
snmpSSHDomain is 'ssh'. This prefix may be used by Security
Models or other components to identify which secure transport
infrastructure authenticated a securityName."
::= { snmpDomains 7 }
The securityName prefix to be associated with the
snmpSSHDomain is 'ssh'. This prefix may be used by Security
Models or other components to identify which secure transport
infrastructure authenticated a securityName."
::= { snmpDomains 7 }
SnmpSSHAddress ::= TEXTUAL-CONVENTION
DISPLAY-HINT "1a"
STATUS current
SnmpSSHAddress ::= TEXTUAL-CONVENTION
DISPLAY-HINT "1a"
STATUS current
DESCRIPTION "Represents either a hostname or IP address, along with a port number and an optional user name.
DESCRIPTION”表示主机名或IP地址，以及端口号和可选用户名。
The beginning of the address specification may contain a user name followed by an '@' (US-ASCII character 0x40). This portion of the address will indicate the user name that should be used when authenticating to an SSH server. The user name must be encoded in UTF-8 (per [RFC4252]). If missing, the SNMP securityName should be used. After the optional user name field and '@' character comes the hostname or IP address.
地址规范的开头可能包含用户名，后跟“@”（US-ASCII字符0x40）。地址的这一部分将指示向SSH服务器进行身份验证时应使用的用户名。用户名必须用UTF-8编码（根据[RFC4252]）。如果缺少，则应使用SNMP securityName。可选用户名字段和@字符后面是主机名或IP地址。
The hostname is always in US-ASCII (as per RFC1033); internationalized hostnames are encoded in US-ASCII as specified in RFC 3490. The hostname is followed by a colon ':' (US-ASCII character 0x3A) and a decimal port number in US-ASCII. The name SHOULD be fully qualified whenever possible.
主机名始终为US-ASCII（根据RFC1033）；按照RFC 3490中的规定，国际化主机名以US-ASCII编码。主机名后面是冒号“：”（US-ASCII字符0x3A）和十进制端口号（US-ASCII）。名称应尽可能完全限定。
An IPv4 address must be in dotted decimal format followed by a colon ':' (US-ASCII character 0x3A) and a decimal port number in US-ASCII.
IPv4地址必须采用点十进制格式，后跟冒号“：”（US-ASCII字符0x3A）和US-ASCII格式的十进制端口号。
An IPv6 address must be in colon-separated format, surrounded by square brackets ('[', US-ASCII character 0x5B, and ']', US-ASCII character 0x5D), followed by a colon ':' (US-ASCII character 0x3A) and a decimal port number in US-ASCII.
IPv6地址必须采用冒号分隔格式，由方括号（“[”，US-ASCII字符0x5B和“]”，US-ASCII字符0x5D）包围，后跟冒号“：”（US-ASCII字符0x3A）和US-ASCII十进制端口号。
Values of this Textual Convention might not be directly usable as transport-layer addressing information and may require runtime resolution. As such, applications that write them must be prepared for handling errors if such values are not supported or cannot be resolved (if resolution occurs at the time of the management operation).
此文本约定的值可能无法直接用作传输层寻址信息，并且可能需要运行时解析。因此，如果这些值不受支持或无法解析（如果在管理操作时发生解析），则编写这些值的应用程序必须准备好处理错误。
The DESCRIPTION clause of TransportAddress objects that may have snmpSSHAddress values must fully describe how (and when) such names are to be resolved to IP addresses and vice versa.
可能具有snmpSSHAddress值的TransportAddress对象的DESCRIPTION子句必须完全描述如何（以及何时）将此类名称解析为IP地址，反之亦然。
This Textual Convention SHOULD NOT be used directly in object definitions since it restricts addresses to a specific format. However, if it is used, it MAY be used either on its own or in conjunction with TransportAddressType or TransportDomain as a pair.
此文本约定不应直接用于对象定义，因为它将地址限制为特定格式。但是，如果使用，它可以单独使用，也可以与TransportAddressType或TransportDomain成对使用。
When this Textual Convention is used as a syntax of an index object, there may be issues with the limit of 128 sub-identifiers, which is specified in SMIv2 (STD 58). It is RECOMMENDED that all MIB documents using this Textual Convention make explicit any limitations on index component lengths that management software must observe. This may be done either by including SIZE constraints on the index components or by specifying applicable constraints in the conceptual row DESCRIPTION clause or in the surrounding documentation. " REFERENCE "RFC 1033: DOMAIN ADMINISTRATORS OPERATIONS GUIDE RFC 3490: Internationalizing Domain Names in Applications RFC 3986: Uniform Resource Identifier (URI): Generic Syntax RFC 4252: The Secure Shell (SSH) Authentication Protocol" SYNTAX OCTET STRING (SIZE (1..255))
当此文本约定用作索引对象的语法时，SMIv2（STD 58）中指定的128个子标识符的限制可能存在问题。建议所有使用此文本约定的MIB文档对管理软件必须遵守的索引组件长度做出明确的限制。这可以通过在索引组件上包含大小约束或在概念行描述子句或周围文档中指定适用的约束来实现。参考“RFC 1033:域管理员操作指南RFC 3490:应用程序中的域名国际化RFC 3986:统一资源标识符（URI）：通用语法RFC 4252:安全外壳（SSH）身份验证协议”语法八位字符串（大小（1..255））
-- The snmpSshtmSession Group
--snmpSshtmSession组
snmpSshtmSession OBJECT IDENTIFIER ::= { snmpSshtmObjects 1 }
snmpSshtmSession OBJECT IDENTIFIER ::= { snmpSshtmObjects 1 }
snmpSshtmSessionOpens OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION "The number of times an openSession() request has been
executed as an SSH client, whether it succeeded or
failed.
"
::= { snmpSshtmSession 1 }
snmpSshtmSessionOpens OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION "The number of times an openSession() request has been
executed as an SSH client, whether it succeeded or
failed.
"
::= { snmpSshtmSession 1 }
snmpSshtmSessionCloses OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION "The number of times a closeSession() request has been
executed as an SSH client, whether it succeeded or
failed.
"
::= { snmpSshtmSession 2 }
snmpSshtmSessionCloses OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION "The number of times a closeSession() request has been
executed as an SSH client, whether it succeeded or
failed.
"
::= { snmpSshtmSession 2 }
snmpSshtmSessionOpenErrors OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current
snmpSshtmSessionOpenErrors对象类型语法计数器32 MAX-ACCESS只读状态当前
DESCRIPTION "The number of times an openSession() request
failed to open a transport connection or failed to
authenticate the server.
"
::= { snmpSshtmSession 3 }
DESCRIPTION "The number of times an openSession() request
failed to open a transport connection or failed to
authenticate the server.
"
::= { snmpSshtmSession 3 }
snmpSshtmSessionUserAuthFailures OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION "The number of times an openSession() request
failed to open a session as an SSH client due to
user-authentication failures.
"
::= { snmpSshtmSession 4 }
snmpSshtmSessionUserAuthFailures OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION "The number of times an openSession() request
failed to open a session as an SSH client due to
user-authentication failures.
"
::= { snmpSshtmSession 4 }
snmpSshtmSessionNoChannels OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION "The number of times an openSession() request
failed to open a session as an SSH client due to
channel-open failures.
"
::= { snmpSshtmSession 5 }
snmpSshtmSessionNoChannels OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION "The number of times an openSession() request
failed to open a session as an SSH client due to
channel-open failures.
"
::= { snmpSshtmSession 5 }
snmpSshtmSessionNoSubsystems OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION "The number of times an openSession() request
failed to open a session as an SSH client due to
inability to connect to the requested subsystem.
"
::= { snmpSshtmSession 6 }
snmpSshtmSessionNoSubsystems OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION "The number of times an openSession() request
failed to open a session as an SSH client due to
inability to connect to the requested subsystem.
"
::= { snmpSshtmSession 6 }
snmpSshtmSessionNoSessions OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION "The number of times an outgoing message was
dropped because the same session was no longer
available.
"
::= { snmpSshtmSession 7 }
snmpSshtmSessionNoSessions OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION "The number of times an outgoing message was
dropped because the same session was no longer
available.
"
::= { snmpSshtmSession 7 }
snmpSshtmSessionInvalidCaches OBJECT-TYPE SYNTAX Counter32
snmpSshtmSessionInvalidCaches对象类型语法计数器32
MAX-ACCESS read-only
STATUS current
DESCRIPTION "The number of outgoing messages dropped because the
tmStateReference referred to an invalid cache.
"
::= { snmpSshtmSession 8 }
MAX-ACCESS read-only
STATUS current
DESCRIPTION "The number of outgoing messages dropped because the
tmStateReference referred to an invalid cache.
"
::= { snmpSshtmSession 8 }
-- ************************************************
-- snmpSshtmMIB - Conformance Information
-- ************************************************
-- ************************************************
-- snmpSshtmMIB - Conformance Information
-- ************************************************
snmpSshtmCompliances OBJECT IDENTIFIER ::= { snmpSshtmConformance 1 }
snmpSshtmCompliances OBJECT IDENTIFIER ::= { snmpSshtmConformance 1 }
snmpSshtmGroups OBJECT IDENTIFIER ::= { snmpSshtmConformance 2 }
snmpSshtmGroups OBJECT IDENTIFIER ::= { snmpSshtmConformance 2 }
-- ************************************************
-- Compliance statements
-- ************************************************
-- ************************************************
-- Compliance statements
-- ************************************************
snmpSshtmCompliance MODULE-COMPLIANCE STATUS current
SNMPSSHTM合规性模块-合规性状态当前
DESCRIPTION "The compliance statement for SNMP engines that
support the SNMP-SSH-TM-MIB."
MODULE
MANDATORY-GROUPS { snmpSshtmGroup }
::= { snmpSshtmCompliances 1 }
DESCRIPTION "The compliance statement for SNMP engines that
support the SNMP-SSH-TM-MIB."
MODULE
MANDATORY-GROUPS { snmpSshtmGroup }
::= { snmpSshtmCompliances 1 }
-- ************************************************
-- Units of conformance
-- ************************************************
-- ************************************************
-- Units of conformance
-- ************************************************
snmpSshtmGroup OBJECT-GROUP
OBJECTS {
snmpSshtmSessionOpens,
snmpSshtmSessionCloses,
snmpSshtmSessionOpenErrors,
snmpSshtmSessionUserAuthFailures,
snmpSshtmSessionNoChannels,
snmpSshtmSessionNoSubsystems,
snmpSshtmSessionNoSessions,
snmpSshtmSessionInvalidCaches
}
STATUS current
DESCRIPTION "A collection of objects for maintaining information
of an SNMP engine that implements the SNMP Secure
Shell Transport Model.
"
snmpSshtmGroup OBJECT-GROUP
OBJECTS {
snmpSshtmSessionOpens,
snmpSshtmSessionCloses,
snmpSshtmSessionOpenErrors,
snmpSshtmSessionUserAuthFailures,
snmpSshtmSessionNoChannels,
snmpSshtmSessionNoSubsystems,
snmpSshtmSessionNoSessions,
snmpSshtmSessionInvalidCaches
}
STATUS current
DESCRIPTION "A collection of objects for maintaining information
of an SNMP engine that implements the SNMP Secure
Shell Transport Model.
"
::= { snmpSshtmGroups 2 }
::= { snmpSshtmGroups 2 }
END
终止
The SSH Transport Model will likely not work in conditions where remote access to the CLI has stopped working. The SSH Transport Model assumes that TCP and IP continue to operate correctly between the communicating nodes. Failures in either node, death of the deamon serving the communication, routing problems in the network between, firewalls that block the traffic, and other problems can prevent the SSH Transport Model from working. In situations where management access has to be very reliable, operators should consider mitigating measures. These measures may include dedicated management-only networks, point-to-point links, and the ability to use alternate protocols and transports.
SSH传输模型可能无法在对CLI的远程访问停止的情况下工作。SSH传输模型假设TCP和IP在通信节点之间继续正常运行。任何一个节点中的故障、服务于通信的deamon的死亡、节点之间网络中的路由问题、阻止通信的防火墙以及其他问题都会阻止SSH传输模型工作。在管理访问必须非常可靠的情况下，运营商应考虑缓解措施。这些措施可能包括专用的仅管理网络、点对点链路以及使用备用协议和传输的能力。
To have SNMP properly utilize the security services provided by SSH, the SSH Transport Model MUST be used with a Security Model that knows how to process a tmStateReference, such as the Transport Security Model for SNMP [RFC5591].
为了让SNMP正确利用SSH提供的安全服务，SSH传输模型必须与知道如何处理tmStateReference的安全模型一起使用，例如SNMP的传输安全模型[RFC5591]。
If the SSH Transport Model is configured to utilize AAA services, operators should consider configuring support for local authentication mechanisms, such as local passwords, so SNMP can continue operating during times of network stress.
如果SSH传输模型被配置为利用AAA服务，运营商应该考虑配置对本地认证机制的支持，例如本地密码，因此SNMP可以在网络重压期间继续运行。
The SSH protocol has its own window mechanism, defined in RFC 4254. The SSH specifications leave it open when window adjustment messages should be created, and some implementations send these whenever received data has been passed to the application. There are noticeable bandwidth and processing overheads to handling such window adjustment messages, which can be avoided by sending them less frequently.
SSH协议有自己的窗口机制，在RFC 4254中定义。SSH规范在应该创建窗口调整消息时保持打开状态，并且一些实现在接收到的数据传递到应用程序时发送这些消息。处理此类窗口调整消息会带来明显的带宽和处理开销，可以通过降低发送频率来避免。
The SSH protocol requires the execution of CPU-intensive calculations to establish a session key during session establishment. This means that short-lived sessions become computationally expensive compared to USM, which does not have a notion of a session key. Other transport security protocols such as TLS support a session-resumption feature that allows reusing a cached session key. Such a mechanism does not exist for SSH and thus SNMP applications should keep SSH sessions for longer time periods.
SSH协议要求执行CPU密集型计算，以在会话建立期间建立会话密钥。这意味着与USM相比，短命会话在计算上变得昂贵，USM没有会话密钥的概念。其他传输安全协议（如TLS）支持会话恢复功能，允许重用缓存的会话密钥。SSH不存在这样的机制，因此SNMP应用程序应该将SSH会话保持更长的时间。
To initiate SSH connections, an entity must be configured with SSH client credentials plus information to authenticate the server. While hosts are often configured to be SSH clients, most
要启动SSH连接，必须为实体配置SSH客户端凭据以及用于验证服务器的信息。虽然主机通常配置为SSH客户端，但大多数
internetworking devices are not. To send notifications over SSHTM, the internetworking device will need to be configured as an SSH client. How this credential configuration is done is implementation-and deployment-specific.
网络互连设备不可用。要通过SSHTM发送通知，需要将internetworking设备配置为SSH客户端。如何完成此凭据配置取决于实现和部署。
This memo describes a Transport Model that permits SNMP to utilize SSH security services. The security threats and how the SSH Transport Model mitigates those threats is covered in detail throughout this memo.
本备忘录描述了允许SNMP利用SSH安全服务的传输模型。本备忘录将详细介绍安全威胁以及SSH传输模型如何缓解这些威胁。
The SSH Transport Model relies on SSH mutual authentication, binding of keys, confidentiality, and integrity. Any authentication method that meets the requirements of the SSH architecture will provide the properties of mutual authentication and binding of keys.
SSH传输模型依赖于SSH相互身份验证、密钥绑定、机密性和完整性。任何满足SSH体系结构要求的身份验证方法都将提供相互身份验证和密钥绑定的属性。
SSHv2 provides perfect forward secrecy (PFS) for encryption keys. PFS is a major design goal of SSH, and any well-designed key-exchange algorithm will provide it.
SSHv2为加密密钥提供了完美的前向保密性（PFS）。PFS是SSH的一个主要设计目标，任何设计良好的密钥交换算法都可以提供它。
The security implications of using SSH are covered in [RFC4251].
[RFC4251]中介绍了使用SSH的安全含义。
The SSH Transport Model has no way to verify that server authentication was performed, to learn the host's public key in advance, or to verify that the correct key is being used. The SSH Transport Model simply trusts that these are properly configured by the implementer and deployer.
SSH传输模型无法验证是否执行了服务器身份验证，无法提前了解主机的公钥，也无法验证是否使用了正确的密钥。SSH传输模型只相信实现者和部署者正确配置了这些。
SSH provides the "none" userauth method. The SSH Transport Model MUST NOT be used with an SSH connection with the "none" userauth method. While SSH does support turning off confidentiality and integrity, they MUST NOT be turned off when used with the SSH Transport Model.
SSH提供了“none”userauth方法。SSH传输模型不得与带有“none”userauth方法的SSH连接一起使用。虽然SSH支持关闭机密性和完整性，但在与SSH传输模型一起使用时，不能关闭它们。
The SSH protocol is not always clear on whether the user name field must be filled in, so for some implementations, such as those using GSSAPI authentication, it may be necessary to use a mapping algorithm to transform an SSH identity to a tmSecurityName or to transform a tmSecurityName to an SSH identity.
SSH协议并不总是清楚是否必须填写用户名字段，因此对于某些实现，例如使用GSSAPI身份验证的实现，可能需要使用映射算法将SSH标识转换为tmSecurityName或将tmSecurityName转换为SSH标识。
In other cases, the user name may not be verified by the server, so for these implementations, it may be necessary to obtain the user name from other credentials exchanged during the SSH exchange.
在其他情况下，服务器可能不会验证用户名，因此对于这些实现，可能需要从SSH交换期间交换的其他凭据中获取用户名。
Most key-exchange algorithms are able to authenticate the SSH server's identity to the client. However, for the common case of Diffie-Hellman (DH) signed by public keys, this requires the client to know the host's public key a priori and to verify that the correct key is being used. If this step is skipped, then authentication of the SSH server to the SSH client is not done. Data confidentiality and data integrity protection to the server still exist, but these are of dubious value when an attacker can insert himself between the client and the real SSH server. Note that some userauth methods may defend against this situation, but many of the common ones (including password and keyboard-interactive) do not and, in fact, depend on the fact that the server's identity has been verified (so passwords are not disclosed to an attacker).
大多数密钥交换算法都能够向客户端验证SSH服务器的身份。但是，对于由公钥签名的Diffie Hellman（DH）的常见情况，这要求客户端事先知道主机的公钥，并验证使用的密钥是否正确。如果跳过此步骤，则不会完成SSH服务器到SSH客户端的身份验证。对服务器的数据机密性和数据完整性保护仍然存在，但当攻击者可以在客户端和真正的SSH服务器之间插入自己时，这些都具有可疑的价值。请注意，某些userauth方法可能会针对这种情况进行防御，但许多常见方法（包括密码和键盘交互）不会，事实上，这取决于服务器的身份已被验证的事实（因此密码不会泄露给攻击者）。
SSH MUST NOT be configured to skip public-key verification for use with the SSH Transport Model.
不能将SSH配置为跳过用于SSH传输模型的公钥验证。
SNMP Notifications are authorized to be sent to a receiver based on the securityName used by the notification originator's SNMP engine. This authorization is performed before the message is actually sent and before the credentials of the remote receiver have been verified. Thus, the credentials presented by a notification receiver MUST match the expected value(s) for a given transport address, and ownership of the credentials MUST be properly cryptographically verified.
SNMP通知被授权根据通知发起人的SNMP引擎使用的securityName发送给接收方。此授权在消息实际发送之前以及在验证远程接收器的凭据之前执行。因此，通知接收方提供的凭据必须与给定传输地址的预期值相匹配，并且必须以加密方式正确验证凭据的所有权。
If a "user@" prefix is used within an SnmpSSHAddress value to specify an SSH user name to use for authentication, then the key presented to the remote entity MUST be the key expected by the server for the "user". This may be different than a locally cached key identified by the securityName value.
如果在SnmpSSHAddress值中使用“user@”前缀来指定用于身份验证的SSH用户名，则提供给远程实体的密钥必须是服务器期望的“user”密钥。这可能不同于由securityName值标识的本地缓存密钥。
The User-based Security Model [RFC3414] employed symmetric cryptography and user-naming conventions. SSH employs an asymmetric cryptography and naming model. Unlike USM, cryptographic keys will be different on both sides of the SSH connection. Both sides are responsible for verifying that the remote entity presents the right key. The optional "user@" prefix component of the SnmpSSHAddress Textual Convention allows the client SNMP stack to associate the connection with a securityName that may be different than the SSH user name presented to the SSH server.
基于用户的安全模型[RFC3414]采用对称加密和用户命名约定。SSH采用非对称加密和命名模型。与USM不同，SSH连接两侧的加密密钥将不同。双方都负责验证远程实体是否提供了正确的密钥。SnmpSSHAddress文本约定的可选“user@”前缀组件允许客户端SNMP堆栈将连接与securityName关联，该securityName可能不同于提供给SSH服务器的SSH用户名。
SSH provides the "none" Message Authentication Code (MAC) algorithm, which would allow you to turn off data integrity while maintaining confidentiality. However, if you do this, then an attacker may be able to modify the data in flight, which means you effectively have no authentication.
SSH提供了“无”消息身份验证码（MAC）算法，允许您在保持机密性的同时关闭数据完整性。但是，如果您这样做，攻击者可能会在飞行中修改数据，这意味着您实际上没有身份验证。
SSH MUST NOT be configured using the "none" MAC algorithm for use with the SSH Transport Model.
SSH不得使用与SSH传输模型一起使用的“无”MAC算法进行配置。
The SNMPv1 and SNMPv2c message processing described in [RFC3584] (BCP 74) always selects the SNMPv1 or SNMPv2c Security Models, respectively. Both of these and the User-based Security Model typically used with SNMPv3 derive the securityName and securityLevel from the SNMP message received, even when the message was received over a secure transport. Access control decisions are therefore made based on the contents of the SNMP message, rather than using the authenticated identity and securityLevel provided by the SSH Transport Model.
[RFC3584]（BCP 74）中描述的SNMPv1和SNMPv2c消息处理始终分别选择SNMPv1或SNMPv2c安全模型。这两个模型以及通常与SNMPv3一起使用的基于用户的安全模型都从接收到的SNMP消息中派生securityName和securityLevel，即使消息是通过安全传输接收的。因此，访问控制决策是基于SNMP消息的内容做出的，而不是使用SSH传输模型提供的经过身份验证的标识和安全级别。
There are no management objects defined in this MIB module that have a MAX-ACCESS clause of read-write and/or read-create. So, if this MIB module is implemented correctly, then there is no risk that an intruder can alter or create any management objects of this MIB module via direct SNMP SET operations.
此MIB模块中未定义具有读写和/或读创建MAX-ACCESS子句的管理对象。因此，如果此MIB模块实现正确，则入侵者不会通过直接的SNMP集操作更改或创建此MIB模块的任何管理对象。
Some of the readable objects in this MIB module (i.e., objects with a MAX-ACCESS other than not-accessible) may be considered sensitive or vulnerable in some network environments. It is thus important to control even GET and/or NOTIFY access to these objects and possibly to even encrypt the values of these objects when sending them over the network via SNMP. These are the tables and objects and their sensitivity/vulnerability:
在某些网络环境中，此MIB模块中的某些可读对象（即具有MAX-ACCESS而非not ACCESS的对象）可能被视为敏感或易受攻击。因此，在通过SNMP通过网络发送这些对象时，控制甚至获取和/或通知对这些对象的访问，甚至可能加密这些对象的值，这一点非常重要。以下是表和对象及其敏感度/漏洞：
o The information in the snmpSshtmSession group is generated locally when a client session is being opened or closed. This information can reflect the configured capabilities of a remote SSH server, which could be helpful to an attacker for focusing an attack.
o snmpSshtmSession组中的信息在打开或关闭客户端会话时在本地生成。此信息可以反映远程SSH服务器的配置功能，这有助于攻击者集中攻击。
SNMP versions prior to SNMPv3 did not include adequate security. Even if the network itself is secure (for example by using IPSec or SSH), even then, there is no control as to who on the secure network is allowed to access and GET/SET (read/change/create/delete) the objects in this MIB module.
SNMPv3之前的SNMP版本未包含足够的安全性。即使网络本身是安全的（例如通过使用IPSec或SSH），即使如此，也无法控制安全网络上的谁可以访问和获取/设置（读取/更改/创建/删除）此MIB模块中的对象。
It is RECOMMENDED that implementers consider the security features as provided by the SNMPv3 framework (see [RFC3410], Section 8), including full support for cryptographic mechanisms for authentication and privacy, such as those found in the User-based Security Model [RFC3414], the Transport Security Model [RFC5591], and the SSH Transport Model described in this document.
建议实施者考虑SNMPv3框架提供的安全特性（参见[RCF310]，第8节），包括完全支持用于身份验证和隐私的密码机制，例如在基于用户的安全模型[RCFC1414]中发现的那些，传输安全模型[RCFC991]，以及本文档中描述的SSH传输模型。
Further, deployment of SNMP versions prior to SNMPv3 is NOT RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to enable cryptographic security. It is then a customer/operator responsibility to ensure that the SNMP entity giving access to an instance of this MIB module is properly configured to give access to the objects only to those principals (users) that have legitimate rights to indeed GET or SET (change/create/delete) them.
此外，不建议部署SNMPv3之前的SNMP版本。相反，建议部署SNMPv3并启用加密安全性。然后，客户/运营商应负责确保授予访问此MIB模块实例权限的SNMP实体已正确配置为仅授予那些拥有确实获取或设置（更改/创建/删除）对象的合法权限的主体（用户）访问对象。
IANA has assigned:
IANA已分配：
1. Two TCP port numbers in the Port Numbers registry that will be the default ports for the SNMP-over-SSH Transport Model as defined in this document, and the SNMP-over-SSH Transport Model for notifications as defined in this document. The assigned keywords and port numbers are "snmpssh" (5161) and "snmpssh-trap" (5162).
1. 端口号注册表中的两个TCP端口号将作为本文档中定义的SNMP over SSH传输模型和本文档中定义的通知SNMP over SSH传输模型的默认端口。分配的关键字和端口号是“snmpssh”（5161）和“snmpssh陷阱”（5162）。
2. An SMI number (189) under mib-2, for the MIB module in this document.
2. mib-2下的SMI编号（189），用于本文档中的mib模块。
3. An SMI number (7) under snmpDomains, for the snmpSSHDomain.
3. snmpSSHDomain下的SMI编号（7）。
4. "ssh" as the corresponding prefix for the snmpSSHDomain in the SNMP Transport Domains registry; defined in [RFC5590].
4. “ssh”作为SNMP传输域注册表中snmpSSHDomain的相应前缀；在[RFC5590]中定义。
5. "snmp" as a Connection Protocol Subsystem Name in the SSH Protocol Parameters registry.
5. “snmp”作为SSH协议参数注册表中的连接协议子系统名称。
The editors would like to thank Jeffrey Hutzelman for sharing his SSH insights, and Dave Shield for an outstanding job wordsmithing the existing document to improve organization and clarity.
编辑们要感谢Jeffrey Hutzelman分享他的SSH见解，并感谢Dave Shield出色地完成了对现有文档的文字处理，以提高组织性和清晰度。
Additionally, helpful document reviews were received from Juergen Schoenwaelder.
此外，Juergen Schoenwaeld还提供了有用的文件审查。
[RFC1033] Lottor, M., "Domain administrators operations guide", RFC 1033, November 1987.
[RFC1033]洛托，M.，“域管理员操作指南”，RFC1033，1987年11月。
[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月。
[RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. Schoenwaelder, Ed., "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999.
[RFC2578]McCloghrie，K.，Ed.，Perkins，D.，Ed.，和J.Schoenwaeld，Ed.“管理信息的结构版本2（SMIv2）”，STD 58，RFC 2578，1999年4月。
[RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and J. Schoenwaelder, Ed., "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999.
[RFC2579]McCloghrie，K.，Ed.，Perkins，D.，Ed.，和J.Schoenwaeld，Ed.“SMIv2的文本约定”，STD 58，RFC 2579，1999年4月。
[RFC2580] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999.
[RFC2580]McCloghrie，K.，Perkins，D.，和J.Schoenwaeld，“SMIv2的一致性声明”，STD 58，RFC 25801999年4月。
[RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, December 2002.
[RFC3411]Harrington，D.，Presohn，R.，和B.Wijnen，“描述简单网络管理协议（SNMP）管理框架的体系结构”，STD 62，RFC 3411，2002年12月。
[RFC3413] Levi, D., Meyer, P., and B. Stewart, "Simple Network Management Protocol (SNMP) Applications", STD 62, RFC 3413, December 2002.
[RFC3413]Levi，D.，Meyer，P.，和B.Stewart，“简单网络管理协议（SNMP）应用”，STD 62，RFC 3413，2002年12月。
[RFC3414] Blumenthal, U. and B. Wijnen, "User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)", STD 62, RFC 3414, December 2002.
[RFC3414]Blumenthal，U.和B.Wijnen，“简单网络管理协议（SNMPv3）版本3的基于用户的安全模型（USM）”，STD 62，RFC 3414，2002年12月。
[RFC3418] Presuhn, R., "Management Information Base (MIB) for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3418, December 2002.
[RFC3418]Presohn，R.，“简单网络管理协议（SNMP）的管理信息库（MIB）”，STD 62，RFC 3418，2002年12月。
[RFC3490] Faltstrom, P., Hoffman, P., and A. Costello, "Internationalizing Domain Names in Applications (IDNA)", RFC 3490, March 2003.
[RFC3490]Faltstrom，P.，Hoffman，P.，和A.Costello，“应用程序中的域名国际化（IDNA）”，RFC 34902003年3月。
[RFC3584] Frye, R., Levi, D., Routhier, S., and B. Wijnen, "Coexistence between Version 1, Version 2, and Version 3 of the Internet-standard Network Management Framework", BCP 74, RFC 3584, August 2003.
[RFC3584]Frye，R.，Levi，D.，Routhier，S.，和B.Wijnen，“互联网标准网络管理框架版本1，版本2和版本3之间的共存”，BCP 74，RFC 3584，2003年8月。
[RFC4251] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) Protocol Architecture", RFC 4251, January 2006.
[RFC4251]Ylonen，T.和C.Lonvick，“安全外壳（SSH）协议架构”，RFC 4251，2006年1月。
[RFC4252] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) Authentication Protocol", RFC 4252, January 2006.
[RFC4252]Ylonen，T.和C.Lonvick，“安全外壳（SSH）认证协议”，RFC 4252，2006年1月。
[RFC4253] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) Transport Layer Protocol", RFC 4253, January 2006.
[RFC4253]Ylonen，T.和C.Lonvick，“安全外壳（SSH）传输层协议”，RFC 4253，2006年1月。
[RFC4254] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) Connection Protocol", RFC 4254, January 2006.
[RFC4254]Ylonen，T.和C.Lonvick，“安全外壳（SSH）连接协议”，RFC 42542006年1月。
[RFC5590] Harrington, D. and J. Schoenwaelder, "Transport Subsystem for the Simple Network Management Protocol (SNMP)", RFC 5590, June 2009.
[RFC5590]Harrington，D.和J.Schoenwaeld，“简单网络管理协议（SNMP）的传输子系统”，RFC 55902009年6月。
[RFC1994] Simpson, W., "PPP Challenge Handshake Authentication Protocol (CHAP)", RFC 1994, August 1996.
[RFC1994]辛普森，W.，“PPP挑战握手认证协议（CHAP）”，RFC 1994，1996年8月。
[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000.
[RFC2865]Rigney，C.，Willens，S.，Rubens，A.，和W.Simpson，“远程认证拨入用户服务（RADIUS）”，RFC 28652000年6月。
[RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction and Applicability Statements for Internet-Standard Management Framework", RFC 3410, December 2002.
[RFC3410]Case，J.，Mundy，R.，Partain，D.，和B.Stewart，“互联网标准管理框架的介绍和适用性声明”，RFC 34102002年12月。
[RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, "Diameter Base Protocol", RFC 3588, September 2003.
[RFC3588]Calhoun，P.，Loughney，J.，Guttman，E.，Zorn，G.，和J.Arkko，“直径基础协议”，RFC 3588，2003年9月。
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
[RFC3986]Berners Lee，T.，Fielding，R.，和L.Masinter，“统一资源标识符（URI）：通用语法”，STD 66，RFC 3986，2005年1月。
[RFC4256] Cusack, F. and M. Forssen, "Generic Message Exchange Authentication for the Secure Shell Protocol (SSH)", RFC 4256, January 2006.
[RFC4256]Cusack，F.和M.Forssen，“安全外壳协议（SSH）的通用消息交换身份验证”，RFC 4256，2006年1月。
[RFC4462] Hutzelman, J., Salowey, J., Galbraith, J., and V. Welch, "Generic Security Service Application Program Interface (GSS-API) Authentication and Key Exchange for the Secure Shell (SSH) Protocol", RFC 4462, May 2006.
[RFC4462]Hutzelman，J.，Salowey，J.，Galbraith，J.，和V.Welch，“安全壳（SSH）协议的通用安全服务应用程序接口（GSS-API）认证和密钥交换”，RFC 4462，2006年5月。
[RFC4742] Wasserman, M. and T. Goddard, "Using the NETCONF Configuration Protocol over Secure SHell (SSH)", RFC 4742, December 2006.
[RFC4742]Wasserman，M.和T.Goddard，“在安全外壳（SSH）上使用NETCONF配置协议”，RFC 4742，2006年12月。
[RFC5090] Sterman, B., Sadolevsky, D., Schwartz, D., Williams, D., and W. Beck, "RADIUS Extension for Digest Authentication", RFC 5090, February 2008.
[RFC5090]Sterman，B.，Sadolevsky，D.，Schwartz，D.，Williams，D.，和W.Beck，“摘要认证的半径扩展”，RFC 50902008年2月。
[RFC5591] Harrington, D. and W. Hardaker, "Transport Security Model for the Simple Network Management Protocol (SNMP)", RFC 5591, June 2009.
[RFC5591]Harrington，D.和W.Hardaker，“简单网络管理协议（SNMP）的传输安全模型”，RFC 55912009年6月。
Authors' Addresses
作者地址
David Harrington Huawei Technologies (USA) 1700 Alma Dr. Suite 100 Plano, TX 75075 USA
David Harrington Huawei Technologies（美国）1700 Alma Dr.Suite 100 Plano，TX 75075美国
Phone: +1 603 436 8634
EMail: ietfdbh@comcast.net
Phone: +1 603 436 8634
EMail: ietfdbh@comcast.net
Joseph Salowey Cisco Systems 2901 3rd Ave Seattle, WA 98121 USA
美国华盛顿州西雅图第三大道2901号Joseph Salowey Cisco Systems 98121
EMail: jsalowey@cisco.com
EMail: jsalowey@cisco.com
Wes Hardaker Cobham Analytic Solutions P.O. Box 382 Davis, CA 95617 US
韦斯·哈达克·科巴姆分析解决方案美国加利福尼亚州戴维斯市382号信箱，邮编95617
Phone: +1 530 792 1913
EMail: ietf@hardakers.net
Phone: +1 530 792 1913
EMail: ietf@hardakers.net