重启14.04服务器后，什么原因导致SSH问题？

为什么重启运行Ubuntu 14.04的服务器会出现“拒绝连接”错误？

我看到了，ssh: connect to host <IP-address-here> port 22: Connection refused但仅适用于14.04，并且仅在重启后才能看到。我在家使用12.04 Desktop。我该如何解决？

为了使问题更清楚，以下是对我有用或不可行的方法：

• SSH进入12.04的全新安装>注销>再次登录SSH>可行
• SSH进入全新安装的12.04>重新启动>再次进入SSH>可以运行
• SSH进入14.04的全新安装>注销>再次登录SSH>可以运行
• SSH进入14.04的全新安装>重新启动>再次进入SSH>连接被拒绝

我遇到的问题是14.04特有的，仅在重新启动后才会发生。在此之前，我有几台运行12.04的服务器，并且一切仍然正常运行。我有一个要使用14.04的新服务器，我想了解出了什么问题。有什么建议么？

到目前为止，这是我尝试过的方法：

sudo traceroute -p 22 -T <IP-address-here>

Traceroute工作正常，我从SSH端口22上的服务器收到响应。

initctl list
...
ssh start/running, process 23371
...

看起来14.04服务器上的ssh设置为在启动时启动（如预期的那样）。

tom@Desktop:~$ ssh -vvv root@<IP-address-here>
OpenSSH_5.9p1 Debian-5ubuntu1.4, OpenSSL 1.0.1 14 Mar 2012
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to <IP-address-here> [<IP-address-here>] port 22.
debug1: connect to address <IP-address-here> port 22: Connection refused
ssh: connect to host <IP-address-here> port 22: Connection refused

编辑：这是来自新创建的计算机的整个syslog。我创建了它，并在SSH中输入了＆发出了reboot now命令，然后在等待它重新启动并尝试第二次SSH后收到连接被拒绝的错误。通过托管控制面板进行硬重启，现在SSH连接可以再次使用。

快速回答：

SSH不是问题。您用来重新引导的命令是问题所在：不要执行reboot now，执行reboot或shutdown -r now重新引导系统。

命令语法（自13.04开始）为：

reboot [OPTION]...  [REBOOTCOMMAND]

在REBOOTCOMMAND以前从来没有存在过。在12.04中，您now只是被忽略了，但现在正在使用中...它破坏了一切。

长答案，附我的测试结果和解释：

我在某些服务器上运行14.04 AND VPS（在法国OVH提供程序托管-运行OpenVZ）并且在reboot now服务器内部进行操作时遇到类似的问题。

像您一样，我reboot now从控制台发出了命令（使用SSH登录）。按下几秒钟后RETURN，会话自动断开。像您一样，发出此命令后，我再也无法通过SSH重新连接到服务器。

因此，我决定打开OVH提供的KVM控制台。（在这种虚拟服务器上模拟使用物理服务器上的键盘和屏幕进行的直接访问）。

我能够连接到我的机器，并且看到她正在进入单用户模式，等待我按CTRL+ D继续或输入root密码进入维护模式。我按下了组合键，继续进行该过程，然后再次可以SSH进入系统。在运行后uptime，我的惊喜是，正常运行时间不是2或3分钟，而是一天的很多时间：reboot now在Ubuntu 14.04 VPS内执行并没有真正重启，而只是要求进入单用户模式！

由此，我学会了从不要求从VPS内部进行重新引导，而是从主机管理界面上提供的命令中请求重新引导。

因此，您的SSH安装没有问题。问题是当您键入时reboot now。实际上，我随后也对其进行了测试，如果您键入了reboot（只是单词，没有选项），它就可以完成您打算做的事情：重新启动服务器。

使用reboot带参数（从该名男子页）调用命令shutdown与给定的参数。确实，如果执行shutdown now，我将具有相同的行为：系统没有重新启动，而是进入单用户模式。

备注：看起来像是预期的行为，因为点击执行此命令后屏幕上出现的消息显示如下：

系统将进入维护模式

维护模式或单用户模式，表示相同，一个运行级别，不仅仅涉及shell，没有网络，没有网络进程，...

这可能会造成混淆，但是请注意，正确的用法shutdown例如是：shutdown -h now立即停止系统或shutdown -r now立即重新启动系统。我不知道那只shutdown now会使系统进入单用户模式。我通常会这样做init S。

我可能已经晚了，而且可能很明显，但是对我有用的是检查配置文件/etc/ssh/sshd_config：使用守护程序/etc/init.d/ssh start或任何其他组合运行该服务，即使该服务没有运行，但如果我使用以下命令启动可执行文件，它的绝对路径（以我的情况/usr/sbin/sshd为例），我看到在配置文件的末尾附加了一个“ 0B”，它在启动时导致错误，将其删除即可解决问题。

另一个潜在原因是ufw丢失SSH端口规则配置。我发生过至少一两次情况，在应用更新并重新启动后，防火墙配置阻止了我访问服务器。使用托管服务提供商的VPS控制台工具，使我可以进入计算机并诊断问题。以下示例显示了问题（即端口22没有条目）：

user@host:~$ sudo ufw status verbose
[sudo] password for user:
Status: active
Logging: on (low)
    Default: deny (incoming), allow (outgoing), disabled (routed)
New profiles: skip

To                         Action      From
--                         ------      ----
80,443/tcp (Nginx Full)    ALLOW IN    Anywhere
25/tcp                     ALLOW IN    Anywhere
143                        ALLOW IN    Anywhere
110                        ALLOW IN    Anywhere
993/tcp (Dovecot Secure IMAP) ALLOW IN    Anywhere
995/tcp (Dovecot Secure POP3) ALLOW IN    Anywhere
25/tcp (Postfix)           ALLOW IN    Anywhere
465/tcp (Postfix SMTPS)    ALLOW IN    Anywhere
80,443/tcp (Nginx Full (v6)) ALLOW IN    Anywhere (v6)
25/tcp (v6)                ALLOW IN    Anywhere (v6)
143 (v6)                   ALLOW IN    Anywhere (v6)
110 (v6)                   ALLOW IN    Anywhere (v6)
993/tcp (Dovecot Secure IMAP (v6)) ALLOW IN    Anywhere (v6)
995/tcp (Dovecot Secure POP3 (v6)) ALLOW IN    Anywhere (v6)
25/tcp (Postfix (v6))      ALLOW IN    Anywhere (v6)
465/tcp (Postfix SMTPS (v6)) ALLOW IN    Anywhere (v6)

重新启用端口如下所示：

user@host:~$ sudo ufw allow ssh
Rule added
Rule added (v6)

对于我的系统，问题在于ssh init脚本/etc/init.d/ssh是唯一检查instart新版版本是否存在的脚本。

因此/etc/init.d/ssh不要开始，ssh,因为它认为它将由开始upstart。

就我而言，由于我的特定配置，新贵不会开始：

中的配置正确/etc/init/ssh.conf，但是其中/etc/init/ssh.override包含的文件manual，这意味着ssh应该手动启动。

该文件是由get-remnux.sh安装脚本创建的。

手动启动或删除/etc/init/ssh.override文件即可解决问题。