Security_Shell(SSH)协议_中文版.pdf

发布时间：2022-05-29 发布人：admin 分类：说明书资料大小：0.42M 资料格式：pdf 举报版权申诉

ls1989822-5717109-4744300845375441459.pdf-第1页.png

第1页 / 共62页

ls1989822-5717109-4744300845375441459.pdf-第2页.png

第2页 / 共62页

ls1989822-5717109-4744300845375441459.pdf-第3页.png

第3页 / 共62页

ls1989822-5717109-4744300845375441459.pdf-第4页.png

第4页 / 共62页

ls1989822-5717109-4744300845375441459.pdf-第5页.png

第5页 / 共62页

ls1989822-5717109-4744300845375441459.pdf-第6页.png

第6页 / 共62页

ls1989822-5717109-4744300845375441459.pdf-第7页.png

第7页 / 共62页

ls1989822-5717109-4744300845375441459.pdf-第8页.png

第8页 / 共62页

SSH协议架构

摘要

1. 简介

2. 撰稿者

3. 本文中的惯用约定

4. 架构

4.1. 主机密钥

4.2. 扩展性

4.3. 策略问题

4.4. 安全特性

4.5. 本地化和字符集支持

5. SSH协议使用的数据类型表示法

6. 算法和方法命名

7. 消息编号

8. IANA考虑

9. 安全性考虑

9.1. 伪随机数生成

9.2. 控制字符筛选

9.3. 传输

9.4. 验证协议

9.5. 连接协议

10. 参考文献

SSH传输层协议

摘要

1. 简介

2. 撰稿者

3. 本文中的惯用约定

4. 连接建立

4.1. 在TCP/IP上使用

4.2. 协议版本交换

5. 与SSH旧版本的兼容性

6. 二进制数据包协议

6.1. 最大数据包长度

6.2. 压缩

6.3. 加密

6.4. 数据完整性

6.5. 密钥交换方法

6.6. 公钥算法

7. 密钥交换

7.1. 算法协商

7.2. 密钥交换的输出

7.3. 密钥的交付使用

8. Diffie-Hellman密钥交换

8.1. diffie-hellman-group1-sha1

8.2. diffie-hellman-group14-sha1

9. 密钥重新交换

10. 服务请求

11. 附加消息

11.1. 断开连接消息

11.2. 被忽略的数据消息

11.3. 除错消息

11.4. 保留消息

12. 消息编号总结

13. IANA考虑

14. 安全性考虑

15. 参考文献

SSH验证协议

摘要

1. 简介

2. 撰写者

3. 本文中的惯用约定

4. 验证协议框架

5. 验证请求

5.1. 对验证请求的响应

5.2. "none"验证请求

5.3. 完成用户验证

5.4. 警告消息（Banner Message）

6. 验证协议消息编号

7. 公钥验证方法："publickey"

8. 密码验证方法："password"

9. 基于主机的验证："hostbased"

10. IANA考虑

11. 安全性考虑

12. 参考文献

SSH连接协议

摘要

1. 简介

2. 撰写者

3. 本文中的惯用约定

4. 全局请求

5. 信道机制

5.1. 打开一个信道

5.2. 数据传输

5.3. 关闭一个信道

5.4. 信道特定的请求

6. 交互式会话

6.1. 打开一个会话

6.2. 请求一个伪终端

6.3. X11转发

6.4. 环境变量传递

6.5. 启动一个命令解释程序或一个命令

6.6. 会话数据传输

6.7. 窗口大小变化消息

6.8. 本地流程控制

6.9. 信号（Signals）

6.10. 返回终止状态（Exit Status）

7. TCP/IP端口转发

7.1. 请求端口转发

7.2. TCP/IP转发信道

8. 终端模式编码

9. 消息编码总结

10. IANA考虑

11. 安全性考虑

12. 参考文献

Security Shell（SSH）协议中文版版本：1.0 广东金赋信息科技有限公司 Guangdong Kamfu Information & Technology Co., Ltd. 地址：广东省佛山市南海区桂城东平路瀚天科技城综合楼三楼邮编：528200 电话：(0757)88023456 传真：(0757)88351111 网址：www.kamfu.com.cn 电子邮件：kamfu@kamfu.com.cn

Security Shell（SSH）协议中文版 Security Shell（SSH）协议中文版本文档是 Security Shell（SSH）协议系列文档（RFC 4251～4254）的中文翻译。 2011 年 6 月 10 日薛立徽版本描述作者文档信息标题描述创建日期翻译作者修订记录日期第 2 页/共 62 页

目录 Security Shell（SSH）协议中文版 SSH 协议架构摘要 1. 简介 2. 撰稿者 3. 本文中的惯用约定 4. 架构 4.1. 主机密钥 4.2. 扩展性 4.3. 策略问题 4.4. 安全特性 4.5. 本地化和字符集支持 5. SSH 协议使用的数据类型表示法 6. 算法和方法命名 7. 消息编号 8. IANA 考虑 9. 安全性考虑 9.1. 伪随机数生成 9.2. 控制字符筛选 9.3. 传输 9.4. 验证协议 9.5. 连接协议 10. 参考文献 SSH 传输层协议摘要 1. 简介 2. 撰稿者 3. 本文中的惯用约定 4. 连接建立 4.1. 在 TCP/IP 上使用 4.2. 协议版本交换 5. 与 SSH 旧版本的兼容性 6. 二进制数据包协议 6.1. 最大数据包长度 6.2. 压缩 6.3. 加密 6.4. 数据完整性 6.5. 密钥交换方法第 3 页/共 62 页 6 6 6 6 6 7 7 8 8 8 9 9 11 11 12 13 13 13 13 17 19 20 21 21 21 21 21 22 22 22 23 23 23 24 24 25 26

6.6. 公钥算法 7. 密钥交换 7.1. 算法协商 7.2. 密钥交换的输出 7.3. 密钥的交付使用 8. DIFFIE-HELLMAN 密钥交换 8.1. DIFFIE-HELLMAN-GROUP1-SHA1 8.2. DIFFIE-HELLMAN-GROUP14-SHA1 9. 密钥重新交换 10. 服务请求 11. 附加消息 11.1. 断开连接消息 11.2. 被忽略的数据消息 11.3. 除错消息 11.4. 保留消息 12. 消息编号总结 13. IANA 考虑 14. 安全性考虑 15. 参考文献 SSH 验证协议摘要 1. 简介 2. 撰写者 3. 本文中的惯用约定 4. 验证协议框架 5. 验证请求 5.1. 对验证请求的响应 5.2. "NONE"验证请求 5.3. 完成用户验证 5.4. 警告消息（BANNER MESSAGE） 6. 验证协议消息编号 7. 公钥验证方法："PUBLICKEY" 8. 密码验证方法："PASSWORD" 9. 基于主机的验证："HOSTBASED" 10. IANA 考虑 11. 安全性考虑 12. 参考文献 SSH 连接协议摘要 1. 简介 Security Shell（SSH）协议中文版 26 28 29 31 32 32 34 34 34 34 35 35 36 36 36 37 37 37 37 38 38 38 38 38 39 39 40 41 41 41 42 42 43 45 46 46 46 47 47 47 第 4 页/共 62 页

2. 撰写者 3. 本文中的惯用约定 4. 全局请求 5. 信道机制 5.1. 打开一个信道 5.2. 数据传输 5.3. 关闭一个信道 5.4. 信道特定的请求 6. 交互式会话 6.1. 打开一个会话 6.2. 请求一个伪终端 6.3. X11 转发 6.4. 环境变量传递 6.5. 启动一个命令解释程序或一个命令 6.6. 会话数据传输 6.7. 窗口大小变化消息 6.8. 本地流程控制 6.9. 信号（SIGNALS） 6.10. 返回终止状态（EXIT STATUS） 7. TCP/IP 端口转发 7.1. 请求端口转发 7.2. TCP/IP 转发信道 8. 终端模式编码 9. 消息编码总结 10. IANA 考虑 11. 安全性考虑 12. 参考文献 Security Shell（SSH）协议中文版 47 47 47 48 48 50 51 52 52 53 53 53 54 55 55 56 56 56 57 58 58 59 60 61 62 62 62 第 5 页/共 62 页

Security Shell（SSH）协议中文版 SSH 协议架构摘要 SSH 协议是在不安全的网络上进行安全远程登录和其他安全网络服务的协议。本文描述 SSH 协议的架构，以及 SSH 协议文档中所用的惯用约定和术语。本文也讨论了允许本地扩展的 SSH 算法命名体系。SSH 协议由三个主要部分组成：传输层协议（Transport Layer Protocol）提供服务器验证、保密性和完整性，具完全前向安全性（perfect forward secrecy）。验证协议（Authentication Protocol）向服务器验证客户端。连接协议（Connection Protocol）将加密隧道复用为若干逻辑信道。 1. 简介 SSH（Security Shell）是在不安全的网络上进行安全远程登录和其他安全网络服务的协议。它由三个主要部分组成： ○ 传输层协议[SSH-TRANS]提供服务器验证、保密性和完整性。它也可选的提供压缩。传输层一般运行在一个 TCP/IP 连接上，但也可能被用在任何其他可靠的数据流上。 ○ 验证协议[SSH-USERAUTH]向服务器验证客户端用户。它运行在传输层协议上。 ○ 连接协议[SSH-CONNECT]将加密隧道复用为若干逻辑信道。它运行在验证协议上。在一个安全的传输层连接被建立后，客户端发送一个服务请求。在用户验证完成后，第二个服务请求被发出。这允许新的协议被定义并与上述协议共存。连接协议提供的信道可被用于广泛的目的。提供了标准方法用于建立安全的交互式 shell 进程以及转发（隧道）任意 TCP/IP 端口和 X11 连接。 2. 撰稿者（略） 3. 本文中的惯用约定所有与 SSH 协议相关的文档都应使用关键词“必须”、“禁止（绝不能）”、“必须的”、“应”、 “不应”、“推荐”、“可（能）”、“可选的”来描述要求。这些关键词的含义符合[RFC2119] 的描述。本文中用于描述命名空间分配的关键词"PRIVATE USE"、"HIERARCHICAL ALLOCATION"、 "FIRST COME FIRST SERVED"、 "EXPERT REVIEW"、"SPECIFICATION REQUIRED"、 "IESG APPROVAL"、"IETF CONSENSUS"以及"STANDARDS ACTION"的含义符合[RFC2434] 的描述。协议文档中定义了协议域和可能的取值。协议域将在消息定义中定义。例如， SSH_MSG_CHANNEL_DATA 的定义如下：第 6 页/共 62 页

Security Shell（SSH）协议中文版 byte uint32 string SSH_MSG_CHANNEL_DATA recipient channel data 在整套协议文档中，当引用域时，域的名称出现在单引号中。当引用域的值时，它们出现在双引号中。例如，’data’的可能取值是”foo”和”bar”。 4. 架构 4.1. 主机密钥每一个服务器主机应有一个主机密钥。主机可有多个使用不同算法的主机密钥。多个主机可共享相同的主机密钥。如果主机具有密钥，那么对每一种必须的公钥算法（DSS）必须有至少一个密钥。服务器主机密钥在密钥交换中用于检验客户端真的是在和正确的服务器对话。为使之可能，客户端必须事先知道服务器主机密钥的公钥。两个不同的信任模型可被使用： ○ 客户端有一个本地的数据库，将每个主机名（与用户输入相同）与对应的主机密钥公钥关联起来。这种方法不需要集中管理的基础架构或第三方的配合。缺点是主机名-密钥关联数据库的维护可能成为一个负担。 ○ 主机名-密钥关联由一个可信的认证机构（CA）证明。客户端只知道 CA 根密钥，并且能够检验所有由 CA 认证的主机密钥的有效性。第二种方式消除了维护问题，因为理想的只有一个 CA 密钥需要被安全的保存在客户端。但另一方面，在进行验证前，每个主机密钥必须被一个中心机构以适当的方式认证。同时，中心基础架构被寄予了极大的信任。协议提供提供了这种选项：在第一次连接到主机时不检查服务器名-主机密钥的关联。这允许在事先不知道主机密钥或证书的情况下进行通信。连接仍然提供对被动侦听（ passive listening）的保护；但是，它容易受到主动的中间人攻击（active man-in-the-middle attacks）。系统实现正常情况不应默认的允许这种连接，因其造成潜在的安全问题。但是，由于在撰写本文时互联网上没有一个被广泛部署的密钥基础架构，这一选项使协议在这种基础架构出现前的过渡时期内的可用性大幅提高，同时仍然提供了比旧的解决方案（如 telnet 和 rlogin）高得多的安全性。系统实现应尽量检查主机密钥。一个可能的策略是：只有当第一次连接到一个主机时才不经检查的接受主机密钥，把密钥保存到本地数据库，在将来所有的到该主机的连接中都以此为基准进行对比。系统实现可提供附加的方法来检验主机密钥的正确性，例如，通过 SHA-1 哈希从公钥产生一个十六进制的数字指纹。这种数字指纹能够很容易的用电话或其他外部通信通道来检验。所有系统实现应提供一个选项：不接受不能被检验的主机密钥。第 7 页/共 62 页

Security Shell（SSH）协议中文版本工作组的成员相信“易用”是终端用户接受安全解决方案的关键，如果新的解决方案没有并采用，就不会带来任何安全性的提高。因此，提供不检查服务器主机密钥的选项提高了 Internet 整体的安全性，尽管在允许该选项的设置中它降低了协议的安全性。 4.2. 扩展性我们相信协议将会随时间演化，一些组织将希望使用它们自己的加密、验证及/或密钥交互方法。对所有扩展进行集中注册是繁琐的，特别对于试验性或保密的特性。另一方面，没有集中注册会导致方法标识符冲突，影响互操作性。我们选择通过特定格式的名称来标识算法、方法、格式和扩展协议。DNS 名称被用于创建本地命名空间，在其中可定义试验性或保密的扩展而不用担心与其他系统实现相冲突。一个设计目标是保持基础协议尽可能简单，并且要求尽可能少的算法。但是，所有系统实现必须支持一个最小的算法集合以保证互操作性（这不表示所有主机上的本地策略要允许这些算法）。强制性的算法在相关协议文档中规定。附加的算法、方法、格式和扩展协议可在单独的文档中定义。参见第 6 节，算法命名。 4.3. 策略问题协议允许对加密、完整性、密钥交换、压缩以及公钥算法和格式进行完整的协商。两个传输方向的加密、完整性、公钥和压缩算法可以不同。下列策略问题应在系统实现的配置机制中被解决： ○ 每个传输方向的加密、完整性和压缩算法。策略必须规定哪一个是优选算法（例如，在每个类别下列出的第一个算法）。 ○ 主机验证使用的公钥算法和密钥交换方法。已存在的使用不同算法的受信任的主机密钥也影响这一选择。 ○ 服务器对每个用户要求的验证方法。服务器的策略可对一些或所有用户要求多重认证。要求的算法可依赖于用户试图获得授权时所在的位置。 ○ 用户被允许使用连接协议进行的操作。一些问题与安全性有关；例如，策略不应允许服务器在客户机上启动进程或运行命令，并且必须不允许连接到验证代理，除非被要求转发这样的连接。另一些问题，例如谁能够转发那个 TCP/IP 端口，非常明显是本地策略。很多这样的问题可能涉及穿越或绕过防火墙，并且与本地安全策略互相联系。 4.4. 安全特性 SSH 协议的主要目的是改善 Internet 的安全性。它尝试通过一种容易部署的方式实现该目的，为此，甚至不惜牺牲绝对安全。 ○ 所使用的所有加密、完整性，以及公钥算法都是广为人知的、成熟的算法。第 8 页/共 62 页

分享到：

赞收藏

资料库

Security_Shell(SSH)协议_中文版.pdf

相关推荐

开发技术

热门标签

最新资料