SSH 服务端通过 host key 来避免中间人攻击，包括公钥和私钥两部分。你不可能伪造一份同样的 host key —— 你可以得到远程服务器的公钥，但没有私钥的话，你无法和一个正常的 SSH 客户端完成密钥协商过程（因为你没法解密使用正常公钥加密的数据）。

密钥协商过程大致如下： SSH 开始时，服务器传到客户端的数据中包括服务器的公钥。客户端使用服务器的公钥对发出的数据进行加密，并期待服务器端的 sshd 有对应的私钥，能够解密并理解发出的数据内容。你伪造的中间人得不到对应的私钥，没法知道客户端发回的信息是什么，也就没办法继续协商过程了。

另外再提一句，客户端发回的信息中一定会有随机数，这就要求服务器必须用私钥成功解密客户端的信息之后才能继续协商，从而避免了重放攻击。

参考资料： https://www.vandyke.com/solutions/host_keys/host_keys.pdf

https://cve.mitre.org/ ?

https://www.exploit-db.com/ ?

1. GFW 对不同端口有不同的分析逻辑。基本上和流量大小关系不大。
2. GFW 很可能封锁了来自某个 IP （比如第 15 跳的路由的 IP ） TCP 22 端口的包，从而导致你的 IP 和端口被影响了。
3. GFW 的一种封锁方式是根据来源 IP 而不是目的 IP 丢包。

@rockivy 你对 log 的解读不完整。上面的 log 只能表明，过了第 15 跳之后，你没有收到回应包。这可能是你发的包被中间的路由丢掉了，也可能是回应包被中间的路由丢掉了。

根据来源 IP （和端口）丢包是 GFW 的特性之一。

@huntcool001 图中的时间不是 GMT+8 的。

已入，希望可以一直用下去。楼主的服务单响应速度很快，解决问题也十分及时，大赞！

希望楼主能挺过去。现在付款不便，明天入一个支持一下。

2G 和 8G 之间差了几档？有没有 4G 的规格呢？

楼主可以试试 pwnat: https://github.com/samyk/pwnat

https://github.com/topazproject/topaz :-D

@lalalakakaka 楼主上网之后记得回复我的邮件哦。

我可以帮楼主远程分析一下这个问题。楼主愿意的话就留个邮箱，我晚上或明天白天联系你。

你的 720 个密码里面不包括带有重复数字的密码，比如 112。

应该是你用的私钥 bandwagon_ssh_key 的权限不对。修改你本地私钥的权限就可以了。

1. 确定 binary 里面确实没有这些指令的字节码。
2. 试试在加载的库里面找找这些字节码。如果加载了 libc 的话肯定能找得到的。
3. ROP 最后不一定要调用 syscall。试试直接调用现有的函数。