web-dev-qa-db-ja.com

Amazon EC2-再起動後にSSHがない、接続が拒否された

私はこれを2、3回繰り返したので、私がやっていることに問題があると思います。

これが私のステップです：

  1. Ubuntu Server 13.10-AMI-ace67f9c（64ビット）を使用してEC2管理コンソールから新しいインスタンスを起動します
  2. デフォルトで起動（既存の鍵ペアを使用）
  3. インスタンスが起動します。 PuTTYまたはMac端末を使用してSSHで接続できます。成功！
  4. インスタンスを再起動します

  5. 10分後、インスタンスをバックアップして実行する必要があるときに、ターミナル接続に次のように表示されます。

    stead:~ stead$ ssh -v -i Dropbox/SteadCloud3.pem [email protected]
OpenSSH_5.6p1, Op`enSSL 0.9.8y 5 Feb 2013
debug1: Reading configuration data /etc/ssh_config
debug1: Applying options for *
debug1: Connecting to 54.201.200.208 [54.201.200.208] port 22.
debug1: connect to address 54.201.200.208 port 22: Connection refused
ssh: connect to Host 54.201.200.208 port 22: Connection refused
stead:~ stead$

私はパブリックIPアドレスが変更される可能性があることを理解しているので、EC2管理コンソールを確認して、同じであることを確認します。変だ。楽しみのために、パブリックDNSホスト名ec2-54-201-200-208.us-west-2.compute.amazonaws.comで接続してみます。サイコロなし、同じ結果。

EC2コンソールに組み込まれたJava SSHクライアントを介して接続を使用しても、接続が拒否されます。

セキュリティグループを確認しました。このインスタンスはグループlaunch-wizard-4にあります。このグループのインバウンド構成を見ると、ポート22は0.0.0.0/0から許可されているため、どこにでもあるはずです。インスタンスにpingできないため、インスタンスにアクセスしていることはわかっています。これが適切なセキュリティグループです。このセキュリティグループに対してICMPを有効にすると、突然pingが実行されます。

同様のエラーメッセージがインターネット上にいくつか投稿されていますが、ほとんどはファイアウォール設定を調整することで簡単に解決できるようです。私はこれらのいくつかを試しましたが、うまくいきませんでした。

見逃している簡単なEC2ステップがあると思います。ご協力いただきありがとうございます。さらに情報を提供したり、さらにテストしたりできます。

更新-Amazon EC2コンソールからのシステムログは次のとおりです： http://Pastebin.com/4M5pwGRt

sshamazon-ec2cloud
18
SteadH

今日、私のec2インスタンスで同様の動作をしていて、これまでを追跡しました：Sudo reboot nowを実行すると、マシンがハングし、Sudo rebootを実行すると、aws管理コンソールから手動で再起動する必要があります正常に再起動します。ここで指摘されているように、「今」は再起動の有効なオプションではないようです https://askubuntu.com/questions/397502/reboot-a-server-from-command-line

考え？

7
oromoiluig

このトピックに関する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. もう一度発砲 。
19
Jeromy French

それは状況を少しも助けにはしないかもしれませんが、EC2の再起動が「スタック」するいくつかのケースを見ました。 VMで「リセット」を行ってからシステムログを取得すると、動作が変わる可能性があります。ログが2番目のブートからのものであり、最初のブートからのものでないことを確認してください。更新が遅れる。

チェックするもう1つのことは、インスタンスがIPで応答していることを確認することです。上記の接続が拒否されたようです。インスタンスは稼働しているようですが、SSHが実行されていないかファイアウォールで保護されていますが、インスタンスが完全に再起動していることを確認してください。

また、テストシステムからすべてのポートを開いてみて、「nmap」が何を示しているかを確認することもできます-インスタンスで応答している他のサービスがあります。

0
Nathan Neulinger