图解 SSH 原理

1. 初见 SSH

SSH是一种协议标准,用于在网络主机之间进行加密的一种协议,其目的是实现安全远程登录以及其它安全网络服务

SSH 仅仅是一协议标准,其具体的实现有很多,既有开源实现的 OpenSSH,也有商业实现方案。使用范围最广泛的当然是开源实现 OpenSSH。

为什么要搞这么个协议呢?其实,很久很久以前,互联网通信都是明文的,一旦在中间环节被某些中间商截获了,我们的通信内容就暴漏无疑。

所以芬兰就有这么一位叫做 Tatu Ylonen 的人设计了 SSH 协议,将信息加密,这样就像上面说的,即使我们的登陆信息在中间被人截获了,我们的密码也不会被泄露。

目前 SSH 协议已经在全世界广泛被使用,且已经在成为各个 Linux 发行版的标配。

2. SSH 工作原理

在讨论 SSH 的原理和使用前,我们需要分析一个问题:为什么需要 SSH?

从 1.1 节 SSH 的定义中可以看出,SSH 和 Telnet、FTP 等协议主要的区别在于安全性。这就引出下一个问题:如何实现数据的安全呢?首先想到的实现方案肯定是对数据进行加密。加密的方式主要有两种:

  1. 对称加密(也称为秘钥加密)
  2. 非对称加密(也称公钥加密)

所谓对称加密,指加密解密使用同一套秘钥。如下图所示:

图1-1:对称加密-Client端

图1-2:对称加密-Server端

对称加密的加密强度高,很难破解。但是在实际应用过程中不得不面临一个棘手的问题:如何安全的保存密钥呢?

尤其是考虑到数量庞大的 Client 端,很难保证密钥不被泄露。一旦一个 Client端的密钥被窃取,那么整个系统的安全性也就不复存在。为了解决这个问题,非对称加密应运而生。非对称加密有两个密钥:“公钥”“私钥”

两个密钥的特性:公钥加密后的密文,只能通过对应的私钥进行解密。而通过公钥推理出私钥的可能性微乎其微。

下面看下使用非对称加密方案的登录流程:

图1-3:非对称加密登录流程

  1. 远程 Server 收到 Client 端用户 TopGun 的登录请求,Server 把自己的公钥发给用户。
  2. Client 使用这个公钥,将密码进行加密。
  3. Client 将加密的密码发送给 Server端。
  4. 远程 Server 用自己的私钥,解密登录密码,然后验证其合法性。
  5. 若验证结果,给 Client 相应的响应。

私钥是 Server 端独有,这就保证了 Client 的登录信息即使在网络传输过程中被窃据,也没有私钥进行解密,保证了数据的安全性,这充分利用了非对称加密的特性。

这样就一定安全了吗?

上述流程会有一个问题:Client 端如何保证接受到的公钥就是目标 Server 端的? 如果一个攻击者中途拦截 Client 的登录请求,向其发送自己的公钥,Client 端用攻击者的公钥进行数据加密。攻击者接收到加密信息后再用自己的私钥进行解密,不就窃取了 Client 的登录信息了吗?这就是所谓的中间人攻击。

图1-4:中间人攻击

2.1 SSH 中是如何解决这个问题的?
2.1.1 基于口令的认证

从上面的描述可以看出,问题就在于如何对 Server 的公钥进行认证?在 https中可以通过 CA 来进行公证,可是 SSH 的 Publish keyPrivate key 都是自己生成的,没法公证。

只能通过 Client 端自己对公钥进行确认。通常在第一次登录的时候,系统会出现下面提示信息:

The authenticity of host 'ssh-server.example.com (12.18.429.21)' can't be established.
RSA key fingerprint is 98:2e:d7:e0:de:9f:ac:67:28:c2:42:2d:37:16:58:4d.
Are you sure you want to continue connecting (yes/no)?

上面的信息说的是:无法确认主机 ssh-server.example.com(12.18.429.21)的真实性,不过知道它的公钥指纹,是否继续连接?

之所以用 fingerprint 代替 key,主要是 key 过于长(RSA 算法生成的公钥有1024 位),很难直接比较。所以,对公钥进行 Hash 生成一个 128 位的指纹,这样就方便比较了。

如果输入 yes 后,会出现下面信息:

Warning: Permanently added 'ssh-server.example.com,12.18.429.21' (RSA) to the list of known hosts.
Password: (enter password)

该 host 已被确认,并被追加到文件 known_hosts 中,然后就需要输入密码,之后的流程就按照图 1-3 进行。

2.1.2 基于公钥认证

在上面介绍的登录流程中可以发现,每次登录都需要输入密码,很麻烦。SSH 提供了另外一种可以免去输入密码过程的登录方式:公钥登录。流程如下:

图1-5:公钥认证流程

  1. Client 将自己的公钥存放在 Server 上,追加在文件 authorized_keys 中。注意:Client 端的 Public key 是 Client 手动 Copy 到 Server端的,SSH 建立连接过程中没有公钥的交换操作。
  2. Server 端接收到 Client 的连接请求后,会在 authorized_keys 中匹配到 Client 的公钥 pubKey,并生成随机数 R,用 Client 的公钥对该随机数进行加密得到 pubKey(R),然后将加密后信息发送给 Client。
  3. Client 端通过私钥进行解密得到随机数 R,然后对随机数 R 和本次会话的 SessionKey 利用 MD5 生成摘要 Digest1,发送给 Server 端。
  4. Server 端会也会对 R 和 SessionKey 利用同样摘要算法生成 Digest2。
  5. Server 端会最后比较 Digest1 和 Digest2 是否相同,完成认证过程。

注意:在步骤1中,Client 将自己的公钥存放在 Server 上。需要用户手动将公钥 Copy 到 Server 上。这就是在配置 SSH 的时候进程进行的操作。下图是 GitHub 上 SSH keys 设置视图:

GitHub 中 SSH keys 设置

在步骤 2 中,Server 端根据什么信息在 authorized_keys 中进行查找的呢?主要是根据 Client 在认证的开始会发送一个 KeyID 给 Server,这个 KeyID 会唯一对应该 Client 的一个 PublicKey,Server 就是通过该 KeyID 在 authorized_keys 进行查找对应的 PublicKey。

3. SSH 实践

3.1 生成密钥操作

经过上面的原理分析,下面三行命令的含义应该很容易理解了:

$ ssh-keygen -t rsa -P '' -f ~/.ssh/id_rsa
$ cat ~/.ssh/id_rsa.pub >> ~/.ssh/authorized_keys
$ chmod 0600 ~/.ssh/authorized_keys

ssh-keygen 是用于生产密钥的工具。

  • -t:指定生成密钥类型(rsa、dsa、ecdsa 等)
  • -P:指定 passphrase,用于确保私钥的安全
  • -f:指定存放密钥的文件(公钥文件默认和私钥同目录下,不同的是存放公钥的文件名需要加上后缀 .pub)

首先看下面 ~/.ssh 中的四个文件:

SSH 涉及文件

  1. id_rsa:保存私钥
  2. id_rsa.pub:保存公钥
  3. authorized_keys:保存已授权的客户端公钥
  4. known_hosts:保存已认证的远程主机 ID(关于 known_hosts 详情,见文末更新内容)

四个角色的关系如下图所示:

SSH 结构简图

需要注意的是:一台主机可能既是 Client,也是 Server。所以会同时拥有authorized_keys 和 known_hosts。

3.2 登录操作

# 以用户名user,登录远程主机host
$ ssh user@host

# 本地用户和远程用户相同,则用户名可省去
$ ssh host

# SSH默认端口22,可以用参数p修改端口
$ ssh -p 2017 user@host

4. 其它一些补充

下面关于 SSH 的 known_hosts 机制的一些补充。

4.1 known_hosts 中存储的内容是什么?

known_hosts 中存储是已认证的远程主机 host key,每个 SSH Server 都有一个 secret, unique ID, called a host key

4.2 host key 何时加入 known_hosts 的?

当我们第一次通过 SSH 登录远程主机的时候,Client 端会有如下提示:

Host key not found from the list of known hosts.
Are you sure you want to continue connecting (yes/no)?

此时,如果我们选择 yes,那么该 host key 就会被加入到 Client 的known_hosts 中,格式如下:

# domain name+encryption algorithm+host key
example.hostname.com ssh-rsa AAAAB4NzaC1yc2EAAAABIwAAAQEA...

4.3 为什么需要 known_hosts?

最后探讨下为什么需要 known_hosts,这个文件主要是通过 Client 和 Server的双向认证,从而避免中间人(man-in-the-middle attack)攻击,每次Client 向 Server 发起连接的时候,不仅仅 Server 要验证 Client 的合法性,Client 同样也需要验证 Server 的身份,SSH Client 就是通过 known_hosts 中的 host key 来验证 Server 的身份的。

这种方案足够安全吗?当然不,比如第一次连接一个未知 Server 的时候,known_hosts 还没有该 Server 的 host key,这不也可能遭到中间人攻击吗?这可能只是安全性和可操作性之间的折中吧。

5. 总结

本文以图文方式对 SSH 原理进行解析(主要指远程登录,没有涉及端口转发等功能)。同时分析了非对称加密的特性,以及在实践过程中如何对加密操作进行改进。

来源:简书 原文:http://t.cn/Ai0nUQPK 题图:来自谷歌图片搜索 版权:本文版权归原作者所有 投稿:欢迎投稿,投稿邮箱: editor@hi-linux.com

本文分享自微信公众号 - 运维之美(Hi-Linux)

原文出处及转载信息见文内详细说明,如有侵权,请联系 yunjia_community@tencent.com 删除。

原始发表时间:2019-07-15

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

扫码关注云+社区

领取腾讯云代金券