web-dev-qa-db-ja.com

14.04サーバーの再起動後にSSHの問題が発生する原因は何ですか？

Ubuntu 14.04を実行しているサーバーを再起動すると、「接続拒否」エラーが発生するのはなぜですか？

ssh: connect to Host <IP-address-here> port 22: Connection refusedが表示されますが、14.04のみで、再起動後のみです。自宅で12.04デスクトップを使用しています。これをトラブルシューティングするにはどうすればよいですか？

質問をより明確にするために、ここで私にとって機能するものと機能しないものを示します。

  • 12.04の新規インストールへのSSH>ログアウト> SSHの再入力>動作
  • 12.04の新規インストールへのSSH>再起動> SSHの再入力>動作
  • 14.04の新規インストールへのSSH>ログアウト> SSHの再入力>動作
  • 14.04の新規インストールへのSSH>再起動> 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コマンドを発行し、再起動するのを待って2回目のSSHを試みた後、接続拒否エラーが発生しました。ホスティングコントロールパネルを介してハードリブートすると、SSH接続が再び機能するようになりました。

server14.04sshopenssh
15
Tom Brossman

素早い回答：

SSHは問題ではありません。再起動に使用するコマンドが問題です。システムを再起動するには、reboot nowを実行せず、rebootまたはshutdown -r nowを実行しないでください。

コマンド構文（ 13.04以降 ）は次のとおりです。

reboot [OPTION]...  [REBOOTCOMMAND]

REBOOTCOMMANDは以前に存在していませんでした。 12.04では、nowは無視されましたが、現在使用されています...そして、すべてを壊しています。

私のテスト結果と説明を含む長い答え：

14.04およびVPS（フランスのOVHプロバイダーでホストされ、OpenVZを実行）で実行しているサーバーと、サーバー自体でreboot nowを実行しているサーバーで同様の問題があります。

あなたと同じように、コンソールからコマンドreboot nowを発行しました（SSHを使用してログインします）。押してから数秒 RETURN、私のセッションは自動的に切断されます。あなたのように、このコマンドを発行した後、SSH経由でサーバーに再接続することはできませんでした。

そこで、OVHが提供するKVMコンソールを開くことにしました。 （この種の仮想サーバーでは、物理サーバー上のキーボードと画面を使用して直接アクセスをエミュレートします）。

私は自分のマシンに接続することができ、彼女がシングルユーザーモードに入って、押すのを待っているのを見ました CTRL+D 続行するか、rootパスワードを入力してメンテナンスモードに切り替えます。キーの組み合わせを押してプロセスを続行し、システムに再度SSH接続できました。 uptimeを実行した後、アップタイムが2分または3分ではなく、多くの日だったことを見て驚いたのは、Ubuntu 14.04 VPS内で実行されたreboot nowは実際には再起動ではなく、シングルユーザーモードに移行することを要求しているだけです！

このことから、VPS内から再起動を要求するのではなく、ホストの管理インターフェイスで提供されるコマンドから再起動を要求することを学びました。

したがって、SSHインストールに問題はありません。問題は、reboot nowと入力したときです。実際、reboot（Wordのみ、オプションなし）を入力した場合は、後でテストしました。つまり、サーバーを再起動します。

引数付きのrebootを（manページから）使用すると、指定された引数でshutdownコマンドが呼び出されます。実際、shutdown nowを実行すると、同じ動作になります。システムは再起動されず、シングルユーザーモードになります。

備考：このコマンドの実行を押した後に画面に表示されるメッセージは次のようなものであるため、意図した動作のようです：

システムはメンテナンスモードになります

メンテナンスモードまたはシングルユーザーモード。これは、シェル、ネットワークなし、ネットワークプロセスなしなどに注意するランレベルと同じです。

これは混乱を招くかもしれませんが、shutdownの正しい使用法は、たとえば、今すぐシステムを停止するshutdown -h nowや、今すぐ再起動するshutdown -r nowであることに注意してください。 shutdown nowがシステムをシングルユーザーモードにするだけであることを知りませんでした。私は通常、これを達成するためにinit Sを実行します。

17
Benoit

もう1つの潜在的な原因は、ufw SSHポートルールの設定を失ったことです。これは、少なくとも1〜2回発生しました。更新プログラムを適用して再起動した後、ファイアウォール構成によってサーバーへのアクセスがブロックされていました。ホスティングプロバイダーの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)
2
John Rix

私は遅れているかもしれませんが、明らかかもしれませんが、私のために働いたのは、構成ファイル/etc/ssh/sshd_configを確認することでした：/etc/init.d/ssh startまたは他の組み合わせでデーモンを実行すると、サービスが実行されていてもそうではありませんでしたが、その絶対パスで実行可能ファイルを起動すると（私の場合は/usr/sbin/sshd）、構成ファイルの最後に「0B」が追加され、起動時にエラーが発生しました。問題。

2
tama