SSH中的安全 | 从SSH协议看身份验证底层原理

> 原文链接：[SSH中的安全 | 从SSH协议看身份验证底层原理](https://codemutex.com/blog/20220909-SSH%E4%B8%AD%E7%9A%84%E5%AE%89%E5%85%A8-%E4%BB%8ESSH%E5%8D%8F%E8%AE%AE%E7%9C%8B%E8%BA%AB%E4%BB%BD%E9%AA%8C%E8%AF%81%E5%BA%95%E5%B1%82%E5%8E%9F%E7%90%86) > > 推广：[NextSSH 简洁直观的 SSH 客户端 ](https://codemutex.com/)[https://codemutex.com/](https://codemutex.com/) ## 前言 前置关键词：SSH 客户端/服务器，Linux/Unix 系统的用户账户，TCP/IP，Socket。 本文撰于 2022 年 9 月，若相关内容有更新请按照引用链接内的内容为准。 本文介绍了 SSH 协议在验证用户身份过程中的实现细节，想帮助读者更加深入的了解 SSH 客户端与服务器的工作过程。也因此，本文可能不适用于指导 SSH 服务器或客户端的配置。 本文在撰写中参考了下列内容。 * SSH 架构 [RFC 4251](http://www.rfc-editor.org/info/rfc4251) The Secure Shell (SSH) Protocol Architecture * SSH 传输层协议 [RFC 4253](http://www.rfc-editor.org/info/rfc4253) The Secure Shell (SSH) Transport Layer Protocol * SSH 身份验证协议 [RFC 4252](http://www.rfc-editor.org/info/rfc4252) The Secure Shell (SSH) Authentication Protocol * SSH 连接协议 [RFC 4254](http://www.rfc-editor.org/info/rfc4254) The Secure Shell (SSH) Connection Protocol * SSH 交互式身份验证 [RFC 4256](http://www.rfc-editor.org/info/rfc4256) Generic Message Exchange Authentication for the Secure Shell Protocol (SSH) ### SSH 协议的结构  建立一个 SSH 连接，将会经过下面几个过程。 * （明文通信）**建立 TCP 连接** * （明文通信）**协商 SSH 协议版本**（本质上是相互发送包含版本号的字符串） * 服务器将自己的 SSH 协议版本发送到客户端，格式为：`SSH-protoversion(版本号)-softwareversion(自定义) SP(空格一个,可选) comments(注释,可选) CR(回车) LF(换行)` * 客户端将自己的 SSH 协议版本发送到服务器，格式为：`SSH-protoversion(版本号)-softwareversion(自定义) SP(空格一个,可选) comments(注释,可选) CR(回车符) LF(换行符)` * （明文通信）**协商密钥** * 服务器发送公钥 * 客户端和服务器相互发送支持的相关加密算法列表、MAC 算法列表 * 使用 [D-H 算法](https://zh.wikipedia.org/zh-cn/%E8%BF%AA%E8%8F%B2-%E8%B5%AB%E7%88%BE%E6%9B%BC%E5%AF%86%E9%91%B0%E4%BA%A4%E6%8F%9B) 生成此后通讯中使用的[对称加密密钥](https://zh.wikipedia.org/wiki/%E5%B0%8D%E7%A8%B1%E5%AF%86%E9%91%B0%E5%8A%A0%E5%AF%86)（会话密钥） * （密文通信）**身份认证** * （密文通信）**正式进入应用**（如打开 Shell、SFTP、端口转发） 从上面的流程中可以看出，身份验证过程实际上发生在 SSH 连接建立之后，此后客户端与服务器之间传输的密码、密钥、信息都已经受到 SSH 协议生成的「会话密钥」加密。 ## 关于「安全」 SSH 的全称是「Secure Shell」，安全 Shell。其中的「安全」不是指使用 SSH 就能进入一个绝对的安全世界，而是包含了传输安全和身份安全。 假设，我正在打电话给身在公司的朋友，询问一些机要信息。此时攻击者就可以剪断我屋外的电话线，分别接上两个电话听筒对听筒放在一起。我和我的朋友都不会注意到问题，而攻击者可以从中得知我们之间传输的信息。这是网络中存在的[中间人攻击](https://zh.wikipedia.org/wiki/%E4%B8%AD%E9%97%B4%E4%BA%BA%E6%94%BB%E5%87%BB)。 SSH 避免了这个问题，客户端与服务器之间的数据传输经过了上面的过程而加密（SSH 传输层协议 [RFC 4253](http://www.rfc-editor.org/info/rfc4253)）。这个加密是无关于用户的账号密码的，在事前就完成。无论是网络中的交换机还是跳板机都无法直接获取加密前的明文。SSH 保护了传输时的安全。 SSH 也同样提供了验证用户身份的方式，客户端可以将用户的密码发送至服务器，以此让服务器确认用户的身份，只允许被授权的访问连接到服务器。 SSH 的安全不是绝对的。比如攻击者拿起剪断的电话线（中间人攻击），他依旧可以通过客户端与服务器之间的通讯内容推测出这是 SSH 连接。SSH 协议并不能保证连接不被侦测到特征。 ## 身份验证方式 ### 密码（Password） 使用密码登录是常用且较为便捷的认证方式。在配置文件 `/etc/ssh/sshd_config` 中添加 `PasswordAuthentication yes` 以开启密码登录。  通常也认为使用密码登录是一种较为脆弱的认证方式。这不是说使用密码会造成传输时的不安全，而是对密码本身保存的担忧。一般的用户密码都是十位或数十位字符，可能被记录与纸上或记事本中。即使不是如此，有意义的密码也容易遭到社会工程攻击而泄露。 在 `/etc/ssh/sshd_config` 文件中有时会设置 `PermitRootLogin prohibit-password` ，要求系统管理用户 `root` 不得使用密码登录。 根据 RFC 中的描述，用户认证过程是在连接握手之后的。此时客户端与服务器之间已经建立起了加密的连接。双方都会使用握手时交换好的密钥加密所有传输内容。后文中的 SSH 数据样式都是被加密传输的。 登录时，登录请求由客户端发起。一个名称为 `SSH_MSG_USERAUTH_REQUEST` 的消息从客户端发出，包含了登录的用户名与密码。 ```plaintext C: byte SSH_MSG_USERAUTH_REQUEST C: string user name C: string service name C: string "password" C: boolean FALSE C: string plaintext password in ISO-10646 UTF-8 encoding [RFC3629] S: byte SSH_MSG_USERAUTH_SUCCESS ``` 若登录认证失败，服务器将回复 `SSH_MSG_USERAUTH_FAILURE`。 基本上，这样的消息往复就完成了平时常见的登录过程。 除此之外，在 RFC 标准中还有一个用于服务器响应密码登录请求的消息。 > 通常，服务器会成功或失败地响应此消息。但是，如果密码已过期，服务器应通过 `SSH_MSG_USERAUTH_PASSWD_CHANGEREQ` 响应来指示这一点。在任何情况下，服务器都不得允许使用过期密码进行身份验证。 后文介绍的 `keyboard-interactive` 登录方式也可以做出密码过期提示。 ### 公钥私钥（Publickey） 在 RFC 标准中，公钥验证方式是唯一必须实现的验证方式（The only REQUIRED authentication）。所有实现都必须（MUST, RFC2119）支持这种方法。在 `/etc/ssh/sshd_config` 文件中使用 `PubkeyAuthentication yes` 开启公钥验证方式。 此验证方式需要用户先准备一个[非对称加密](https://zh.wikipedia.org/wiki/%E5%85%AC%E5%BC%80%E5%AF%86%E9%92%A5%E5%8A%A0%E5%AF%86)的密钥对，将公钥保存至 SSH 服务器的 `~/.ssh/authorized_key` 文件中。客户端登录时，在本地用私钥加密某个信息，并将结果发送给服务器，服务器将通过公钥验证收到的密文是否来自指定的用户。 私钥通常以加密的形式存储在客户主机上，用户必须在生成签名之前提供一个口令（`passphrase`）。 即使不是这样，签名操作也涉及一些昂贵的计算。 为了避免不必要的处理和用户互动，提供以下信息来查询使用 "公钥 "方法的认证是否可以接受。 ```plaintext C: byte SSH_MSG_USERAUTH_REQUEST C: string user name in ISO-10646 UTF-8 encoding [RFC3629] C: string service name in US-ASCII C: string "publickey" C: boolean FALSE C: string public key algorithm name C: string public key blob ``` 任何公钥算法都可以被提供给认证使用，如果请求中的算法不被服务器支持，它必须直接拒绝该请求。 服务器必须以 `SSH_MSG_USERAUTH_FAILURE` 或以下方式回应该消息。 ```plaintext S: byte SSH_MSG_USERAUTH_PK_OK S: string public key algorithm name from the request S: string public key blob from the request ``` 之后，客户端会使用私钥加密一个消息（消息的构成方式参见 RFC 4252），将结果发送给服务器。下面消息中的 `signature` 即为加密运算后的内容。 ```plaintext C: byte SSH_MSG_USERAUTH_REQUEST C: string user name C: string service name C: string "publickey" C: boolean TRUE C: string public key algorithm name C: string public key to be used for authentication C: string signature ``` 使用公钥方式登录的优点是，密钥对基本不可能被写在纸上（密钥是很长的随机文本，社会工程攻击中只能通过更困难的间接方式窃取这么长的内容）；在网络上传输、保存的通常是密钥对的公钥文件，而非私钥文件。 更加显而易见的好处是，私钥文件是保存在客户端的计算机上的。使用 SSH 命令时就无需再反复输入密码。因此网络上很多教程使用此方式作为免密码登录的方式。与此同时，因为需要预先将公钥放在服务器上（通常是通过网络上传），其也确实不便于配置。 ### 交互式（keyboard-interactive） 在 RFC 文档中，这个验证方式被视作是前述方案的一种扩展。允许 SSH 客户端和服务器在获取身份验证信息时进行一些交互。如要启用此方式需在 `/etc/ssh/sshd_config` 文件中添加 `ChallengeResponseAuthentication yes` 。通常情况下，这个验证模式会与系统内的 [PAM](https://zh.wikipedia.org/zh-cn/%E5%8F%AF%E6%8F%92%E6%8B%94%E8%AE%A4%E8%AF%81%E6%A8%A1%E5%9D%97) 模块一同启用。以此来支持谷歌验证器（[多因素验证](https://zh.wikipedia.org/wiki/%E5%A4%9A%E9%87%8D%E8%A6%81%E7%B4%A0%E9%A9%97%E8%AD%89)），或其他内部身份校验模块。  使用交互式验证可以允许用户输入更多的信息，获得更多的提示内容。 从 RFC 中来看，此验证模式也是从客户端发起身份验证请求开始。 ```plaintext C: byte SSH_MSG_USERAUTH_REQUEST C: string user name (ISO-10646 UTF-8, as defined in [RFC-3629]) C: string service name (US-ASCII) C: string "keyboard-interactive" (US-ASCII) C: string language tag (as defined in [RFC-3066]) C: string submethods (ISO-10646 UTF-8) ``` 当服务器得知客户端准备使用 `keyboard-interactive` 为验证方式后，服务器会向客户端发出用户信息请求。在这个来自服务器的请求中，服务器将提供提示文本（`instruction`, `prompt`）并且为每一个字段（或者称为询问）标记一个序号（`num-prompts`）。 ```plaintext S: byte SSH_MSG_USERAUTH_INFO_REQUEST S: string name (ISO-10646 UTF-8) S: string instruction (ISO-10646 UTF-8) S: string language tag (as defined in [RFC-3066]) S: int num-prompts S: string prompt[1] (ISO-10646 UTF-8) S: boolean echo[1] S: ... S: string prompt[num-prompts] (ISO-10646 UTF-8) S: boolean echo[num-prompts] ``` 收到来自 SSH 服务器的请求后，客户端即可开始向用户展示界面获取信息。在使用 `ssh` 命令时，通常会在终端内等待用户输入，具有 GUI 的软件将会展示提示界面。  当用户完成输入后，客户端即可发送用户信息响应。 ```plaintext C: byte SSH_MSG_USERAUTH_INFO_RESPONSE C: int num-responses C: string response[1] (ISO-10646 UTF-8) C: ... C: string response[num-responses] (ISO-10646 UTF-8) ``` 这样的过程（服务器请求-用户输入-客户端响应）可能会重复多次。例如用户输入的密码错误，或者服务器依据情况请求了更多的信息。 下面是来自 RFC 文档中的，客户端和服务器之间的两个交换例子。 第一个例子是用需处理的 Token 进行验证的例子。这是一种其他认证方法无法实现的方式。 ```plaintext C: byte SSH_MSG_USERAUTH_REQUEST C: string "user23" C: string "ssh-userauth" C: string "keyboard-interactive" C: string "" C: string "" S: byte SSH_MSG_USERAUTH_INFO_REQUEST S: string "CRYPTOCard Authentication" S: string "The challenge is ’14315716’" S: string "en-US" S: int 1 S: string "Response: " S: boolean TRUE [Client prompts user for password] C: byte SSH_MSG_USERAUTH_INFO_RESPONSE C: int 1 C: string "6d757575" S: byte SSH_MSG_USERAUTH_SUCCESS ``` 第二个例子是一个标准的密码认证。但在此例子中，用户的密码已经过期。 ```plaintext C: byte SSH_MSG_USERAUTH_REQUEST C: string "user23" C: string "ssh-userauth" C: string "keyboard-interactive" C: string "en-US" C: string "" S: byte SSH_MSG_USERAUTH_INFO_REQUEST S: string "Password Authentication" S: string "" S: string "en-US" S: int 1 S: string "Password: " S: boolean FALSE [Client prompts user for password] C: byte SSH_MSG_USERAUTH_INFO_RESPONSE C: int 1 C: string "password" S: byte SSH_MSG_USERAUTH_INFO_REQUEST S: string "Password Expired" S: string "Your password has expired." S: string "en-US" S: int 2 S: string "Enter new password: " S: boolean FALSE S: string "Enter it again: " S: boolean FALSE [Client prompts user for new password] C: byte SSH_MSG_USERAUTH_INFO_RESPONSE C: int 2 C: string "newpass" C: string "newpass" S: byte SSH_MSG_USERAUTH_INFO_REQUEST S: string "Password changed" S: string "Password successfully changed for user23." S: string "en-US" S: int 0 [Client displays message to user] C: byte SSH_MSG_USERAUTH_INFO_RESPONSE C: int 0 S: byte SSH_MSG_USERAUTH_SUCCESS ``` --- 本文转载不得删改，应全文转载并保留原文出处链接。