解決策 1:
EBS ルート ボリュームを使用していることを願っています。もしそうなら、解決策はそれほど難しくありません。
基本的に、EBS ボリュームを別のインスタンスにアタッチして変更を加え、元のインスタンスに再アタッチします。
- 元のインスタンスを停止します (終了しないでください)
- EBS ボリュームを切り離す
- 別のインスタンスを起動
- 現在の EBS ボリュームを新しいインスタンスに接続する
- SSH で新しいインスタンスに接続し、EBS ボリュームをマウントして、必要な変更を加えます
- EBS ボリュームをアンマウントします (例:
umount -d /dev/xvdhまたはumount -d /dev/sdh) - 新しいインスタンスから EBS ボリュームを切り離し、ルート ボリュームとして接続します (例:
/dev/sda1) 古いインスタンスの - 古いインスタンスを開始
- すべてが機能している場合は、新しいインスタンスを終了してください
これが機能する理由は、新鮮な新しいインスタンスでは、適切なアクセス許可を持っているためです (ルート ボリュームは損なわれていません)。これにより、元のインスタンスの sudoers ファイルが編集可能な別のファイルになります。
残念ながら、インスタンス ストアのルート ボリュームがある場合、おそらく問題を解決することはできず、以前にバックアップとして作成した AMI に戻す必要があります。
解決策 2:
AMI ルート デバイスか EBS ルート デバイスかによって異なります。
それが AMI であり、ルート パスワードを持っておらず、AMI がルート SSH アクセスを構成していない場合は、何もできません。
EBS ルートの場合は、それを終了して、ボリュームを別のインスタンス (ルートではなく追加のディスクとして) にアタッチできます。その後、データにアクセスするか、sudoers ファイルを修正して、ボリュームを使用して新しいインスタンスを起動できます。