Ответ от службы поддержки aws:
Существует 3 метода, с помощью которых вы можете отменить изменения реестра. Прошу вас следовать последовательным методам, если текущий метод не работает.
Метод 1 - Подключение к реестру проблемного экземпляра из другого экземпляра в том же VPC и отмена изменений. (Вы можете временно запустить тестовый экземпляр в том же VPC, если у вас нет существующих экземпляров в том же VPC.)
1. Откройте редактор реестра из рабочего экземпляра, который находится в том же VPC, что и проблемный экземпляр.
2. Нажмите Файл-> Подключить сетевой реестр.
3. Введите полное доменное имя сервера и нажмите «ОК».
4. Введите учетные данные и нажмите ОК.
5. Теперь разверните куст Удаленного компьютера (проблемный экземпляр) и отмените изменения.
Метод 2 - Доступ к проблемному экземпляру с помощью TightVNC.
1. Убедитесь, что нерабочему экземпляру назначена роль IAM с политикой «AmazonEC2RoleforSSM», связанной с ролью IAM. Чтобы создать и присоединить роль IAM, см. Ссылку https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/iam-roles-for-amazon-ec2.html & https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/iam-roles-for-amazon-ec2.html#attach-iam-role
2. Теперь установите TightVNC на рабочем экземпляре, который находится в том же VPC и подсети. Ссылка для загрузки TightVNC MSI: https://tightvnc.com/download.php 3. Щелкните правой кнопкой мыши MSI> Свойства> На вкладке «Общие»> Убедитесь, что файл разблокирован, установив флажок «Разблокирован».
4. Теперь скопируйте MSI-файл и на проблемный экземпляр. Скопируйте MSI в C $ на проблемном экземпляре (\\ c $). Для простоты переименуйте MSI в TightVNC64.msi 5. Теперь перейдите к https://console.aws.amazon.com/systems-manager
6. На левой панели в разделе «Действия» нажмите «Выполнить команду».
7. Нажмите «Выполнить команду» и найдите документ команды с именем «AWS-RunPowerShellScript».
8. Выберите AWS-RunPowerShellScript и в разделе «Параметры команды» вставьте следующую команду:
Начать процесс
9. Прокрутите вниз и в разделе «Цели» выберите проблемный экземпляр.
10. В нижней части страницы нажмите «Выполнить».
11. Подождите, пока статус команды не станет успешным.
12. Запустите TightVNC Viewer на своем рабочем экземпляре и укажите IP / FQDN проблемного экземпляра, за которым следуют учетные данные, которые вы указали в команде на шаге 8.
13. Вы будете подключены к экземпляру и сможете вносить изменения в реестр.
Метод 3 (Метод потребует остановки и запуска экземпляра.)
1. Для отсоединения корневого тома от проблемного экземпляра и присоединения его к рабочему экземпляру просим вас посмотреть видео с 1:47 до 3:40 в следующей статье:
https://aws.amazon.com/premiumsupport/knowledge-center/ec2rescue-windows-troubleshoot/
2. Откройте Консоль управления диском (diskmgmt.msc) и щелкните правой кнопкой мыши диск, отображающий состояние в автономном режиме, и нажмите «Онлайн».
3. Когда диск подключен к сети, перейдите на «Мой компьютер» и запишите букву диска, который вы прикрепили.
4. Откройте редактор реестра и выберите HKLM.
5. Нажмите Файл и загрузить куст. Укажите любое имя, например. «Восстановление».
6. Разверните ключ «Восстановление» и отмените изменения, т. Е. Включите значение для шифра AES 128 \ 128 и хэшей SHA, SHA256, SHA384, MD5.
7. После того, как все изменения внесены, выберите ключ «Recovery» и нажмите «Файл» и «Разгрузить куст».
8. Откройте консоль управления дисками и переведите диск в автономный режим.
9. Теперь для повторного присоединения корневого тома к проблемному экземпляру, просим вас посмотреть видео с 08:02 до 9:28 по той же ссылке: https://aws.amazon.com/premiumsupport/knowledge-center/ec2rescue-windows-troubleshoot/
Кроме того, прежде всего вы должны убедиться, что ваш IP-адрес находится в диапазоне правил inbounds неисправного экземпляра.
в моем случае я сначала попытался использовать приложение amazon "app2rescue" для диагностического сбойного экземпляра, но оно не показало никакой пользы (показывало только несколько возможных проблем с брандмауэром, но это не связано с моей проблемой) .
Тогда я попробовал первый способ - но мне не удалось получить доступ к удаленному реестру (я предполагаю, что на целевой машине была отключена служба «Удаленный реестр»).
И наконец, я использовал третий метод, и он решил мою проблему. Во время этих операций я столкнулся только с одной проблемой - до сбоя я менял currentControlSet, и когда я подключал том к временному серверу, я пытался найти именно его, но обнаружил, что currentControlSet включен только тогда, когда этот реестр используется для текущей ОС (когда этот реестр работает), поэтому я нашел мои проблемные параметры (sha, md5 и т. д.) в controlSet001 вместо currentControlSet.