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全体です。私はそれを作成し、reboot nowコマンドをSSHで送信し、再起動するのを待って2回目にSSHを試行した後、接続拒否エラーを受け取りました。ホスティングコントロールパネルを介してハードリブートすると、SSH接続が再び機能するようになりました。

素早い回答：

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を押して続行するか、ルートパスワードを入力してメンテナンスモードに入るのを待っているのを見ました。キーの組み合わせを押してプロセスを続行し、システムに再度SSHで接続できました。実行後uptime、アップタイムが2分または3分ではなく、多くの日だったことを見て驚いたのは、reboot nowUbuntu 14.04 VPS内で実行されたのは実際には再起動ではなく、単にシングルユーザーモードに移行することを要求していることです！

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

したがって、SSHインストールに問題はありません。問題は、入力するときですreboot now。実際、私は後でテストしました。もしあなたがタイプしたならreboot（言葉だけで、オプションはありません）、それはあなたがやろうとしていたことをしたでしょう：サーバーをリブートしてください。

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

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

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

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

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

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

もう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)

私のシステムの問題は、ssh initスクリプト/etc/init.d/sshがinit のupstartバージョンの存在をチェックする唯一のものであるということでした。

で/etc/init.d/ssh開始さssh,れると信じているため、開始しませんupstart。

私の場合、特定の構成のためにupstartが起動しません。

には正しい構成がありましたが、を含むファイル/etc/init/ssh.confもありました。これは、手動で開始することを意味します。/etc/init/ssh.overridemanualssh

このファイルは、get-remnux.shインストールスクリプトによって作成されました。

手動で開始するか、/etc/init/ssh.overrideファイルを削除すると、問題が解決します。