解决SSH不能远程登录VPS服务器的奇怪故障

前两天一个朋友听取了我的建议，要自己做一个外贸网站（自己建外贸网站的原因在这里），并在我的推荐下购买了Vultr的VPS服务器，操作系统选用的是Ubuntu Server 16.04 LTS。注册、付款、以及创建服务器实例的过程是朋友自己操作的，而配置web服务器的环境和安装Wordpress则是大伟哥抽空帮忙搞定的。在这个过程中，我发现通过Vultr的后台控制面板能够用root用户进入VPS系统，但是远程使用putty或者Linux SSH命令，每次尝试登陆，都会出现下面的提示：

ssh root@12.34.56.78
Connection closed by 12.34.56.78

这是怎么回事呢？以下是排查的思路和步骤：

1. 首先排除是VPS的IP地址是被别人使用过进入了黑名单被和谐的可能。

如果你的IP地址很幸运地被和谐了，那SSH肯定是连接不上的，所以首先要排除这一点。我们可以使用PING命令初步判断一下（实际是PING不通也不一定说明就是被和谐了，但是能PING通的话就说明肯定没有被和谐）：

daweibro@Workstation:~$ ping 12.34.56.78
PING 12.34.56.78 (12.37.56.78) 56(84) bytes of data.
64 bytes from 12.37.56.78.vultr.com (12.37.56.78): icmp_seq=1 ttl=40 time=197 ms
64 bytes from 12.37.56.78.vultr.com (12.37.56.78): icmp_seq=2 ttl=40 time=207 ms
64 bytes from 12.37.56.78.vultr.com (12.37.56.78): icmp_seq=3 ttl=40 time=200 ms
64 bytes from 12.37.56.78.vultr.com (12.37.56.78): icmp_seq=4 ttl=40 time=193 ms
64 bytes from 12.37.56.78.vultr.com (12.37.56.78): icmp_seq=5 ttl=40 time=203 ms
64 bytes from 12.37.56.78.vultr.com (12.37.56.78): icmp_seq=6 ttl=40 time=208 ms
64 bytes from 12.37.56.78.vultr.com (12.37.56.78): icmp_seq=7 ttl=40 time=206 ms
64 bytes from 12.37.56.78.vultr.com (12.37.56.78): icmp_seq=8 ttl=40 time=209 ms
64 bytes from 12.37.56.78.vultr.com (12.37.56.78): icmp_seq=9 ttl=40 time=193 ms
^C
--- 12.37.56.78 ping statistics ---
9 packets transmitted, 9 received, 0% packet loss, time 8868ms
rtt min/avg/max/mdev = 193.526/202.492/209.418/5.953 ms

能Ping的通，说明线路没问题啊，肯定不是被和谐了。那接下来再找其他原因。

2. 再来确认SSH服务器有没有安装，有没有启动。

一般查看系统中有没有运行某个服务的进程，可以使用ps -e | grep 进程名查看是否存在，如果没有返回相应的结果的话，就需要启动相应的服务了。

这里我们应该使用ps -e | grep sshd来查询，但是Vultr网站上的管理工具noVNC的功能是受限制的，没法输入“|”符号和“<”符号，所以没法用这种方法查看。所以大伟哥用重新启动sshd进程的方法来确保SSH Server的进程是存在的。重启sshd进程的命令：service sshd restart 或者/etc/init.d/sshd restart, 如果提示服务不存在，那就运行apt-get install openssh-server安装服务再启动。

3. 确认SSH服务器没有禁用root用户远程登录，有决有禁用密码登录，有没有防火墙禁用SSH端口

因为朋友是新安装的VPS操作系统,使用的是root用户，所以我们需要确认SSH服务是允许root用户通过远程登录管理的。SSH Server的配置文件是/etc/ssh/sshd_config，我们要确保里面有这么一行，而且前面没有#注释号：

PermitRootLogin yes

如果没有发现这一行或者这一行是PermitRootLogin prohibit-password，那需要把prohibit-password相应修改成yes。修改以后还要再次重启还能生效。

但是大伟哥在这里并没有发现什么可疑的地方，而问题还是没有解决。使用ufw status查看防火墙状态，也没有发现系统屏蔽默认的SSH端口22。

4. 使用SSH -v 进行debug

实在没辙了，只能用ssh加上-v参数debug，看看有没有什么提示线索：

daweibro@Workstation:~$ ssh -v 12.34.56.78
OpenSSH_6.6.1, OpenSSL 1.0.1f 6 Jan 2014
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug1: Connecting to 12.34.56.78 port 22.
debug1: Connection established.
debug1: identity file /home/daweibro/.ssh/id_rsa type -1
debug1: identity file /home/daweibro/.ssh/id_rsa-cert type -1
debug1: identity file /home/daweibro/.ssh/id_dsa type -1
debug1: identity file /home/daweibro/.ssh/id_dsa-cert type -1
debug1: identity file /home/daweibro/.ssh/id_ecdsa type -1
debug1: identity file /home/daweibro/.ssh/id_ecdsa-cert type -1
debug1: identity file /home/daweibro/.ssh/id_ed25519 type -1
debug1: identity file /home/daweibro/.ssh/id_ed25519-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.6.1p1 Ubuntu-2ubuntu2.10
debug1: Remote protocol version 2.0, remote software version OpenSSH_7.2p2 Ubuntu-4ubuntu2.4
debug1: match: OpenSSH_7.2p2 Ubuntu-4ubuntu2.4 pat OpenSSH* compat 0x04000000
debug1: SSH2_MSG_KEXINIT sent
Connection closed by 12.34.56.78

根据debug的信息去Google搜索，没有发现直接的解决方法，但却找到了一个排查的方向，那就是可以看看系统里密钥文件的大小，理论上密钥文件的大小肯定不是零的，必然要有一定的数据量，但在很偶然的情况下，却有密钥文件大小为零的情况，这说明密钥没有正确生成，导致了SSH服务不能正常登录。如下面出现的情况：

root@12.34.56.78:/etc/ssh# ll
total 268K
drwxr-xr-x.   2 root root     4.0K Mar 20 06:06 ./
drwxr-xr-x. 128 root root      12K Mar 20 05:15 ../
-rw-r--r--.   1 root root     237K Mar 20 23:30 abcde
-rw-r--r--.   1 root root     2.2K Mar 20 23:30 ssh_config
-rw-------.   1 root root     4.3K Mar 20 06:03 sshd_config
-rw-r-----.   1 root ssh_keys    0 Mar 20 00:46 ssh_host_ecdsa_key
-rw-r--r--.   1 root root        0 Mar 20 00:46 ssh_host_ecdsa_key.pub
-rw-r-----.   1 root ssh_keys    0 Mar 20 00:46 ssh_host_ed25519_key
-rw-r--r--.   1 root root        0 Mar 20 00:46 ssh_host_ed25519_key.pub
-rw-r-----.   1 root ssh_keys    0 Mar 20 00:46 ssh_host_rsa_key
-rw-r--r--.   1 root root        0 Mar 20 00:46 ssh_host_rsa_key.pub

好几个密钥文件大小都是0！大伟哥发现这台VPS服务器上的出现的情况是一样的，这意味着有可能通过重新生成密钥文件解决。按照Google到的解决方法，大伟哥做了以下操作：

ssh-keygen -t rsa -f /etc/ssh/ssh_host_rsa_key
ssh-keygen -t ecdsa -f /etc/ssh/ssh_host_ecdsa_key
ssh-keygen -t ed25519 -f /etc/ssh/ssh_host_ed25519_key

然后再次从本地ssh尝试连接：

daweibro@Workstation:~$ ssh root@12.34.56.78
The authenticity of host '12.34.56.78 (12.34.56.78)' can't be established.
RSA key fingerprint is 9a:50:48:ff:3d:71:59:47:8d:5e:65:f4:5b:51:8e:01.
Are you sure you want to continue connecting (yes/no)? 

成功了！这下再也不用先登录Vultr然后使网页noVNC管理VPS了。