Решение этой ошибки стоило много времени, чтобы решить ее, и не смогли найти решение для нее в Интернете, но после некоторой помощи от поддержки AWS нам удалось ее решить, поэтому мы делимся ею, надеясь, что это поможет другим.
Предпосылка
Мы пытались подключиться к Ubuntu AWS EC2 через PuTTy (мы пробовали и другие альтернативы), но когда мы это делаем, то получаем сообщение об ошибке «Disconnected: No supported authentication methods available (server sent: publickey)»
Поиск проблемы
Эта ошибка может возникать при следующих обстоятельствах:
- Вы не подключаетесь к соответствующему имени пользователя для AMI, когда вы подключаете сеанс SSH с экземпляром EC2.
- Вы используете неправильный закрытый ключ, когда вы используете сеанс SSH с экземпляром EC2.
Если вы подключаетесь к соответствующему имени пользователя, убедитесь, что вы используете правильный закрытый ключ, выполнив следующие шаги:
- Войдите в свою учетную запись AWS и откройте консоль Amazon EC2.
- В навигационной панели выберите Экземпляры.
- Найдите экземпляр EC2, к которому вы хотите подключиться, используя SSH.
- В столбце «Имя ключа» проверьте имя закрытого ключа, который вы используете для подключения через SSH.
Если вы используете PuTTY:
Убедитесь, что закрытый ключ SSH соответствует закрытому ключу, который вы видите в столбце «Имя ключа» для вашего экземпляра EC2 в консоли. Если ваш экземпляр основан на ОС Ubuntu, имя пользователя по умолчанию должно быть ubuntu.
Убедитесь, что файл приватного ключа (.pem) преобразован в формат, распознанный PuTTY (.ppk). Дополнительные сведения см. В разделе Преобразование личного ключа с помощью PuTTYgen.
- проблема с каталогом, который содержит ключ ssh (/home/ubuntu)
В нашем случае мы случайно выполнили команду sudo chmod -R 777. для каталога EC2 «/home/ubuntu», поэтому это привело к отказу доступа к EC2, и неправильное разрешение было похоже на следующее:
Неправильная разрешающая способность EC2
Между тем, правильное разрешение должно быть таким:
Право доступа EC2
Чтобы решить эту проблему, нам пришлось создать экземпляр восстановления в том же AZ, что и поврежденный экземпляр (в случае выбора другого неправильного AZ вы не сможете использовать + прикреплять тома от подверженного воздействия экземпляра, который должен быть прикреплен + монтирован на экземпляр восстановления для работы над разрешениями).
- Создайте EC2 в одной и той же зоне доступности затронутого экземпляра
- Остановите затронутый экземпляр.
- Отсоедините том затронутого экземпляра
- Прикрепите том к новому экземпляру восстановления
- Подключитесь к экземпляру восстановления
- Смонтируйте том на экземпляре восстановления, как показано ниже.
sudo mkdir /mountpoint
cd ../
lsblk # to know where the new volume is attached, in my case "/dev/xvdf1"
sudo mount /dev/xvdf1/mountpoint # mount step
/dev/xvdf1 # this gave me permission denied
cd /mountpoint/var/log
ls
nano auth.log
Это покажет вам причину ошибки, которая является “Authentication refused: bad ownership or modes for file /home/ubuntu/.ssh/authorized_keys”
ls -l /mountpoint/home/ubuntu/.ssh/authorized_keys
sudo chmod 600 /mountpoint/home/ubuntu/.ssh/authorized_keys
чтобы убедиться, что разрешение было обновлено
ls -l /mountpoint/home/ubuntu/.ssh/authorized_keys
следующий шаг:
ls -ld /mountpoint//home/ubuntu/.ssh/
sudo chmod 700 /mountpoint/home/ubuntu/.ssh
ls -ld /mountpoint//home/ubuntu
sudo chmod 755 /mountpoint/home/ubuntu/
ls -ld /mountpoint//home/ubuntu
ls -ld /mountpoint//home/
Следующее:
- Остановите экземпляр восстановления
- Отсоедините том удаляемого экземпляра от восстановления
- Прикрепите том к затронутому экземпляру
-
- Запустите экземпляр
- Подключитесь к экземпляру через PuTTY
Вуаля, теперь вы можете подключаться правильно без ошибок.