Как исправить ошибку отказа в доступе SSH на EC2

Содержание

• Распространенные причины постоянных ошибок “Permission denied”
• Проверка и исправление проблем с именем пользователя
• Исправление прав домашней директории на EC2
• Конфигурация группы безопасности
• Дополнительные шаги по устранению неполадок
• Профилактические меры

Распространенные причины постоянных ошибок “Permission denied”

После исправления прав файла .pem с помощью chmod 600, ошибка сменяется с “UNPROTECTED PRIVATE KEY FILE” на “Permission denied (publickey)”, что указывает на то, что SSH-сервер отклоняет вашу попытку аутентификации. Это может произойти по нескольким причинам:

1. Неправильное имя пользователя: Разные AMI имеют разные имена пользователей по умолчанию
2. Неправильные права доступа к домашней директории на экземпляре EC2
3. Конфигурация группы безопасности, блокирующей доступ SSH
4. Несоответствие пары ключей между используемым ключом и ключом, связанным с экземпляром
5. Проблемы с сетевым подключением между вашим компьютером и экземпляром EC2

Согласно документации AWS, ошибка “Permission denied (publickey)” возникает, когда процесс аутентификации достигает SSH-сервера, но не удается из-за проблем с конфигурацией на стороне экземпляра.

Проверка и исправление проблем с именем пользователя

Одной из наиболее распространенных причин является использование неправильного имени пользователя для вашего типа AMI. Имена пользователей по умолчанию значительно различаются между разными дистрибутивами Linux:

Как объясняется в документации AWS, “Для AMI Ubuntu имя пользователя - ubuntu. Для AMI Oracle имя пользователя - ec2-user. Для AMI Bitnami имя пользователя - bitnami.”

Чтобы исправить это, проверьте тип вашего AMI и используйте правильное имя пользователя:

# Для экземпляров Ubuntu
ssh -i amazonec2.pem ubuntu@<public-dns>

# Для экземпляров Amazon Linux  
ssh -i amazonec2.pem ec2-user@<public-dns>

# Для экземпляров Bitnami
ssh -i amazonec2.pem bitnami@<public-dns>

Если вы не уверены, какое имя пользователя использовать, попробуйте сначала подключиться к пользователю root, так как многие AMI настроены на отображение правильного имени пользователя:

ssh -i amazonec2.pem root@<public-dns>

Как отмечено на Alestic.com, “Некоторые AMI настроены так, что ssh на root@ выводит сообщение с правильным именем пользователя и затем закрывает соединение.”

Исправление прав домашней директории на EC2

Даже при правильных правах доступа к файлу .pem и правильном имени пользователя вы все равно можете столкнуться с ошибкой “Permission denied (publickey)”, если права доступа к домашней директории или директории .ssh на экземпляре EC2 неверны.

Правильные права доступа должны быть:

• Директория /home: 755
• Директория /home/username: 700
• Директория /home/username/.ssh: 700
• Файл /home/username/.ssh/authorized_keys: 600

Если вы все еще можете получить доступ к экземпляру через другие средства (например, AWS Systems Manager Session Manager), вы можете исправить эти права доступа:

sudo chown root:root /home
sudo chmod 755 /home
sudo chown <username>:<username> /home/<username> -R
sudo chmod 700 /home/<username>
sudo chmod 700 /home/<username>/.ssh
sudo chmod 600 /home/<username>/.ssh/authorized_keys

Как показано в их скрипте cloud-init на AWS re:Post knowledge center, именно эти настройки прав доступа требуются для правильной аутентификации SSH.

Если вы полностью заблокированы и не можете получить доступ к экземпляру через другие средства, вам может потребоваться открепить корневой том и подключить его к временному экземпляру для исправления прав доступа, как описано во многих постах на Server Fault.

Конфигурация группы безопасности

Группа безопасности, действующая как брандмауэр для вашего экземпляра EC2, должна разрешать входящий трафик SSH. Даже при идеальной конфигурации SSH-ключа и пользователя вы получите ошибку “Permission denied (publickey)”, если группа безопасности блокирует порт 22.

Чтобы проверить и исправить это:

1. Перейдите в консоль AWS EC2
2. Выберите ваш экземпляр и нажмите на вкладку “Безопасность”
3. Нажмите на имя группы безопасности
4. Убедитесь, что есть правило входящего трафика, разрешающее:
   • Тип: SSH (TCP порт 22)
   • Источник: Ваш IP-адрес (0.0.0.0/0 разрешает весь трафик, но для безопасности используйте ваш конкретный IP)

Как указано в документации AWS, “Убедитесь, что есть правило, разрешающее трафик с вашего локального компьютера на порт 22 (SSH). Если ваша группа безопасности не имеет правила, разрешающего…”

Интересно, как отмечено на Stack Overflow, “Вы не можете получить ‘Permission denied (publickey)’, если правильно не настроили настройки брандмауэра (группы безопасности).” Это означает, что если вы получаете ошибку publickey, ваша группа безопасности на самом деле настроена правильно, но что-то другое не так.

Дополнительные шаги по устранению неполадок

Если базовые исправления не решают проблему, попробуйте эти дополнительные шаги по устранению неполадок:

Использование подробного вывода SSH

Запустите SSH с флагом -v для получения подробной отладочной информации:

ssh -v -i amazonec2.pem <username>@<public-dns>

Это покажет вам, где именно происходит сбой аутентификации.

Проверка связи пары ключей

Убедитесь, что файл .pem, который вы используете, действительно связан с экземпляром EC2. В консоли AWS перейдите к вашему экземпляру и проверьте, что “Имя пары ключей” соответствует имени вашего файла .pem.

Тестирование с новым экземпляром

Если возможно, запустите новый тестовый экземпляр с тем же типом AMI и свяжите вашу пару ключей. Это поможет определить, является ли проблема конфигурацией экземпляра или вашей локальной настройкой.

Проверка наличия нескольких файлов ключей

Убедитесь, что вы случайно не используете другой файл .pem, который не соответствует экземпляру. Используйте полный путь к вашему файлу .pem:

ssh -i /Users/mattroberts/amazonec2.pem <username>@<public-dns>

Проверка SSH-агента

На macOS SSH-агент может мешать. Попробуйте выполнить:

ssh-add -D
ssh-add amazonec2.pem

Затем попробуйте подключиться снова.

Профилактические меры

Чтобы избежать этих проблем в будущем:

1. Всегда используйте правильное имя пользователя для вашего типа AMI
2. Сразу устанавливайте правильные права доступа после загрузки файла .pem:
   bash

   chmod 600 ~/Downloads/your-key.pem
   

3. Создайте файл конфигурации SSH, чтобы не указывать ключ и пользователя каждый раз:
   Host your-ec2-instance
     HostName your-ec2-public-dns
     User ec2-user  # или ubuntu для Ubuntu
     IdentityFile ~/.ssh/your-key.pem
   

4. Регулярно проверяйте группы безопасности при запуске новых экземпляров
5. Храните резервную копию ваших файлов .pem в безопасном месте, так как AWS не может восстановить утерянные закрытые ключи

Систематически проверив эти потенциальные причины, вы должны иметь возможность устранить постоянную ошибку “Permission denied (publickey)” и успешно подключиться к вашему экземпляру EC2 по SSH.

Источники

1. AWS Knowledge Center - Устранение ошибок “Permission denied (publickey)” или “Authentication failed, permission denied”
2. AWS Documentation - Управление пользователями на экземплярах EC2
3. AWS Documentation - Устранение проблем с подключением к экземплярам
4. Stack Overflow - Permission denied (publickey) при SSH-доступе к экземпляру Amazon EC2
5. Alestic.com - Имена пользователей SSH по умолчанию для подключения к экземплярам EC2
6. Server Fault - Заблокирован из экземпляра EC2 ubuntu из-за прав /home
7. AWS re:Post - Устранение ошибок разрешений при доступе к экземпляру EC2

Заключение

Постоянная ошибка “Permission denied (publickey)” после исправления прав доступа к файлу .pem обычно возникает из-за проблем с конфигурацией имени пользователя, правами доступа к домашней директории на экземпляре EC2 или настройками группы безопасности. Систематически проверив эти области - начиная с правильного имени пользователя для вашего типа AMI, затем проверив права доступа к домашней директории и, наконец, подтвердив конфигурацию группы безопасности, - вы должны иметь возможность устранить проблемы с SSH-подключением. Всегда используйте подробный вывод SSH с флагом -v для детальной отладки и рассмотрите возможность создания файла конфигурации SSH для упрощения будущих подключений.