《SecurityShellSSH协议中文版》由会员分享，可在线阅读，更多相关《SecurityShellSSH协议中文版（56页珍藏版）》请在金锄头文库上搜索。
1、KAMRJ金料検Security Shell(SSH)协议中文版KAMFU金赋科技Security Shell (SSH)协议中文版版本：1.0广东金赋信息科技有限公司Guangdong Kamfu In formati on & Tech no logy Co., Ltd.地址：广东省佛山市南海区桂城东平路瀚天科技城综合楼三楼邮编：528200电话：（0757）88023456 传真：（0757）88351111网址： 电子邮件： 文档信息标题Security Shell( SSH)协议中文版描述本文档是Security Shell(SSH)协议系列文档(RFC 42514254 )的中文翻
2、译。创建日期2011年6月10日翻译作者薛立徽修订记录日期版本描述作者第#页/共62页KAAARJ 金料技Security Shell(SSH)协议中文版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摘要21
3、1.简介212.撰稿者213.本文中的惯用约定214.连接建立224.1. 在TCP/IP 上使用224.2.协议版本交换225.与SSH旧版本的兼容性236.二进制数据包协议236.1.最大数据包长度236.2.压缩246.3.加密246.4.数据完整性256.5. 密钥交换方法266.6.公钥算法267.密钥交换287.1.算法协商297.2.密钥交换的输出3173密钥的交付使用328.Diffie -H ellman 密钥交换 328.1.DIFFIE - HELLMAN- GR0UP1- SHA1 348.2.DIFFIE - HELLMAN - GROUP14- SHA1 349.密
4、钥重新交换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 警告消息(Banner message) 416.验证协议消息编号427.公钥验证方法：PUBLICKEY 428.密码验证方法：PASSWORD，439.基于主机的验证
5、：HOSTBASED 4510.IANA考虑4611.安全性考虑4612.参考文献46SSH连接协议47摘要4747简介第#页/共62页KAMHJ金料技Security Shell（ SSH）协议中文版1. 撰写者2. 本文中的惯用约定473. 全局请求4. 信道机制4.1. 打开一个信道484.2. 数据传输4.3. 关闭一个信道514.4. 信道特定的请求525. 交互式会话5.1. 打开一个会话535.2. 请求一个伪终端535.3. X11 转发5.4. 环境变量传递545.5. 启动一个命令解释程序或一个命令555.6. 会话数据传输555.7. 窗口大小变化消息565.8. 本地流
6、程控制565.9. 信号(Signals)565.10. 返回终止状态(Exit Status) 576. TCP/IP 端口转发 586.1. 请求端口转发586.2. TCP/IP 转发信道597. 终端模式编码8. 消息编码总结9. IANA 考虑10. 安全性考虑4747485052536061626262参考文献第#页/共62页KAMHJ金料技Security Shell（ SSH）协议中文版SSH协议架构摘要SSH协议是在不安全的网络上进行安全远程登录和其他安全网络服务的协议。本文描述SSH协议的架构，以及SSH协议文档中所用的惯用约定和术语。本文也讨论了允许本地扩展的SSH算法命
7、名体系。SSH协议由三个主要部分组成：传输层协议(Tran sport Layer Protocol)提供服务器验证、保密性和完整性，具完全前向安全性( perfect forward secrecy)。验证协议(Authe nticatio n Protocol)向服务器验证客户端。连接协议(Conn ectionProtocol )将加密隧道复用为若干逻辑信道。1. 简介SSH(Security Shell )是在不安全的网络上进行安全远程登录和其他安全网络服务的协议。 它由三个主要部分组成：O 传输层协议SSH-TRANS提供服务器验证、保密性和完整性。它也可选的提供压缩。传输 层一般运
8、行在一个TCP/IP连接上，但也可能被用在任何其他可靠的数据流上。O 验证协议SSH-USERAUTH向服务器验证客户端用户。它运行在传输层协议上。O 连接协议SSH-CONNECT将加密隧道复用为若干逻辑信道。它运行在验证协议上。在一个安全的传输层连接被建立后，客户端发送一个服务请求。在用户验证完成后，第二个服务 请求被发出。这允许新的协议被定义并与上述协议共存。连接协议提供的信道可被用于广泛的目的。提供了标准方法用于建立安全的交互式shell进程以及转发(隧道)任意 TCP/IP 端口和X11连接。2. 撰稿者(略)3. 本文中的惯用约定所有与SSH协议相关的文档都应使用关键词“必须”、“
9、禁止(绝不能)”、“必须的”、“应”、 “不应”、“推荐”、“可(能) ”、“可选的”来描述要求。这些关键词的含义符合RFC2119 的描述。本文中用于描述命名空间分配的关键词 PRIVATE USE 、HIERARCHICAL ALLOCATION、 FIRST COME FIRST SERVED 、EXPERT REVIEW 、SPECIFICATION REQUIRED、 IESG APPROVAL、IETF CONSENSUS以及STANDARDS ACTION的含义符合RFC2434 的描述。协议文档中定义了协议域和可能的取值。协议域将在消息定义中定义。例如，SSH_MSG_CHAN
10、NEL_DATA勺定义如下：byteSSH_MSG_CHANNEL_DATAuin t32recipie ntcha nnelstri ngdata在整套协议文档中，当引用域时，域的名称出现在单引号中。当引用域的值时，它们出现在双引 号中。例如，data 的可能取值是” foo 和” bar”。4. 架构4.1. 主机密钥每一个服务器主机应有一个主机密钥。 主机可有多个使用不同算法的主机密钥。 多个主机可共享 相同的主机密钥。如果主机具有密钥，那么对每一种必须的公钥算法（ DSS）必须有至少一个密 钥。服务器主机密钥在密钥交换中用于检验客户端真的是在和正确的服务器对话。为使之可能，客户 端必须
11、事先知道服务器主机密钥的公钥。两个不同的信任模型可被使用:O 客户端有一个本地的数据库，将每个主机名（与用户输入相同）与对应的主机密钥公钥关 联起来。这种方法不需要集中管理的基础架构或第三方的配合。缺点是主机名-密钥关联数据库的维护可能成为一个负担。O 主机名-密钥关联由一个可信的认证机构（CA）证明。客户端只知道CA根密钥，并且能够 检验所有由CA认证的主机密钥的有效性。第二种方式消除了维护问题，因为理想的只有一 个CA密钥需要被安全的保存在客户端。但另一方面，在进行验证前，每个主机密钥必须被 一个中心机构以适当的方式认证。同时，中心基础架构被寄予了极大的信任。协议提供提供了这种选项：在第一
12、次连接到主机时不检查服务器名-主机密钥的关联。这允许在 事先不知道主机密钥或证书的情况下进行通信。连接仍然提供对被动侦听（passive liste ning）的保护；但是，它容易受到主动的中间人攻击（active ma n-in-the-middleattacks ）。系统实现正常情况不应默认的允许这种连接，因其造成潜在的安全问题。但是， 由于在撰写本文时互联网上没有一个被广泛部署的密钥基础架构，这一选项使协议在这种基础架构出现前的过渡时期内的可用性大幅提高，同时仍然提供了比旧的解决方案（如tel net 和rlogi n ）高得多的安全性。系统实现应尽量检查主机密钥。一个可能的策略是：只有
13、当第一次连接到一个主机时才不经检查 的接受主机密钥，把密钥保存到本地数据库，在将来所有的到该主机的连接中都以此为基准进行 对比。系统实现可提供附加的方法来检验主机密钥的正确性，例如，通过SHA-1哈希从公钥产生一个十六进制的数字指纹。这种数字指纹能够很容易的用电话或其他外部通信通道来检验。所有系统实现应提供一个选项：不接受不能被检验的主机密钥。第#页/共62页KAMHJ金料技Security Shell（ SSH）协议中文版本工作组的成员相信“易用”是终端用户接受安全解决方案的关键， 如果新的解决方案没有并采 用，就不会带来任何安全性的提高。因此，提供不检查服务器主机密钥的选项提高了 In t
14、ernet 整体的安全性，尽管在允许该选项的设置中它降低了协议的安全性。4.2. 扩展性我们相信协议将会随时间演化，一些组织将希望使用它们自己的加密、 验证及/或密钥交互方法。 对所有扩展进行集中注册是繁琐的， 特别对于试验性或保密的特性。另一方面，没有集中注册会 导致方法标识符冲突，影响互操作性。我们选择通过特定格式的名称来标识算法、方法、格式和扩展协议。DNS名称被用于创建本地命 名空间，在其中可定义试验性或保密的扩展而不用担心与其他系统实现相冲突。一个设计目标是保持基础协议尽可能简单， 并且要求尽可能少的算法。但是，所有系统实现必须 支持一个最小的算法集合以保证互操作性（这不表示所有主机上的本地策略要允许这些算法）。 强制
