Security-Shell(SSH)协议-中文版

SecurityShell（SSH）协议中文版版本：1.0广东金赋信息科技有限公司GuangdongKamfuInformation&TechnologyCo.,Ltd.地址：广东省佛山市南海区桂城东平路瀚天科技城综合楼三楼邮编：528200电话：[phone]传真：[phone]网址：电子邮件：[e-mail]（SSH）协议中文版第2页/共62页文档信息标题SecurityShell（SSH）协议中文版描述本文档是SecurityShell（SSH）协议系列文档（RFC4251～4254）的中文翻译。创建日期2011年6月10日翻译作者薛立徽修订记录日期版本描述作者SecurityShell（SSH）协议中文版第3页/共62页目录SSH协议架构6摘要61.简介62.撰稿者63.本文中的惯用约定64.架构74.1.主机密钥74.2.扩展性84.3.策略问题84.4.安全特性84.5.本地化和字符集支持95.SSH协议使用的数据类型表示法96.算法和方法命名117.消息编号118.IANA考虑129.安全性考虑139.1.伪随机数生成139.2.控制字符筛选139.3.传输139.4.验证协议179.5.连接协议1910.参考文献20SSH传输层协议21摘要211.简介212.撰稿者213.本文中的惯用约定214.连接建立224.1.在TCP/IP上使用224.2.协议版本交换225.与SSH旧版本的兼容性236.二进制数据包协议236.1.昀大数据包长度236.2.压缩246.3.加密246.4.数据完整性256.5.密钥交换方法26SecurityShell（SSH）协议中文版第4页/共62页6.6.公钥算法267.密钥交换287.1.算法协商297.2.密钥交换的输出317.3.密钥的交付使用328.DIFFIE-HELLMAN密钥交换328.1.DIFFIE-HELLMAN-GROUP1-SHA1348.2.DIFFIE-HELLMAN-GROUP14-SHA1349.密钥重新交换3410.服务请求3411.附加消息3511.1.断开连接消息3511.2.被忽略的数据消息3611.3.除错消息3611.4.保留消息3612.消息编号总结3713.IANA考虑3714.安全性考虑3715.参考文献37SSH验证协议38摘要381.简介382.撰写者383.本文中的惯用约定384.验证协议框架395.验证请求395.1.对验证请求的响应405.2.NONE验证请求415.3.完成用户验证415.4.警告消息（BANNERMESSAGE）416.验证协议消息编号427.公钥验证方法：PUBLICKEY428.密码验证方法：PASSWORD439.基于主机的验证：HOSTBASED4510.IANA考虑4611.安全性考虑4612.参考文献46SSH连接协议47摘要471.简介47SecurityShell（SSH）协议中文版第5页/共62页2.撰写者473.本文中的惯用约定474.全局请求475.信道机制485.1.打开一个信道485.2.数据传输505.3.关闭一个信道515.4.信道特定的请求526.交互式会话526.1.打开一个会话536.2.请求一个伪终端536.3.X11转发536.4.环境变量传递546.5.启动一个命令解释程序或一个命令556.6.会话数据传输556.7.窗口大小变化消息566.8.本地流程控制566.9.信号（SIGNALS）566.10.返回终止状态（EXITSTATUS）577.TCP/IP端口转发587.1.请求端口转发587.2.TCP/IP转发信道598.终端模式编码609.消息编码总结6110.IANA考虑6211.安全性考虑6212.参考文献62SecurityShell（SSH）协议中文版第6页/共62页SSH协议架构摘要SSH协议是在不安全的网络上进行安全远程登录和其他安全网络服务的协议。本文描述SSH协议的架构，以及SSH协议文档中所用的惯用约定和术语。本文也讨论了允许本地扩展的SSH算法命名体系。SSH协议由三个主要部分组成：传输层协议（TransportLayerProtocol）提供服务器验证、保密性和完整性，具完全前向安全性（perfectforwardsecrecy）。验证协议（AuthenticationProtocol）向服务器验证客户端。连接协议（ConnectionProtocol）将加密隧道复用为若干逻辑信道。1.简介SSH（SecurityShell）是在不安全的网络上进行安全远程登录和其他安全网络服务的协议。它由三个主要部分组成：○传输层协议[SSH-TRANS]提供服务器验证、保密性和完整性。它也可选的提供压缩。传输层一般运行在一个TCP/IP连接上，但也可能被用在任何其他可靠的数据流上。○验证协议[SSH-USERAUTH]向服务器验证客户端用户。它运行在传输层协议上。○连接协议[SSH-CONNECT]将加密隧道复用为若干逻辑信道。它运行在验证协议上。在一个安全的传输层连接被建立后，客户端发送一个服务请求。在用户验证完成后，第二个服务请求被发出。这允许新的协议被定义并与上述协议共存。连接协议提供的信道可被用于广泛的目的。提供了标准方法用于建立安全的交互式shell进程以及转发（隧道）任意TCP/IP端口和X11连接。2.撰稿者（略）3.本文中的惯用约定所有与SSH协议相关的文档都应使用关键词“必须”、“禁止（绝不能）”、“必须的”、“应”、“不应”、“推荐”、“可（能）”、“可选的”来描述要求。这些关键词的含义符合[RFC2119]的描述。本文中用于描述命名空间分配的关键词PRIVATEUSE、HIERARCHICALALLOCATION、FIRSTCOMEFIRSTSERVED、EXPERTREVIEW、SPECIFICATIONREQUIRED、IESGAPPROVAL、IETFCONSENSUS以及STANDARDSACTION的含义符合[RFC2434]的描述。协议文档中定义了协议域和可能的取值。协议域将在消息定义中定义。例如，SSH_MSG_CHANNEL_DATA的定义如下：SecurityShell（SSH）协议中文版第7页/共62页byteSSH_MSG_CHANNEL_DATAuint32recipientchannelstringdata在整套协议文档中，当引用域时，域的名称出现在单引号中。当引用域的值时，它们出现在双引号中。例如，’data’的可能取值是”foo”和”bar”。4.架构4.1.主机密钥每一个服务器主机应有一个主机密钥。主机可有多个使用不同算法的主机密钥。多个主机可共享相同的主机密钥。如果主机具有密钥，那么对每一种必须的公钥算法（DSS）必须有至少一个密钥。服务器主机密钥在密钥交换中用于检验客户端真的是在和正确的服务器对话。为使之可能，客户端必须事先知道服务器主机密钥的公钥。两个不同的信任模型可被使用：○客户端有一个本地的数据库，将每个主机名（与用户输入相同）与对应的主机密钥公钥关联起来。这种方法不需要集中管理的基础架构或第三方的配合。缺点是主机名-密钥关联数据库的维护可能成为一个负担。○主机名-密钥关联由一个可信的认证机构（CA）证明。客户端只知道CA根密钥，并且能够检验所有由CA认证的主机密钥的有效性。第二种方式消除了维护问题，因为理想的只有一个CA密钥需要被安全的保存在客户端。但另一方面，在进行验证前，每个主机密钥必须被一个中心机构以适当的方式认证。同时，中心基础架构被寄予了极大的信任。协议提供提供了这种选项：在第一次连接到主机时不检查服务器名-主机密钥的关联。这允许在事先不知道主机密钥或证书的情况下进行通信。连接仍然提供对被动侦听（passivelistening）的保护；但是，它容易受到主动的中间人攻击（activeman-in-the-middleattacks）。系统实现正常情况不应默认的允许这种连接，因其造成潜在的安全问题。但是，由于在撰写本文时互联网上没有一个被广泛部署的密钥基础架构，这一选项使协议在这种基础架构出现前的过渡时期内的可用性大幅提高，同时仍然提供了比旧的解决方案（如telnet和rlogin）高得多的安全性。系统实现应尽量检查主机密钥。一个可能的策略是：只有当第一次连接到一个主机时才不经检查的接受主机密钥，把密钥保存到本地数据库，在将来所有的到该主机的连接中都以此为基准进行对比。系统实现可提供附加的方法来检验主机密钥的正确性，例如，通过SHA-1哈希从公钥产生一个十六进制的数字指纹。这种数字指纹能够很容易的用电话或其他外部通信通道来检验。所有系统实现应提供一个选项：不接受不能被检验的主机密钥。SecurityShell（SSH）协议中文版第8页/共62页本工作组的成员相信“易用”是终端用户接受安全解决方案的关键，如果新的解决方案没有并采用，就不会带来任何安全性的提高。因此，提供不检查服务器主机密钥的选项提高了Internet整体的安全性，尽管在允许该选项的设置中它降低了协议的安全性。4.2.扩展性我们相信协议将会随时间演化，一些组织将希望使用它们自己的加密、验证及/或密钥交互方法。对所有扩展进行集中注册是繁琐的，特别对于试验性或保密的特性。另一方面，没有集中注册会导致方法标识符冲突，影响互操作性。我们选择通过特定格式的名称来标识算法、方法、格式和扩展协议。DNS名称被用于创建本地命名空间，在其中可定义试验性或保密的扩展而不用担心与其他系统实现相冲突。一个设计目标是保持基础协议尽可能简单，并且要求尽可能少的算法。但是，所有系统实现必须支持一个昀小的算法集合以保证互操作性（这不表示所有主机上的本地策略要允许这些算法）。强制性的算法在相关协议文档中规定。附加的算法、方法、格式和扩展协议可在单独的文档中定义。参见第6节，算法命名。4.3.策略问题协议允许对加密、完整性、密钥交换、压缩以及公钥算法和格式进行完整的协商。两个传输方向的加密、完整性、公钥和压缩算法可以不同。下列策略问题应在系统实现的配置机制中被解决：○每个传输方向的加密、完整性和压缩算法。策略必须规定哪一个是优选算法（例如，在每个类别下列出的第一个算法）。○主机验证使用的公钥算法和密钥交换方法。已存在的使用不同算法的受信任的主机密钥也影响这一选择。○服务器对每个用户要求的验证方法。服务器的策略可对一些或所有用户要求多重认证。要求的算法可依赖于用户试图获得授权时所在的位置。○用户被允许使用连接协议进行的操作。一些问题与安全性有关；例如，策略不应允许服务器在客户机上启动进程或运行命令，并且必须不允许连接到验证代理，除非被要求转发这样的连接。另一些问题，例如谁能够转发那个TCP/IP端口，非常明显是本地策略。很多这样的问题可能涉及穿越或绕过防火墙，并且与本地安全策略互相联系。4.4.安全特性SSH协议的主要目的是改善Internet的安全性。它尝试通过一种容易部署的方式实现该目的，为此，甚至不惜牺牲绝对安全。○所使用的所有加密、完整性，以及公钥算法都是广为人知的、成熟的算法。SecurityShell（SSH）协议中文版第9页/共62页○所有算法都使用从密码学看来合理的密钥长度，即密钥长度被认为能在几十年内提供对昀强的密钥解析攻击的保护。○所有算法都透过协商，在某些算法失效的情况下，可以容易的切换到其他算法而不需要修改基础协议。为了使大范围、快速的部署容易实现，协议做了特定的妥协。具体而言，在验证服务器主机密钥确实属于目标主机方面，协议允许不进行验证，但这是不推荐的。这被认为在短期内能够显著的改善协议的可用性，直到出现普及的Internet公钥基础架构。4.5.本地化和字符集支持在大多数情况下，SSH协议不直接传递会显示给用户的文本。但是，有些情况下这种数据可能被传递。当可应用时，数据的字符集必须被显式的规定。