主页 / ubuntu / 问题 / 483670
Accepted
Tom Brossman
Asked: 2014-06-16 06:51:30 +0800 CST

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

  • 772

为什么重新启动运行 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 连接又可以工作了。

server

4 个回答

  1. Best Answer

    快速回答：

    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来实现这一点。

    • 18

  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

  3. 我可能迟到了，这可能是显而易见的，但对我有用的是检查配置文件/etc/ssh/sshd_config：运行守护进程/etc/init.d/ssh start或任何其他组合显示服务正在运行，即使它没有运行，但如果我启动可执行文件它的绝对路径（在我的例子中/usr/sbin/sshd）我看到配置文件末尾附加了一个“0B”，导致启动时出错，删除它解决了问题。

    • 2

  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文件即可解决问题。

    • -1

相关问题