Вы не можете применить пару ключей к работающему экземпляру. Вы можете использовать только новую пару ключей для запуска нового экземпляра.
Для восстановления, если это загрузочный AMI EBS, вы можете остановить его, сделать снимок тома. Создайте новый том на его основе. И сможете использовать его снова, чтобы запустить старый экземпляр, создать новый образ или восстановить данные.
Хотя данные при временном хранении будут потеряны.
Из-за популярности этого вопроса и ответа я хотел получить информацию в ссылке, которую Родни разместил в своем комментарии.
Кредит идет на Эрика Хаммонда за эту информацию .
Исправление файлов в корневом томе EBS экземпляра EC2
Вы можете просматривать и редактировать файлы на корневом томе EBS в экземпляре EC2, даже если вы находитесь в такой катастрофической ситуации, как:
- Вы потеряли ключ ssh или забыли пароль
- Вы допустили ошибку при редактировании файла / etc / sudoers и больше не можете получить root-доступ с помощью sudo, чтобы исправить это
- Ваш долго работающий экземпляр по какой-то причине зависает, с ним невозможно связаться, и он не загружается должным образом
- Вам необходимо восстановить файлы с экземпляра, но вы не можете получить к нему доступ
На физическом компьютере, сидящем за вашим столом, вы можете просто загрузить систему с компакт-диска или USB-накопителя, смонтировать жесткий диск, проверить и исправить файлы, а затем перезагрузить компьютер, чтобы вернуться к работе.
Однако удаленный экземпляр EC2 кажется удаленным и недоступным, когда вы находитесь в одной из этих ситуаций. К счастью, AWS предоставляет нам возможности и гибкость для возможности восстановления системы, подобной этой, при условии, что мы запускаем загрузочные экземпляры EBS, а не хранилище экземпляров.
Подход в EC2 несколько похож на физическое решение, но мы собираемся переместить и смонтировать неисправный «жесткий диск» (корневой том EBS) в другой экземпляр, исправить его, а затем переместить обратно.
В некоторых ситуациях может быть проще запустить новый экземпляр EC2 и выбросить плохой, но если вы действительно хотите исправить свои файлы, вот подход, который работал для многих:
Настроить
Укажите исходный экземпляр (A) и том, содержащий поврежденный корневой том EBS, с файлами, которые вы хотите просмотреть и отредактировать.
instance_a=i-XXXXXXXX
volume=$(ec2-describe-instances $instance_a |
egrep '^BLOCKDEVICE./dev/sda1' | cut -f3)
Определите второй экземпляр EC2 (B), который вы будете использовать для исправления файлов на исходном томе EBS. Этот экземпляр должен работать в той же зоне доступности, что и экземпляр A, чтобы к нему можно было подключить том EBS. Если у вас еще нет экземпляра, запустите временный.
instance_b=i-YYYYYYYY
Остановите поврежденный экземпляр A (ожидая, пока он полностью остановится), отсоедините корневой том EBS от экземпляра (ожидая его отсоединения), затем подключите том к экземпляру B на неиспользуемом устройстве.
ec2-stop-instances $instance_a
ec2-detach-volume $volume
ec2-attach-volume --instance $instance_b --device /dev/sdj $volume
ssh к экземпляру B и смонтируйте том, чтобы вы могли получить доступ к его файловой системе.
ssh ...instance b...
sudo mkdir -p 000 /vol-a
sudo mount /dev/sdj /vol-a
Почини это
На этом этапе вся корневая файловая система из экземпляра A доступна для просмотра и редактирования в / vol-a на экземпляре B. Например, вы можете:
- Поместите правильные ключи ssh в /vol-a/home/ubuntu/.ssh/authorized_keys
- Отредактируйте и исправьте / vol-a / etc / sudoers
- Найдите сообщения об ошибках в / vol-a / var / log / syslog
- Скопируйте важные файлы из / vol-a /…
Примечание. Идентификаторы в этих двух экземплярах могут не совпадать, поэтому будьте осторожны, если вы создаете, редактируете или копируете файлы, принадлежащие пользователям без полномочий root. Например, ваш пользователь mysql в экземпляре A может иметь тот же UID, что и ваш пользователь postfix в экземпляре B, что может вызвать проблемы, если вы укажете файлы с одним именем, а затем переместите том обратно на A.
Заворачивать
Когда вы закончите и будете довольны файлами в / vol-a, размонтируйте файловую систему (все еще в экземпляре-B):
sudo umount /vol-a
sudo rmdir /vol-a
Теперь вернитесь в свою систему с помощью ec2-api-tools, продолжайте перемещать том EBS обратно в его исходный экземпляр A и начните его снова:
ec2-detach-volume $volume
ec2-attach-volume --instance $instance_a --device /dev/sda1 $volume
ec2-start-instances $instance_a
Надеемся, что вы исправили проблему, экземпляр A работает просто отлично, и вы можете выполнить то, что изначально намеревались сделать. Если нет, возможно, вам придется продолжать повторять эти шаги, пока он не заработает.
Примечание. Если у вас был Elastic IP-адрес, назначенный экземпляру A, когда вы остановили его, вам нужно будет повторно связать его после повторного запуска.
Помните! Если ваш экземпляр B был временно запущен только для этого процесса, не забудьте прекратить его сейчас.
ssh-addдолжен делать то, что вам нужно.