九死一生的远程连接(ssh,sftp,svn)

最近公司服务器上的 mysql 突然崩盘，引发了一系列的血案。连续三天一直在想办法，考虑怎样恢复数据，始终是徒劳。中间老板请了专门做数据恢复的大神，最后在周五下午终于恢复了所有数据。果然，大神都不是这么简单的。能从 MySQL 的 bin-log 日志及 ib-log 数据日志中全盘恢复数据，这是我不能够想象的。

我自以为很简单的，也是最直接的方法，直接文件恢复，在听了大神的说法后，被无情抛弃了。我们在 mysql 崩盘之后，一直围绕着远程连接 mysql 的报错，及启动 mysql 服务的报错，和数据日志报的错打转，但就是没有实质性的进展。这时候一位同事，脑子不知道怎么想的，直接按照他在网上教程上的说法，初始化了 mysql 数据库./scripts/mysql_install_db --default-file=/etc/my.conf。这时候的我看到存放 mysql 数据的目录下满满的都是 bin-log 文件，我以为数据都还在，但考虑到数据不能被污染，也是听了那同事的建议（他在拷贝数据文件下的文件到本地，慢得要死），就直接 cp data/* databackup/，没有考虑到，文件恢复，是要保留现场的，最好是关闭服务器上所有进程，取消磁盘的挂载（当然这不现实）。这样的大规模的磁盘操作之后，想要恢复，基本已是奢望（我自己不服气，还真的用 re­tun­delete 恢复了一下，确实渣都不剩一点了）。

公司的数据库数据丢失还不是最恼人的，在 mysql 挂掉当天之前，到今天才找到原因的远程连接挂掉才是。在那天挂掉之前，我想用 putty 连接一下我自己的服务器（就是现在这台）。可是突然告诉我，The Au­then­tic­ity of host xxx can't be es­tab­lished，什么什么的不能创建，然后往本地 known_hosts 添加这一主机。这个很像在我使用 putty 第一次连接某个服务器的时候回弹出来的内容，但想想又有点不一样。我没怎么考虑，就直接点了 yes。然后输入账号，回车，直接弹框报错，per­mis­sion de­nied (pub­lickey)。之后这个就像魔障一样一直不停的出现在我的眼前。我用 git bush 中的 ssh 直接登录，也是这个错。中间试了一下其他的服务器，有的直接登录了，有的也登不了。然后中间还提醒说，有可能是中间人攻击，也有可能是 host key 发生了变化（本地还是服务器，忘了）。感觉一团糟，什么头绪都没有，然后还要不停地盯着公司的服务器想办法恢复。太累了。之后有找阿里云去申请工单。他说远程连接没问题，分析得也对，因为我家里的电脑是可以登录的。然后就是查看服务器上的 ssh 配置文件，防火墙，阿里云控制台的安全组，都没改过，确认了一下，忍不住按照各种教程，来回改，但是核心的 Pass­wor­dAu­then­ti­ca­tion yes 是没有问题的，防火墙我压根没开，然后安全组也是最简化版本的。这时候就让我抓包试试，我也抓包了，可是他分析了一下，得出的结论是，没有问题，三次握手成功，没有 re­set。然后最终版的建议就是，换一个 ssh 工具。没办法，如果真的是工具问题，那就换吧！下了个破解版的 XShell 和 se­cure­CRT，竟然没有让我输入密码，如 XSell 直接就只有一个设置公钥文件的选项。这就把我带沟里了。我想的是，那肯定是服务器没有开启密码登录授权的方式啊，但是我并没有改过这些配置，尤其是其他的服务器也是这种情况。这就是一个死胡同。
然后，今天加班，早早地过来找原因，各种错误，各种搜，方法也是试了好多种了。找到一篇关于远程连接错误排查的文章，是阿里云上的。https://help.aliyun.com/knowledge_detail/41470.html?spm=a2c4g.11186623.4.1.40b66cd3DyxjAw

说先排查服务器，配置，ssh 服务是否开启，还有就是服务器本地连接 ssh localhost/127.0.0.1 是否成功。这些服务器端的都检查了一遍，没有问题。然后是客户端，不同的 ssh 客户端依然无法登录，我甚至用了同事的电脑下了一个 putty，然后连接，依然是这样的错误。所以客户端应该是没有问题的。然后就是中间网络了。tel­nent 服务器的端口，也没问题可以通。之后文章下面连接的一些错误排查，有相同的，如：SSH 登录时出现如下错误：Disconnected:No supported authentication methods available，可是，它还是让我去修改 ssh 配置文件，这就让心情一下子糟糕起来了。这样是不行的呀。

刚好排查到网络层级，我想到网络层，换一个网是不是就好了，我家里的能连接，这不就是佐证吗？赶紧开个热点，连上 wlan，然后打开 putty，连接服务器，然后就像第一次连接一样，弹出存储公钥之类的提示信息。确认后，输入 root，回车，呼～，从前的我又回来了。

问题找到了，公司在路由器接入的地方加装了一台服务器，也做了一些配置。这可能就是导致提醒中间人攻击的原因。真可怕。终于找到了原因，不然我感觉自己都要快崩溃了。轻松连上服务器，上传文件，svn 备份。ok，下班！

注：中间有过重启服务器实例之类的，导致 svn 服务挂了，然后早上在家准备备份数据的，发现 cor­ner­stone 停止工作了，报错了。mmp，排查过程中，把它启动了，然后 svn 没问题了。