21

数日前に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プロトコルを使用しています。

何か案は？

ありがとう。

4

11 に答える 11

29

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

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

2015年4月23日更新

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

于 2012-12-27T07:15:52.553 に答える
7

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

また、AWS WebコンソールからSSHで接続できますか？インスタンスにSSH接続するためのJavaプラグインがあります。

于 2012-12-24T22:45:51.703 に答える
6

再起動後にEC2インスタンスにSSHで接続できないためにこの投稿に出くわした方のために、これはserverfaultでの同様の質問にクロスポストされています。

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

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

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

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

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

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

パスワードなしの
PermitRootLoginUseDNSno

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

パスワードなしのPermitRootLoginUseDNSnoパスワードなし
の
PermitRootLoginUseDNSno

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

于 2014-02-04T21:10:26.113 に答える
1

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

于 2012-12-24T22:34:32.160 に答える
0

EBSをデタッチすることで同様のsshがロックアウトされましたが、/ etc/fstabを変更するのを忘れました

于 2016-02-26T10:18:35.520 に答える
0

同じ問題がありましたが、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-group）

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

于 2019-05-21T13:53:46.423 に答える
0

あなたのubuntuが持っているならsystemd、あなたは最後の2行を編集/lib/systemd/system/local-fs.targetしてコメントアウトすることができます：

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

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

于 2019-07-29T03:04:51.783 に答える
0

私の場合、ボリュームが不足していて、サービスを開始できませんでした。AWSチュートリアル（Sherzodの投稿から）を使用して、それを適切なEC2インスタンスにマウントし、クリーンアップしてスタートアップからサービスを削除してから、再マウントして動作を確認しました。

于 2020-05-20T21:10:46.173 に答える
0

私にとっては、IPが変更されたということでした。これが誰かを助けることを願っています。セキュリティグループに移動し、インバウンドルールでマイIPを更新します。

于 2021-09-07T21:28:56.380 に答える
0

同じ問題が発生し、パーミッション拒否エラーでawsインスタンスに接続できませんでした。

画面共有の呼び出しでawsチームに接続でき、次のユーザーメタスクリプトを使用してawsインスタンスのフォルダー権限を変更するように案内されました。

手順：

  1. インスタンスを停止します
  2. アクション>インスタンス設定>ユーザーメタの編集

ここに画像の説明を入力してください

  1. 以下のスクリプトを入力して保存します

**コンテンツタイプ：マルチパート/混合; border = "//" MIME-Version：1.0-// Content-Type：text / cloud-config; charset = "us-ascii" MIME-Version：1.0 Content-Transfer-Encoding：7bit Content-Disposition：attachment; filename = "cloud-config.txt"＃cloud-config cloud_final_modules：

  • [scripts-user、always]-// Content-Type：text / x-shellscript; charset = "us-ascii" MIME-Version：1.0 Content-Transfer-Encoding：7bit Content-Disposition：attachment; filename = "userdata.txt"＃！/ bin / bash chown root：root / home chmod 755 / home chmod 700 / home / ubuntu chmod 700 /home/ubuntu/.ssh chmod 600 /home/ubuntu/.ssh/authorized_keys ls -ld / home / home / ubuntu /home/ubuntu/.ssh /home/ubuntu/.ssh/authorized_keys chown ubuntu：ubuntu / home / ubuntu -R-// **
  1. 保存して、正しいpemキーを使用してインスタンスに接続します。

私の問題を解決しました*ubuntuをインスタンスのユーザー名に変更します

于 2022-01-25T08:40:53.977 に答える