我们经常用的SSH,原来是这样的
前言
在实际日常运维工作中,肯定是离不开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免密登陆啊,这些我们平常只知道用,却不知道为什么是这样子,在出现问题时,不知道为什么,只知道谷歌、百度好用;我希望通过我的这篇文章,能让各位有缘的读者明白、熟悉这些简单的原理,让大家在日后的工作中因为懂,所以更放的开。好了,如果觉的还不错,可以点击下方的“在看”哦。
书籍推荐
人生是个圆,有的人走了一辈子也没有走出命运画出的圆圈,其实,圆上的每一个点都有一条腾飞的切线。
玩代码、玩技术
长按识别二维码,关注“果冻想”