web-dev-qa-db-ja.com

EC2インスタンスを実行すると突然SSH接続が拒否される

数日前にEC2インスタンスをセットアップしましたが、昨夜でも問題なくSSHでインスタンスに接続できました。今日の朝、私はそれにsshできません。セキュリティグループではポート22が既に開いており、昨夜から何も変更していません。

エラー：

ssh: connect to Host [ip address] port 22: Connection refused

最近同様の問題が発生し、その理由を理解できなかったため、新しいインスタンスを作成して再度セットアップし、すべてのEBSストレージを新しいインスタンスに接続して構成する必要がありました。数時間かかりました...そして今、それは再び起こっています。前のバージョンではdenyhostをインストールしましたが、ブロックされた可能性がありますが、現在のバージョンではApache2とmysqlしか実行されていません。

現在のインスタンスは16時間稼働しているので、起動が完了しなかったためとは思われません...また、ポート22はすべてのソース（0.0.0.0/0）に開かれていて、tcpプロトコルを使用しています。

何か案は？

ありがとう。

apachesshamazon-web-servicesamazon-ec2connection
19
Sherzod

@ abhi.gupta200297の助けを借りて、私たちはそれを解決することができました。

問題は/etc/fstabのエラーであり、sshdはfstabが成功した後に開始されるはずでした。しかし、そうではなかったので、sshdは起動せず、そのため接続が拒否されました。解決策は、一時的なインスタンスを作成し、元のインスタンスからルートEBSをマウントし、fstabおよびvoilaからコメントアウトすることでした。これにより、再度接続できます。そして将来のために、fstabの使用をやめて、EBSボリュームをディレクトリにマウントするための一連のシェルコマンドを作成し、それらを/etc/init.d/ebs-init-mountファイルに追加してから、update-rc.d ebs-init-mount defaultsを実行してファイルを初期化しましたロックされたsshに関する問題はもうありません。

UPDATE 4/23/2015

Amazonチームは同様の問題のビデオチュートリアルを作成し、この方法を使用してデバッグする方法を示します。 https://www.youtube.com/watch?v=_P29ZHu_fe

28
Sherzod

何らかの理由でsshdが停止した可能性があります。インスタンスEBSはサポートされていますか？その場合は、シャットダウンしてから再起動してください。これで問題は解決します。

また、AWSウェブコンソールからSSHできますか？ Javaプラグインがあり、インスタンスにSSHで接続します。

7
abhi.gupta200297

再起動後にEC2インスタンスにSSHで接続できないためにこの投稿に遭遇した場合は、 これはクロスポストされています から serverfaultでの同様の質問 ：

このトピックに関するAWS開発者フォーラムの投稿 から：

壊れたインスタンスを停止し、EBSボリュームを切り離して、別のインスタンスにセカンダリボリュームとして接続してみてください。壊れたボリュームを他のインスタンスのどこかにマウントしたら、/ etc/sshd_configファイル（下部近く）を確認します。 Yumがsshd_configをスクロッグして、構文エラーのために起動時にsshdが失敗する原因となった重複行を下部に挿入しました。

修正したら、ボリュームをアンマウントし、デタッチし、他のインスタンスに再接続して、再度起動します。

AWSのドキュメントへのリンクを使用して、これを分解してみましょう。

  1. 壊れたインスタンスを停止 し、EC2管理コンソールに移動して、[Elastic Block Store]> [ボリューム]をクリックし、インスタンスに関連付けられているボリュームを右クリックして、EBS（ルート）ボリュームをデタッチします。やめた.
  2. 壊れたインスタンスと同じリージョンで同じOSの新しいインスタンスを起動します次に 元のEBSルートボリュームをセカンダリボリュームとして接続します）新しいインスタンスに 。以下のステップ4のコマンドは、ボリュームを「data」というフォルダーにマウントすることを前提としています。
  3. 壊れたボリュームを他のインスタンスのどこかにマウントした 、
  4. 次のコマンドを発行して、「/ etc/sshd_config」ファイルで重複エントリを確認します。
    • cd /etc/ssh
    • Sudo nano sshd_config
    • ctrl-vファイルの最後に到達するまでの時間
    • ctrl-k "PermitRootLogin without-password"と "UseDNS no"に言及する下部のすべての行
    • ctrl-xおよびYは、編集したファイルを保存して終了します。
  5. @ Telegard（彼のコメントで）指摘 私たちは症状を修正しただけです。 「/etc/rc.local」ファイルの3つの関連する行をコメント化することで、原因を修正できます。そう：
    • cd /etc
    • Sudo nano rc.local
    • 「PermitRootLogin ...」行を探して削除します
    • ctrl-xおよびYは、編集したファイルを保存して終了します。
  6. 修正したら、 ボリュームのマウントを解除 、
  7. eC2管理コンソールに移動し、[Elastic Block Store]> [Volumes]をクリックして、停止したインスタンスに関連付けられているボリュームを右クリックして、デタッチします。
  8. 他のインスタンスに再接続 および
  9. もう一度発砲 。
6
Jeromy French

Red Hat EC2インスタンスでは、インスタンスを起動するたびに次の2行が/ etc/ssh/sshd_configファイルの末尾に自動的に追加されていたため、これが発生しました。

パスワードなしのPermitRootLogin
UseDNS no

これらの追加操作の1つは改行なしで行われたため、sshd_configファイルの末尾は次のようになります。

パスワードなしのPermitRootLogin
UseDNS noPermitRootLogin without-password
UseDNS no

これにより、sshdは次の起動時に起動に失敗しました。これはここで報告されたバグが原因で発生したと思います： https://bugzilla.redhat.com/show_bug.cgi?id=956531 解決策はsshd_configファイルの下部にある重複したエントリをすべて削除し、最後に改行を追加します。

4
ianmcook

AWS管理コンソールに移動し、インスタンスを選択し、右クリックして[システムログの取得]を選択します。これにより、問題のリストが表示されます。

1
Stewie

EBSを切り離すことで同様のsshがロックアウトされましたが、/ etc/fstabを変更するのを忘れていました

0
wdanxna

同じ問題がありましたが、sysログには次のような問題がありました：

Sshdの開始：/ var/empty/sshdはrootが所有する必要があり、グループまたは全ユーザーが書き込み可能ではありません。 [失敗]

上記と同じ手順を使用して、ボリュームを切り離し、接続可能なインスタンスに接続しました。次に使用：

Sudo chmod 755/var/empty/sshd

Sudo chown root：root/var/empty/sshd

（ https://support.Microsoft.com/en-us/help/4092816/ssh-fails-because-var-empty-sshd-is-not-owned-by-root-and-is-not -グループ ）

次に、デタッチして元のEC2インスタンスに再アタッチし、ssh経由でアクセスできるようになりました。

0
user3473534

Ubuntuにsystemdがある場合、/lib/systemd/system/local-fs.targetを編集して、最後の2行をコメント化できます。

#OnFailure=emergency.target
#OnFailureJobMode=replace-irreversibly

私はこれを広範囲にテストしておらず、リスクや副作用が含まれているかどうかはわかりませんが、これまでのところ、それは魅力のように機能します。ルートボリュームと他のすべてのボリュームをマウントし（構成が正しくないボリュームを除く）、SSHが起動するまでブートプロセスを続行するため、インスタンスに接続して、誤ったfstabエントリを修正できます。

0
ThiagoAlves