SSH如何防御重放攻击？
SSH是一个什么样的存在？SSH类似于TLS，站在TCP 端口22上，TLS站在TCP 端口443上。所以，这两者是平起平坐的，都可以提供安全加密服务。对SSH不熟悉的同学，可以用TLS的知识来学习SSH。网络安全有一个经典口号，不造轮子，只使用轮子！什么意思呢？私自造轮子，本来想提供安全的通信，可是考虑不周全，引入了更多的安全漏洞，得不偿失。
使用酒精考验的轮子，经历了全人类不断捶打的轮子，使用起来更放心！所以，SSH和TLS尽管名称不同，安全的三要素是相同的套路。认证对方分发密钥加密数据SSH与TLS认证方式有一点区别，TLS采用第三方CA认证，而SSH为了简化，没有采用第三方的CA，而是采用双方互相认证。SSH公钥认证当客户端与服务器完成TCP三次握手，紧接着就是SSH双方开始了握手协商的过程。
服务器会将自己的公钥以明文的方式推送给客户端，为了避免被第三方篡改，公钥的尾部报文还附带服务器私钥的签名保护。客户端获得服务器的公钥，用公钥解密签名，可以解开，说明公钥完好。解不开说明公钥被篡改。这里有一个问题，客户端永远都不知道公钥是不是服务器的，对吗？服务器出示一张名片，上面赫然写着“马云”，客户端就相信这个是马云了？客户端尽管傻，但是设计SSH人并不傻，设计人员是这么想的。
假如客户端与服务器第一次通信，是在一个安全的局域网里，双方如同在一个小会议室见面，然后双方交换名片，以后双方即使在互联网上通信，依然只认在小会议室交换的名片，是不是就可以避免被第三方欺骗？重放攻击所谓重放攻击，就是第三方捕获了双方的历史通信报文，在合适的时间重新发送一次或多次不等。如何防止重放攻击？安全协议为了应对这个挑战，通常会在报文头里嵌入一个序列号，从0开始单向增长的整数，接收方维护着一个类似TCP滑动窗口，不在窗口以内的序列号统统抛弃。
HTTPS如何防止重放攻击？
客户端拼接字符串规则如下：接口 参数 时间戳 secretID（如果不是做对外开放性的API，是内部产品调用的话那么secretID可以是写死的一个ID值）将以上字符串用对称加密，作为一个sign参数，请求服务端。比如接口，login，参数有 name、password、加密后的sign服务端接收到请求后，用对称解密sign，得到secretID，核对值是否正确，那么说明请求方是可信任的。
