SSH-关于Hadoop需要配置的免密登录
最后更新时间:
关于免密登录
Hadoop登录，其使用了SSH的方式来实现，所以Hadoop的免密登录=配置SSH的免密登录。
刚好SSH的免密登录对我来说也是空白，凑巧学习一下。
SSH登录
SSH登录采用了不对称加密的方式来实现。不对称加密的一对密钥分为公钥和私钥，公钥只能进行加密，私钥仅能进行解密。
那么如果我要验证一个人给我的密码是否正确，我就要先提供给他公钥，然后让他用我的公钥把密码进行加密；之后我使用我的私钥进行解密验证即可。
这就是SSH密码登录的方式。实际使用时，请求密码登录的同时将会询问你是否要信任对方的公钥，若选择是，此时就获得了公钥。否->不登录
如何进行免密登录
SSH免密登录时，因为没有密码，SSH的设计：
- 首先服务器产生一个密码，准备将这个密码发送给客户端
- 客户端将这个密码拿去进行登录
而为了保证这个随机生成的密码不泄露，就需要再次使用非对称加密。方案是： - 首先让客户端将自己的公钥发送给客户端
- 服务端使用客户端的公钥加密密码，并把加密的密码发送给客户端
- 客户端收到后，使用自己的私钥解密，并进行密码登录的流程
这便是所谓的：谁想要登录到别人上面去，谁负责产生密钥对。
Linux上的免密登录配置
SSH 提供了一个叫做ssh-keygen的工具用于生成公钥和私钥。其产生的文件为：
● id_rsa：私钥(解密用)
● id_rsa.pub：公钥(加密用)
客户端要将自己的公钥提交给服务端，使用：
1 | |
关于SSH的中间人攻击
在HTTPS中，有一种类似的东西叫做证书。而证书的验证是依靠“CA”来进行的。但SSH不像https协议，SSH协议的公钥是没有证书中心（CA）公证的，也就是说，都是自己签发的。
中间人攻击的思路是：我夹在两个服务器中间，对于客户端我充当服务端，对于服务端我充当客户端。
以密码登录为例：在客户端试图连接服务端时，会有一次“是否信任公钥”的询问。如果接受了中间人的公钥，那么客户端使用中间人的公钥加密的内容，中间人可以用自己的私钥进行解密，此时密码暴露。中间人作为一个客户端，连接服务端接受其公钥，并使用密码登录，此时客户端的所有操作都会暴露在中间人中。
可以设想，如果攻击者插在用户与远程主机之间（比如在公共的wifi区域），用伪造的公钥，获取用户的登录密码。再用这个密码登录远程主机，那么SSH的安全机制就荡然无存了。这种风险就是著名的"中间人攻击"（Man-in-the-middle attack）
而如果使用公钥登录（免密登录），中间人能获取到你的公钥。中间人将他的公钥传给服务器，服务器将会使用他的公钥进行加密。此时中间人用自己的私钥进行解密，并将密码以客户端的公钥进行加密。客户端解密后发起登录请求，此时你的信息仍然不安全。
所以在通常情况下，服务器保存的授权公钥应该是提前配置好的，而且服务器管理员会采取措施来确保公钥的安全性，比如通过安全的通信渠道配置公钥，使用安全的文件权限保护公钥等。（ChatGPT）
而如果已经提前配置好了，中间人攻击便无法发挥作用。除非它能修改对应服务器上你的公钥信息。
关于对称加密
课程中提及到：还有一种对称加密，其使用同一个秘钥进行加密和解密。
对称加密的加密强度高，很难破解。但在实际应用过程中不得不面临一个棘手的问题：如何安全的保存密钥。
在ssh中既使用了对称加密又使用了非对称加密，非对称加密是在认证用户连接的时候使用，对称加密是在用户连接之后开始传输数据的时候加密数据。因为使用非对称加密已经保证了通信安全，因而可以安全的传递密钥，之后就可以利用对称加密进行数据的加密传输。
关于GitHub的SSH连接
之前一直没有关心过Github的SSH连接，感觉配置起来很麻烦，好像还有密钥，还要记各种数据。现在才发现，Github要的就是“公钥”。将公钥上传给Github后，等同于配置了免密登录，十分方便。