登录重放攻击_SSH是如何防御重放攻击的？

问题描述

SSH之所以能够保证安全，原因在于它采用了公钥加密。

整个过程是这样的：

(1)远程主机收到用户的登录请求，把自己的公钥发给用户。

(2)用户使用这个公钥，将登录密码加密后，发送回来。

(3)远程主机用自己的私钥，解密登录密码，如果密码正确，就同意用户登录。

如果中间人在用户第二个步骤获取到这个请求，这个请求里面就包括了公钥加密密码后的字符信息。中间人发送这个请求到远程主机，远程主机就会用自己的私钥解密然后验证成功。请问这思路是正确的吗，如果是这样SSH还会是安全的吗？

正文

题主的问题严格审视，好像没有一个点说的是对的！

我在知乎收集计算机网络、网络安全的问题整整三年，终于明白为什么很多学生始终无法入门的原因，那是因为看到“假”的书。

西安看兵马俑的游客，稍不留意就会被带入一个山寨版的秦始皇兵马俑，浑然不知看的竟然是假的兵马俑。

对于想以网络安全为职业的读者，最好去阅读权威的RFC文档，尽管刚开始会困难一点，但是至少不会走到了一个错误的地方。如果觉得读RFC实在困难，那就看看我的文章。我帮大家理理思路，等有一天大家有能力自学了，可以再去翻阅权威文档，那是走向另一个职业高度必然的选择！

SSH是一个什么样的存在？

SSH类似于TLS，站在TCP 端口22上，TLS站在TCP 端口443上。

所以，这两者是平起平坐的，都可以提供安全加密服务。对SSH不熟悉的同学，可以用TLS的知识来学习SSH。

网络安全有一个经典口号，不造轮子，只使用轮子！

什么意思呢？

私自造轮子，本来想提供安全的通信，可是考虑不周全，引入了更多的安全漏洞，得不偿失。

使用酒精考验的轮子，经历了全人类不断捶打的轮子，使用起来更放心！

所以，SSH和TLS尽管名称不同，安全的三要素是相同的套路。

• 认证对方

• 分发密钥

• 加密数据

SSH与TLS认证方式有一点区别，TLS采用第三方CA认证，而SSH为了简化，没有采用第三方的CA，而是采用双方互相认证。

SSH公钥认证

当客户端与服务器完成TCP三次握手，紧接着就是SSH双方开始了握手协商的过程。

服务器会将自己的公钥以明文的方式推送给客户端，为了避免被第三方篡改，公钥的尾部报文还附带服务器私钥的签名保护。

客户端获得服务器的公钥，用公钥解密签名，可以解开，说明公钥完好。解不开说明公钥被篡改。

这里有一个问题，客户端永远都不知道公钥是不是服务器的，对吗？

服务器出示一张名片，上面赫然写着“马云”，客户端就相信这个是马云了？

客户端尽管傻，但是设计SSH人并不傻，设计人员是这么想的。

假如客户端与服务器第一次通信，是在一个安全的局域网里，双方如同在一个小会议室见面，然后双方交换名片，以后双方即使在互联网上通信，依然只认在小会议室交换的名片，是不是就可以避免被第三方欺骗？

这是一个好主意，SSH其实也是这么用的，希望用户第一次登录SSH服务器，要处在一个安全的局域网环境。

完成了服务器认证，接下来的过程和TLS没有任何区别，可以使用RSA分发密钥、DHE分发密钥，然后双方就可以愉快地通信了！

重放攻击

所谓重放攻击，就是第三方捕获了双方的历史通信报文，在合适的时间重新发送一次或多次不等。

如何防止重放攻击？

安全协议为了应对这个挑战，通常会在报文头里嵌入一个序列号，从0开始单向增长的整数，接收方维护着一个类似TCP滑动窗口，不在窗口以内的序列号统统抛弃。即使在窗口内，也要比较接收序列号与缓存的序列号是否相同，如果相同，一样抛弃处理！

写这样没有几个人能看懂的文章，不会有几个赞。但我还是写了，因为读者群里有一部分向往安全的朋友，必须掌握这些基础知识！

看不懂的同学也不要气馁，罗马不是一天建成的，只要坚持看，一定可以看懂的！