1、对称加密与非对称加密
对称加密: 加密和解密的秘钥使用的是同一个.
非对称加密: 非对称加密算法须要两个密钥:公开密钥(publickey)和私有密钥;简称公钥和私钥
对称加密算法
对称加密的密码强度高、较难破解。可是秘钥的保存成为了一个重要的问题,特别是若是机群庞大的时候,一旦某个客户端暴露了秘钥,会给整个系统带来严重的安全问题
非对称加密数据库
公钥加密后的密文,只能经过对应的私钥进行解密。而经过公钥推理出私钥的可能性微乎其微。私钥是Server端独有,并且私钥并不会在网络中进行传输,这必定程度上保证了数据的安全性,充分利用了非对称加密的特性
非对称加密的过程:
① 客户端向服务器发送请求,并获得服务器传来的公钥
②-④ 客户端利用从服务器获得公钥对登陆数据(用户名和密码或其余验证数据)进行加密;而后将加密后的数据传给服务器
⑤-⑦ 服务器利用私钥将从客户端收到的数据进行解密。并将解密后的数据与正确数据(数据库中存储的用户名和密码或其余)进行校验,根据获得校验结果容许或拒绝这次登陆请求;并将最后结果通知客户端
2、非对称加密的安全性问题
从上面的分析中,咱们得知了非对称加密确实解决了必定的安全问题,那么它就必定安全了吗?答案是绝对否认的。由于经过上面的分析,咱们得知客户端对于服务器方是没有认证的。而这时若是一个假冒的服务器方将本身的公钥发给了客户端,它能够很简单的把客户端的加密数据进行解密,由于公钥和私钥都是它本身的啊。这样客户端的数据就被窃取了。这种攻击方式叫作中间人攻击。其原理以下:vim
3、SSH原理
由于非对称加密体质很是耗费系统资源,所以SSH仅将非对称加密用于登陆链接过程,而链接后的数据交互采用了对称加密。咱们经过上面得知,即便是非对称加密也存在一个问题——如何解决中间人攻击?
https中针对中间人攻击采起了公证机制——经过CA来进行公证,但是SSH的公钥和私钥都是本身生成的,无法公证。只能经过Client端本身对公钥进行确认。
所以,SSH引入了known_hosts文件。客户端的每次链接请求,服务器都会将相关信息与known_hosts文件中的信息进行匹配,若是是第一次链接,服务器会将相关信息存储在known_hosts文件中,在这个过程当中,服务器会请求客户端的用户进行确认;拿什么确认呢?公钥指纹!什么是公钥指纹?
由于公钥很长,长达1024位甚至2048位或更长,若是比较这么长的数据会很耗费系统资源。因此这里的公钥指纹是指利用MD5算法对公钥进行加密后造成的128位的一个数据;客户端利用这个从服务器获取到的公钥加密后的公钥指纹和真正服务器的公钥(需提早获取)加密后的公钥指纹进行比较,若是一致的话,用户须要输入yes确认这次认证,若是不一致的话,有可能遭到了中间人攻击,用户须要输入no对这次认证进行中断,防止数据泄露。如图:安全
若是不是第一次链接,客户端(登陆方)会将本身的known_hosts文件中的公钥指纹与服务器传来的公钥指纹进行对比,若是一致,链接会继续,客户端输入用户名和密码直接登陆就能够。若是不一致,客户端会断定这次链接遭到了中间人攻击,并阻止这次链接,如图:服务器
若是是用户主动从新部署了SSH服务器,而且确认这次链接无误的话,用户须要在客户端(登陆方)的known_hosts文件中删除与该地址对应的公钥数据,从新进行SSH链接认证便可
4、SSH免密登陆原理
基于口令的认证方式每次登陆都须要输入密码,这是比较麻烦的一件事情,为此,SSH引入了基于公钥认证的登陆方式,这也是SSH免密登陆的依据,那么基于公钥认证的登陆方式具体步骤是怎样的呢?网络
1.登陆端A生成公钥和私钥,并(手动)将公钥追加到被登陆端B的 authorized_key 文件中
2.登陆端A向被登陆端B发送链接请求,并将公钥发送给被登陆端B
3.被登陆端B接受登陆端A发来的公钥,并将该公钥与本身的 authorized_key 文件中的全部存储的公钥进行比较,若是并未发现有此公钥存在,则登陆端A须要进行口令认证与被登陆端B进行链接。若是在 authorized_key 文件中找到了与登陆端A发送的公钥相同的公钥,则生成随机数R,并利用公钥加密该随机数获得 publickey(R),最后被登陆端B将 publickey(R) 传给登陆端A
4.登陆端A利用私钥对 publickey(R) 进行解密获得R,登陆端A和被登陆端B通讯时会产生一个会话ID(sessionKey)。登陆端A利用MD5算法将R和ID进行加密,并将加密后的数据传给被登陆端B
5.被登陆端B也利用MD5算法对R(被登陆端B在第3步中随机生成的)和会话ID(两者的会话属于同一会话,所以会话ID sessionKey是相同的)进行加密。并将加密后的数据与第四步登陆端传来的加密数据进行比较,若是相同,则容许这次登陆端A的链接请求,并与之创建链接。若是不一样,则两者继续进行基于口令认证的链接请求
注意:
免密登陆的任何一个环节出现不匹配时,登陆端A和被登陆端B的链接将会被转换为基于口令的认证链接
5、用生活实例来演示免密登陆
老板Boss在服务器B上建立了一个userb用户,但是他回到家后想用客户机A使用userb用户链接服务器B
首先,老板在本身办公室的客户机A上建立了秘钥,包括公钥和私钥。老板把公钥传到公司的服务器S上;但是这个老板不可能把公司的全部事情都包了,那样太累了,因而他在公司的服务器S上作了一个容许访问该服务器的 "电脑编号-各级部门经理帐号" 认证列表,该认证列表中包含了公司的全部部门经理的办公电脑的MAC地址和其对应的不一样级别的用户帐号。只有被该列表包含的 "电脑编号-各级部门经理帐号" 才有资格免密登陆此服务器进行办公
有一天老板想要统计公司今年的盈亏情况,因此要查看公司的帐单,老板在客户机A上使用SBoss登陆服务器S;当服务器S收到老板的链接请求后,服务器B上的 "电脑编号-各级部门经理帐号" 会判断本身里边是否有与客户机A经过SBoss登陆服务器的认证,若是没有的话,老板还得输入SBoss在服务器B上的密码进行登陆;若是有的话,服务器B会发送一个用客户机A上的公钥加密的随机数给客户机A,客户机A用私钥解密这个随机数,并用MD5算法对该随机数和当前会话ID组合的数据进行加密,而后将加密后的数据发送给服务器S,服务器S也利用MD5算法对该随机数和当前会话ID进行加密,并与客户机A传来的加密数据进行对比。根据对比结果决定是否容许这次免密登陆请求
上文中的抽象事物与ssh相关文件对应关系以下:
老板 ===> 操做计算机用户的相关管理人员
服务器S ===> SSH服务端
客户端A ===> SSH客户端
SBoss ===> SSH服务端管理员帐号
公钥 ===> SSH客户端的 id_rsa.pub 文件
私钥 ===> SSH客户端号的 id_rsa 文件
"电脑编号-各级部门经理帐号" ===> SSH服务端的 authorized_keys 文件
6、SSH免密登陆实战
单向免密登陆方法一
1.客户端A执行如下命令,生成秘钥
ssh-keygen -t rsa
注意:一路回车便可
2.客户端A执行如下命令,将公钥传给服务端B
ssh-copy-id [服务器B的IP地址]
3.客户端A执行如下命令(注意:先不要执行它,若B出现登陆不了A的情况再执行)
ssh-add id_rsa
4.服务器A执行如下命令验证
ssh [服务端B IP地址]
或
ssh [服务端B上的用户名]@[服务端B IP地址]
5.若是出错的话,多是如下几种缘由
1.两台机器均设置相应的免密登陆
2.
chmod 700 /home/[用户名]/.ssh/
chmod 600 /home/[用户名]/.ssh/authorized_keys
3.修改/etc/ssh/ssh_config配置文件以下关键字
GSSAPIAuthentication no
单向免密登陆方法二
1.客户端A生成公钥和秘钥
ssh-keygen -t rsa
注意:
一路回车便可
2.客户端A将公钥传给服务端B
scp id_rsa.pub root@192.168.5.17:~/.ssh/
3.服务端B将A的公钥追加到本身的 authorized_keys 文件中(若是没有该文件,则先新建再追加)
touch authorized_keys
cat id_rsa.pub >> authorized_keys
4.客户端A执行如下命令(注意:先不要执行它,若B出现登陆不了A的情况再执行)
ssh-add id_rsa
5.客户端A登陆服务端B
ssh root@192.168.5.17
双向免密登陆
1..编辑主机A和主机B的sshd配置文件 vim /etc/ssh/ssh_config
RSAAuthentication yes
PubkeyAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys
2.重启 sshd 服务
service sshd restart
3.主机A新建用户usea,主机B新建用户userb
主机A的操做:
useradd usera
passwd usera
主机B的操做:
useradd userb
passwd userb
4.主机A使用usera用户登陆,建立ssh秘钥
su usera
ssh-keygen -t rsa (一直回车)
5.主机B使用userb用户登陆,建立ssh秘钥
su userb
ssh-keygen -t rsa (一直回车)
6.主机A使用usera在 ~/.ssh/ 目录下新建authorized_keys文件,而且将usera和userb的公钥(id_rsa.pub)复制到该文件中
cd ~/.ssh/
touch authorized_keys
将主机A的usera公钥复制进主机A的usera的目录下的 authorized_keys 文件
cat id_rsa.pub > authorized_keys
将主机B的userb公钥追加到主机A的usera的目录下的 authorized_keys 文件
ssh userb@[主机B的IP地址] cat /home/userb/.ssh/id_rsa.pub >> authorized_keys
7.主机A使用usera用户执行如下命令
chmod 700 /home/usera/.ssh/
chmod 600 /home/usera/.ssh/authorized_keys
8.将主机A的用户usera的~/.ssh目录下的两个配置文件 authorized_keys、known_hosts 复制到主机B的userb用户的~/.ssh目录下
scp authorized_keys known_hosts userb@[主机B的IP地址]:~/.ssh/
9.主机B使用userb用户设置指定文件权限
chmod 700 /home/userb/.ssh/
chmod 600 /home/userb/.ssh/authorized_keys
10.到此,主机A和B就能够经过usera和userb经过ssh免密登陆了
ssh userb@[主机B的IP地址]
ssh usera@[主机A的IP地址]session