前言
在实际日常运维工作中，肯定是离不开SSH的，每天都在不停的使用SSH登陆这个主机，或者那个主机去处理各种问题。每天用的也很舒服，但是对于SSH后面的原理却不甚了解，最近在看Ansible时，发现自己对SSH还有很多的迷惑点，对于我来说，一般不常用的迷惑点，我也就糊弄糊弄就过去了，毕竟对每个知识点进行放大，那都是一本学不完的天书，有些内容我们了解就好了，但是对于SSH，本想着也糊弄糊弄就过去吧，但是后来发现这样行不通，这里面好多的知识点直接影响着我日后的运维工作。于是乎，觉的有必要整理这样的一篇文章来把SSH的原理好好的学习一下，也好让后续自己的运维工作更得心应手，又或在教小弟时也能有点资本。
SSH是什么？
简单一点来说，SSH就是一种网络协议，用于在网络主机之间进行加密的一种协议。结合我们的日常工作来说，如果我从一台服务器使用SSH协议登陆另一台服务器，我们就认为这样的登陆是安全的，即使我们的登陆信息在中间被人截获了，我们的密码也不会被泄露。
为什么要搞这么个协议呢？其实，很久很久以前，互联网通信都是明文的，一旦在中间环节被某些中间商截获了，我们的通信内容就暴漏无疑。所以呢，芬兰就有这么一位叫做Tatu Ylonen的人设计了SSH协议，将信息加密，这样就像上面说的，即使我们的登陆信息在中间被人截获了，我们的密码也不会被泄露。目前SSH协议已经在全世界广泛被使用，且已经在成为各个Linux发行版的标配。
原理解析
至于SSH的一些简单用法，我这里就不细说了，先通过一副时序图看看SSH的密码登陆原理。
从上图中，可以看到我们使用SSH进行登陆时，主要分为以下几步：
用户使用
ssh user@host命令对远程主机发起登陆；远程主机将自己的公钥返回给请求主机；
请求主机使用公钥对用户输入的密码进行加密；
请求主机将加密后的密码发送给远程主机；
远程主机使用私钥对密码进行解密；
最后，远程主机判断解密后的密码是否与用户密码一致，一致就同意登陆，否则反之。
这个过程乍一看没有任何问题，但是在实际工作中，却是存在风险漏洞的。由于SSH不像https协议那样，SSH协议的公钥是没有证书中心（CA）公证的，也就是说，都是自己签发的。这就导致如果有人截获了登陆请求，然后冒充远程主机，将伪造的公钥发给用户，那么用户很难辨别真伪，用户再通过伪造的公钥加密密码，再发送给冒充主机，此时冒充的主机就可以获取用户的登陆密码了，那么SSH的安全机制就荡然无存了，这也就是我们常说的中间人攻击。
既然存在这种问题，SSH就想了一个办法来绕开这个问题，也就是我接下来要总结的known_hosts文件的作用。
known_hosts文件的作用
我们在使用SSH登陆远程主机的时候，有时会看到这样的提示：
The authenticity of host '192.168.1.4 (192.168.1.4)' can't be established.
ECDSA key fingerprint is SHA256:YMLLk0vyfeoY4rbRTnkMSxY11arS2S4qgVgvnwWpBFw.
ECDSA key fingerprint is MD5:82:75:be:8e:e7:26:ea:18:73:aa:fc:10:44:c8:4f:c3.
Are you sure you want to continue connecting (yes/no)?
上面这段话的意思是，无法确认192.168.1.4主机的真实性，只知道它的公钥指纹，问你还想继续连接吗？这样我们就可以看到，SSH是将这个问题抛给了SSH使用者，让SSH使用者自己来确定是否相信远程主机。但是这样对于用户来说，就存在一个难题，用户怎么知道远程主机的公钥指纹是多少；这的确是一个问题，此时就需要远程主机必须公开自己的公钥指纹，以便用户自行核对。
在经过用户的风险衡量以后，用户只需要输入yes来决定接受这个远程主机的公钥。紧接着，系统会出现以下这样的一句提示，表示远程主机已经得到认可：
Warning: Permanently added '192.168.1.4' (ECDSA) to the list of known hosts.
接下来，用户输入远程主机密码即可完成整个登陆。那这个和我这里要总结的known_hosts文件有什么关系呢？请听我慢慢道来。
当远程主机的公钥被接受以后，它就会被保存在文件~/.ssh/known_hosts之中。下次再连接这台主机，系统就会认出它的公钥已经保存在本地了，从而跳过警告部分，直接提示输入密码。
但是由于known_hosts这个机制的存在，也会引起一些问题，比如远程主机的重新装操作系统了，远程主机就会重新生成公钥，如果我们再登陆远程主机时，由于我们本地的known_hosts文件中记录了原来的公钥，此时就会提示指纹认证失败的错误，这个时候我们只需要删除本地的known_hosts文件即可。又比如，我们经常会写一些自动化的脚本，会自动的登陆到远程主机上去，但是这个known_hosts机制却必须要我们手动输入yes才能完成远程登陆，这样整个自动化登陆就无法完成了，但是我们可以通过修改/etc/ssh/ssh_config配置文件，跳过这个known_hosts的询问机制，将# StrictHostKeyChecking ask修改为StrictHostKeyChecking no即可。
公钥免密登录
在我们日常工作中，总是会挂很多的自动化脚本，比如自动的登陆到一台远程主机上进行一些操作，又比如Ansible就可以配置自动登陆到远程主机，但是上面说到的SSH，都需要密码登陆，那如何让SSH免密登陆，实现我们的自动登陆需求呢？这就是这里要将的公钥免密登陆。
上图就是SSh免密登陆原理图，从上图可以看出，SSH免密登陆的前提是使用ssh-keygen -t RSA生成公私秘钥对，然后通过ssh-copy-id -i ~/.ssh/id_rsa.pub user@host命令将公钥分发至远程主机。接下来的每次免密登陆步骤如下：
用户使用
ssh user@host命令对远程主机发起登陆；远程主机对用户返回一个随机串；
用户所在主机使用私钥对这个随机串进行加密，并将加密的随机串返回至远程主机；
远程主机使用分发过来的公钥对加密随机串进行解密；
如果解密成功，就证明用户的登陆信息是正确的，则允许登陆；否则反之。
通过ssh-copy-id -i ~/.ssh/id_rsa.pub user@host命令分发的公钥都会被保存至远程主机的~/.ssh/authorized_keys文件中。
总结
虽然我们经常使用SSH，但是对于其中的一些原理性的东西却不是很懂，很多时候就是因为这些简单的原理性的不懂，就让我们的思维受限，让我们的行动受限，因为不懂，所以就怕操作，怕出错。这篇文章就对SSH中的一些原理进行了总结，对于我们经常接触的东西，比如known_hosts啊、SSH免密登陆啊，这些我们平常只知道用，却不知道为什么是这样子，在出现问题时，不知道为什么，只知道谷歌、百度好用；我希望通过我的这篇文章，能让各位有缘的读者明白、熟悉这些简单的原理，让大家在日后的工作中因为懂，所以更放的开。好了，如果觉的还不错，可以点击下方的“在看”哦。
书籍推荐
人生是个圆，有的人走了一辈子也没有走出命运画出的圆圈，其实，圆上的每一个点都有一条腾飞的切线。
玩代码、玩技术
长按识别二维码，关注“果冻想”