首页 » 日记 » SSHD无法登录

SSHD无法登录

问题描述

git push 失败,用FileZilla上传文件也失败,怀疑是SSHD问题。在终端用ssh登录失败(超时),切换到另一台位于东直门的服务器登录目标机,同样ssh超时。

时间:20130107-20130108。以及后续问题变得更为复杂后的处理。

问题分析

ssh到服务器超时:

ssh: connect to host dongzm.com port 22: Connection timed out

通过Linode控制面板的一个登录功能登录服务器。原理大致是:Linode提供了一个服务器作为中转,ssh到中转机后可以登录控制目标服务器(也是ssh方式,但似乎启动一个类似screen的控制台来操作)。可以通过Linode的网页版(AJAX,类似Chrome浏览器Secure Shell插件)控制(Lish),也可以用SecureCRT/Putty登录Linode中转机。

最终登录服务器后netstat观察到可以收到TCP SYN报文,但客户端回复的ACK没有收到,没有完成三次握手:

$ netstat -nta|grep 22
tcp        0      0 0.0.0.0:22                  0.0.0.0:*                   LISTEN      
tcp        0      0 173.255.196.50:22           111.161.77.198:10188        SYN_RECV    
tcp        0      0 173.255.196.50:22           111.161.77.198:15819        SYN_RECV    

本机的netstat输出:

$ netstat -nat|grep 22
tcp        0      0 192.168.1.105:38620         69.164.200.75:22            ESTABLISHED 
tcp        0      1 192.168.1.105:58439         173.255.196.50:22           SYN_SENT    
tcp        0      0 :::22                       :::*                        LISTEN    

第一条ESTABLISHED是与Linode中转机的连接,第二条是连接目标机的状态,SYN_SENT但没有收到来自服务器的SYC/ACK。

停止sshd服务:

# service sshd stop
Stopping sshd: [  OK  ]

以调试模式启动:

# /usr/sbin/sshd -d

没有什么发现。在目标服务器上反向连接东直门的服务器。成功。退出:

$ netstat -nta|grep 22
tcp        0      0 173.255.196.50:46246        119.254.35.103:22           TIME_WAIT   

推测是客户端发往Server的ACK被截断。这个操作是单向的,出去的ACK被截断,但进来的ACK可以通过。

使用vsftpd临时解决问题

sshd没有解决,有文件要上传。rz上传有问题,只能暂时先搭建一个FTPServer。

# yum install vsftpd

简单修改下配置文件:

/etc/vsftpd/vsftpd.conf

启动vsftpd:

# service vsftpd start
Starting vsftpd for vsftpd: [  OK  ]

在本地用lftp上传文件:

$ lftp -uUSERNAME HOST
...
> mput *.JPG

关闭vsftpd:

# service vsftpd stop
Shutting down vsftpd: [  OK  ]

使用中转机临时解决问题

用FTP传输异常缓慢,而且时常被断开。因为已经试验过在目标服务器可以反向连接东直门的中转服务器,因此先用Linode登录目标机,并把文件传输到东直门服务器,再在目标机上执行scp

$ scp user@dongzm.com:/home/my/20130108.zip .

同样,把备份文件传回东直门:

$ scp backup/file.gz user@dongzm.com:/home/my/

Linode提供的解决方案

概述:先用MTR诊断(Linode MTR帮助文档),把输出发给Linode。接着Linode后提供了一个新的IP,绑定到服务器上,需要配置(Linode 静态IP配置帮助文档)。因为需要修改DNS配置,所以暂且没操作。不过Linode工作人员已把IP做过一个修改,导致当晚用户都没法访问,直到次日我重启服务器,回复到旧IP。

Linode的回复速度极为惊人,以分钟级别的速度与客户交流(通过他们平台而非IM),给我留下深刻印象。企业做到这么大还能有这么快的响应速度,真是值得学习。

用MTR诊断

在本机运行MTR的输出:

# mtr --report -n 173.255.196.50
berlinix.com                      Snt: 10    Loss%  Last   Avg  Best  Wrst StDev
118.198.128.1                                 0.0%   2.4   3.3   1.6   4.8   1.0
118.198.128.1                                 0.0%   2.5   3.5   1.5   6.0   1.5
124.205.97.52                                 0.0%   3.3   4.4   3.0   6.8   1.4
218.241.165.205                               0.0%   2.4   3.5   2.4   4.9   0.7
124.205.98.105                                0.0%   3.4   4.2   2.3   6.9   1.5
202.99.1.125                                  0.0%   2.8   4.8   2.8   7.6   1.7
218.241.165.254                              10.0%  17.6  19.7  13.8  31.6   5.5
???                                          100.0   0.0   0.0   0.0   0.0   0.0
218.11.180.49                                 0.0%  26.9  28.7  24.4  49.0   7.3
...

这里看到有一行 ??? 丢包率为100%,这就是原因了。

我的解决方案

将东直门服务器作为中间一跳,开发机push到东直门,再通过Linode Lish到目标机,在目标机上pull。这个方案的棘手之处在于只能Lish到目标机,比较麻烦。但好歹可以执行更新代码、上传文件、下载备份数据等几个核心操作。

后续

UPDATE: 20130112 - 问题比想象中严重,而且几天以来,问题复杂性不断增加。首先是作为中转机的东直门服务器不能再连接目标服务器;其次是目标服务器上的程序,无法正常访问国内网页(因业务需求,要访问国内某些网页);再次,从办公场所通过Web访问目标服务器也失败了。这3个问题可谓灭顶之灾。

解决方案:

  1. 把中转机替换为JP的一台Linode,所幸SSH JP目前还没有太大问题,无论是git/scp都能比较流畅地进行。
  2. 目标服务器通过JP的Linode访问国内页面,并返回数据。这里需要修改代码,把一个功能从函数调用变更为Web调用。返回JSON。
  3. 办公场所访问是个老问题,经常出现访问中断,这次使用Astrill临时解决问题。

之前,Linode工作人员建议替换IP,是不太可行的方案。替换IP涉及DNS修改,会导致部分用户数小时无法访问(DNS 缓存),更为严重的是,如果替换IP后仍被封,则可能需要频繁替换IP,服务则更不稳定(而且Linode未必肯多次为你替换IP)。

新加中间一跳的好处在于,这一跳涉及关键业务(访问国内页面),但它可以随时迁移到任何IP上,将不稳定性从目标服务器转移到中转机,则用户几乎可以不中断使用我们的服务。

题外话

虽然不优雅地临时解决了问题,但能维持多久还未可知。当我在微博搜索Linode时,不少人也在说这个问题,据说北美的Linode几乎全部沦陷,又有说不是针对Linode,有人贴出Linode的回复(这个回复和我从Linode得到的回复很相似):

Linode SSH failed

再看另一则关于Astrill的新闻(之前一段时间的):

Linode SSH failed

分享

0