为什么重新启动运行 Ubuntu 14.04 的服务器会出现“连接被拒绝”错误？
我知道ssh: connect to host <IP-address-here> port 22: Connection refused，但只适用于 14.04 版，而且必须重启后才能解决。我在家使用 12.04 版桌面版。我该如何解决此问题？
为了使问题更清楚，以下是对我有用或无用的方法：
- 通过 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
编辑：这是来自新创建的机器的整个系统日志。我创建了它，通过 SSH 登录并发出reboot now命令，然后在等待它重新启动并第二次尝试 SSH 后收到连接被拒绝错误。通过主机控制面板硬重启，现在 SSH 连接再次正常工作。
答案1
快速回答：
SSH 不是问题。问题在于您用来重新启动的命令：不要执行reboot now、reboot或shutdown -r now来重新启动系统。
命令语法 (自 13.04 起) 已：
reboot [OPTION]... [REBOOTCOMMAND]
以前从未REBOOTCOMMAND存在过。在 12.04 中，你的now只是被忽略，但现在它被使用了……而且它破坏了一切。
长答案，附有我的测试结果和解释：
reboot now我在使用 14.04 和 VPS（托管在法国 OVH 提供商 - 运行 OpenVZ）的某些服务器以及在服务器内部执行操作时也遇到了类似的问题。
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来实现这一点。
答案2
另一个潜在原因是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)
答案3
我可能来晚了，而且这可能很明显，但对我有用的是检查配置文件/etc/ssh/sshd_config：使用/etc/init.d/ssh start或任何其他组合运行守护进程表明服务正在运行，即使它没有运行，但如果我使用其绝对路径启动可执行文件（在我的情况下/usr/sbin/sshd）我看到在配置文件末尾附加了一个“0B”，导致启动时出现错误，删除它解决了问题。
答案4
对于我的系统来说，问题在于 ssh init 脚本/etc/init.d/ssh是唯一一个检查是否存在 upstart 版本的 init 的脚本。
因此/etc/init.d/ssh不会启动，ssh,因为它认为它将由 启动upstart。
在我的例子中，由于我的特殊配置，upstart 无法启动：
中有一个正确的配置/etc/init/ssh.conf，但也有一个/etc/init/ssh.override包含的文件manual，这意味着ssh需要手动启动。
该文件由安装脚本创建get-remnux.sh。
手动启动或删除/etc/init/ssh.override文件可以解决问题。