通过安全SHell（SSH）使用NETCONF配置协议
The NETCONF protocol [RFC4721] is an XML-based protocol used to manage the configuration of networking equipment. NETCONF is defined to be session-layer and transport independent, allowing mappings to be defined for multiple session-layer or transport protocols. This document defines how NETCONF can be used within a Secure Shell (SSH) session, using the SSH connection protocol [RFC4254] over the SSH transport protocol [RFC4253]. This mapping will allow NETCONF to be executed from a secure shell session by a user or application.
NETCONF协议[RFC4721]是一种基于XML的协议，用于管理网络设备的配置。NETCONF被定义为会话层和传输独立，允许为多个会话层或传输协议定义映射。本文档定义了如何在安全Shell（SSH）会话中使用NETCONF，通过SSH传输协议[RFC4253]使用SSH连接协议[RFC4254]。此映射将允许用户或应用程序从安全shell会话执行NETCONF。
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. The terms “manager” and “agent” are used to refer to the two ends of the NETCONF protocol session. The manager issues NETCONF remote procedure call (RPC) commands, and the agent replies to those commands. When NETCONF is run over SSH using the mapping defined in this document, the client is always the manager, and the server is always the agent.
在本文档中，术语“客户机”和“服务器”用于表示SSH传输连接的两端。客户端主动打开SSH连接，服务器被动侦听传入的SSH连接。术语“管理器”和“代理”用于表示NETCONF协议会话的两端。管理器发出NETCONF远程过程调用（RPC）命令，代理对这些命令进行响应。当使用本文档中定义的映射在SSH上运行NETCONF时，客户机始终是管理器，服务器始终是代理。
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 RFC 2119 [RFC2119].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC2119]中所述进行解释。
To run NETCONF over SSH, the client will first establish an SSH transport connection using the SSH transport protocol, and the client and server will exchange keys for message integrity and encryption. The client will then invoke the “ssh-userauth” service to authenticate the user, as described in the SSH authentication protocol [RFC4252]. Once the user has been successfully authenticated, the client will invoke the “ssh-connection” service, also known as the SSH connection protocol.
要通过SSH运行NETCONF，客户端将首先使用SSH传输协议建立SSH传输连接，客户端和服务器将交换消息完整性和加密的密钥。然后，客户端将调用“ssh userauth”服务对用户进行身份验证，如ssh身份验证协议[RFC4252]中所述。一旦用户成功通过身份验证，客户端将调用“ssh连接”服务，也称为ssh连接协议。
After the ssh-connection service is established, the client will open a channel of type “session”, which will result in an SSH session.
建立ssh连接服务后，客户端将打开一个类型为“session”的通道，这将导致一个ssh会话。
Once the SSH session has been established, the user (or application) will invoke NETCONF as an SSH subsystem called “netconf”. Subsystem support is a feature of SSH version 2 (SSHv2) and is not included in SSHv1. Running NETCONF as an SSH subsystem avoids the need for the script to recognize shell prompts or skip over extraneous information, such as a system message that is sent at shell start-up. However, even when a subsystem is used, some extraneous messages may
一旦建立了SSH会话，用户（或应用程序）将调用NETCONF作为名为“NETCONF”的SSH子系统。子系统支持是SSH版本2（SSHv2）的一项功能，不包含在SSHv1中。将NETCONF作为SSH子系统运行，避免了脚本识别shell提示或跳过无关信息（如shell启动时发送的系统消息）的需要。但是，即使使用子系统，也可能会出现一些无关的消息
be printed by the user’s start-up scripts. Implementations MUST skip over these messages by searching for an ‘xml’ start directive, which MUST be followed by a <hello> element in the ‘NETCONF’ namespace.
由用户的启动脚本打印。实现必须通过搜索“xml”start指令跳过这些消息，该指令后面必须有“NETCONF”命名空间中的<hello>元素。
In order to allow NETCONF traffic to be easily identified and filtered by firewalls and other network devices, NETCONF servers MUST default to providing access to the “netconf” SSH subsystem only when the SSH session is established using the IANA-assigned TCP port <830>. Servers SHOULD be configurable to allow access to the netconf SSH subsystem over other ports.
为了允许防火墙和其他网络设备轻松识别和过滤NETCONF流量，NETCONF服务器必须默认为仅在使用IANA分配的TCP端口<830>建立SSH会话时提供对“NETCONF”SSH子系统的访问。服务器应可配置为允许通过其他端口访问netconf SSH子系统。
A user (or application) could use the following command line to invoke NETCONF as an SSH subsystem on the IANA-assigned port:
用户（或应用程序）可以使用以下命令行调用NETCONF作为IANA分配端口上的SSH子系统：
[user@client]$ ssh -s server.example.org -p <830> netconf
Note that the -s option causes the command (“netconf”) to be invoked as an SSH subsystem.
注意，-s选项导致命令（“netconf”）作为SSH子系统调用。
The server MUST indicate its capabilities by sending an XML document containing a <hello> element as soon as the NETCONF session is established. The user (or application) can parse this message to determine which NETCONF capabilities are supported by the server.
一旦NETCONF会话建立，服务器必须通过发送包含<hello>元素的XML文档来指示其功能。用户（或应用程序）可以解析此消息，以确定服务器支持哪些NETCONF功能。
The client must also send an XML document containing a <hello> element to indicate the client’s capabilities to the server. The document containing the <hello> element MUST be the first XML document that the client sends after the NETCONF session is established.
客户端还必须向服务器发送包含<hello>元素的XML文档，以指示客户端的功能。包含<hello>元素的文档必须是NETCONF会话建立后客户端发送的第一个XML文档。
The following example shows a capability exchange. Messages sent by the client are marked with “C:”, and messages sent by the server are marked with “S:”.
下面的示例显示了一个功能交换。客户端发送的消息标记为“C:”，服务器发送的消息标记为“S:”
S: <?xml version="1.0" encoding="UTF-8"?>
S: <hello>
S: <capabilities>
S: <capability>
S: urn:ietf:params:xml:ns:netconf:base:1.0
S: </capability>
S: <capability>
S: urn:ietf:params:ns:netconf:capability:startup:1.0
S: </capability>
S: </capabilities>
S: <session-id>4<session-id>
S: </hello>
S: ]]>]]>
C: <?xml version="1.0" encoding="UTF-8"?>
C: <hello>
C: <capabilities>
C: <capability>
C: urn:ietf:params:xml:ns:netconf:base:1.0
C: </capability>
C: </capabilities>
C: </hello>
C: ]]>]]>
尽管该示例显示服务器发送一条<hello>消息，然后是客户机的消息，但双方将在NETCONF子系统初始化后立即发送消息，可能是同时发送。
As the previous example illustrates, a special character sequence, ]]>]]>, MUST be sent by both the client and the server after each XML document in the NETCONF exchange. This character sequence cannot legally appear in an XML document, so it can be unambiguously used to identify the end of the current document, allowing resynchronization of the NETCONF exchange in the event of an XML syntax or parsing error.
如前一个示例所示，在NETCONF交换中的每个XML文档之后，客户端和服务器都必须发送一个特殊的字符序列[]]>]]]>。此字符序列不能合法地出现在XML文档中，因此可以明确地将其用于标识当前文档的结尾，从而允许在出现XML语法或解析错误时重新同步NETCONF交换。
A NETCONF over SSH session consists of the manager and agent exchanging complete XML documents. Once the session has been established and capabilities have been exchanged, the manager will send complete XML documents containing <rpc> elements to the server, and the agent will respond with complete XML documents containing <rpc-reply> elements.
NETCONF over SSH会话由交换完整XML文档的管理器和代理组成。建立会话并交换功能后，管理器将向服务器发送包含<rpc>元素的完整XML文档，代理将使用包含<rpc reply>元素的完整XML文档进行响应。
To continue the example given above, an NETCONF over SSH session to retrieve a set of configuration information might look like this:
要继续上面给出的示例，用于检索一组配置信息的NETCONF over SSH会话可能如下所示：
C: <?xml version="1.0" encoding="UTF-8"?>
C: <rpc message-id="105"
C: xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
C: <get-config>
C: <source><running/></source>
C: <config xmlns="http://example.com/schema/1.2/config">
C: <users/>
C: </config>
C: </get-config>
C: </rpc>
C: ]]>]]>
S: <?xml version="1.0" encoding="UTF-8"?>
S: <rpc-reply message-id="105"
S: xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
S: <config xmlns="http://example.com/schema/1.2/config">
S: <users>
S: <user><name>root</name><type>superuser</type></user>
S: <user><name>fred</name><type>admin</type></user>
S: <user><name>barney</name><type>admin</type></user>
S: </users>
S: </config>
S: </rpc-reply>
S: ]]>]]>
Exiting NETCONF is accomplished using the <close-session> operation. An agent will process RPC messages from the manager in the order in which they are received. When the agent processes a <close-session> command, the agent shall respond and close the SSH session channel. The agent MUST NOT process any RPC commands received on the current session after the <close-session> command.
退出NETCONF是使用<close session>操作完成的。代理将按照接收的顺序处理来自管理器的RPC消息。当代理处理<close session>命令时，代理应响应并关闭SSH会话通道。在执行<close session>命令之后，代理程序不得处理当前会话上收到的任何RPC命令。
To continue the example used in previous sections, an existing NETCONF subsystem session could be closed as follows:
要继续前面章节中使用的示例，可以按如下方式关闭现有NETCONF子系统会话：
C: <?xml version="1.0" encoding="UTF-8"?>
C: <rpc message-id="106"
C: xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
C: <close-session/>
C: </rpc>
C: ]]>]]>
S: <?xml version="1.0" encoding="UTF-8"?>
S: <rpc-reply id="106"
S: xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
S: <ok/>
S: </rpc-reply>
S: ]]>]]>