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

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

推广：NextSSH 简洁直观的 SSH 客户端 https://codemutex.com/

前言

前置关键词：SSH 客户端/服务器，Linux/Unix 系统的用户账户，TCP/IP，Socket。

本文撰于 2022 年 9 月，若相关内容有更新请按照引用链接内的内容为准。

本文介绍了 SSH 协议在验证用户身份过程中的实现细节，想帮助读者更加深入的了解 SSH 客户端与服务器的工作过程。也因此，本文可能不适用于指导 SSH 服务器或客户端的配置。

本文在撰写中参考了下列内容。

• SSH 架构 RFC 4251 The Secure Shell (SSH) Protocol Architecture
• SSH 传输层协议 RFC 4253 The Secure Shell (SSH) Transport Layer Protocol
• SSH 身份验证协议 RFC 4252 The Secure Shell (SSH) Authentication Protocol
• SSH 连接协议 RFC 4254 The Secure Shell (SSH) Connection Protocol
• SSH 交互式身份验证 RFC 4256 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 算法 生成此后通讯中使用的对称加密密钥（会话密钥）
• （密文通信）身份认证
• （密文通信）正式进入应用（如打开 Shell、SFTP、端口转发）

从上面的流程中可以看出，身份验证过程实际上发生在 SSH 连接建立之后，此后客户端与服务器之间传输的密码、密钥、信息都已经受到 SSH 协议生成的「会话密钥」加密。

关于「安全」

SSH 的全称是「Secure Shell」，安全 Shell。其中的「安全」不是指使用 SSH 就能进入一个绝对的安全世界，而是包含了传输安全和身份安全。

假设，我正在打电话给身在公司的朋友，询问一些机要信息。此时攻击者就可以剪断我屋外的电话线，分别接上两个电话听筒对听筒放在一起。我和我的朋友都不会注意到问题，而攻击者可以从中得知我们之间传输的信息。这是网络中存在的中间人攻击。

SSH 避免了这个问题，客户端与服务器之间的数据传输经过了上面的过程而加密（SSH 传输层协议 RFC 4253）。这个加密是无关于用户的账号密码的，在事前就完成。无论是网络中的交换机还是跳板机都无法直接获取加密前的明文。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 的消息从客户端发出，包含了登录的用户名与密码。

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 开启公钥验证方式。

此验证方式需要用户先准备一个非对称加密的密钥对，将公钥保存至 SSH 服务器的 ~/.ssh/authorized_key 文件中。客户端登录时，在本地用私钥加密某个信息，并将结果发送给服务器，服务器将通过公钥验证收到的密文是否来自指定的用户。

私钥通常以加密的形式存储在客户主机上，用户必须在生成签名之前提供一个口令（passphrase）。 即使不是这样，签名操作也涉及一些昂贵的计算。 为了避免不必要的处理和用户互动，提供以下信息来查询使用 "公钥 "方法的认证是否可以接受。

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 或以下方式回应该消息。

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 即为加密运算后的内容。

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 模块一同启用。以此来支持谷歌验证器（多因素验证），或其他内部身份校验模块。

使用交互式验证可以允许用户输入更多的信息，获得更多的提示内容。

从 RFC 中来看，此验证模式也是从客户端发起身份验证请求开始。

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）。

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 的软件将会展示提示界面。

当用户完成输入后，客户端即可发送用户信息响应。

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 进行验证的例子。这是一种其他认证方法无法实现的方式。

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

第二个例子是一个标准的密码认证。但在此例子中，用户的密码已经过期。

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

本文转载不得删改，应全文转载并保留原文出处链接。