Как исправить ошибку аутентификации SSH
Проверка ключей и пароля — основополагающие элементы аутентификации с использованием SSH. Использование дополнительных проверок ключей доступа обеспечивает должный уровень безопасности, но иногда возникают неожиданные проблемы, например ошибка authentication failed. В данном материале рассмотрим способы устранения этой проблемы, проанализируем причины сбоев.
Ошибки: базовый случай
Если в терминале появилось сообщение «authentication failed», это означает, что процесс проверки подлинности пользователя не удался. Аутентификация — это процедура, которая требуется для подтверждения личности пользователя и предоставления доступа к системе. Например, для удаленного подключения к серверу по адресу может быть настроено SSH-соединение, которое требует прохождения аутентификации.
В файле конфигурации SSH определяется метод аутентификации. По умолчанию используется парольный метод, но можно также использовать аутентификацию с помощью ключевой пары SSH. В этом случае закрытая часть ключа хранится на компьютере пользователя, а открытая на сервере. Если при попытке установления соединения ключи совпадают, то доступ предоставляется. В противном случае появляется сообщение об ошибке, например, «authentication failed».
Однако причиной ошибки может быть не только несовпадение ключей, но и поврежденные файлы конфигурации или недостаточные права доступа.
Ошибки: использование пароля
«Authentication failed» сообщает о неудачной попытке проверки подлинности пользователя, необходимой для получения доступа к системе. Часто аутентификация требуется для удаленного подключения к серверу через SSH-соединение. Метод аутентификации, используемый по умолчанию, — парольный, но можно настроить аутентификацию с помощью ключевой пары SSH. При этом закрытая часть ключа хранится на компьютере пользователя, а открытая на сервере. Если ключи совпадают, то пользователь получает доступ, в противном случае появляется сообщение об ошибке, например, «authentication failed». Однако, несовпадение ключей не является единственной причиной ошибки — ее причинами также могут быть поврежденные файлы конфигурации или недостаточные права доступа.
Ошибки: ключи
При использовании SSH-подключений часто возникают проблемы, связанные с идентификационными ключами. Например, может возникнуть путаница при использовании нескольких ключей для подключения к разным хостам. Чтобы избежать таких проблем, следует использовать понятные имена файлов аутентификации.
Также возможна ошибка «Too many authentication failures for user», которая возникает, когда клиент SSH пытается подключиться к хосту со всеми доступными ключами, превышая максимальное количество разрешенных попыток. Чтобы исправить это, можно использовать опции IdentitiesOnly и IdentityFile.
Если при использовании ключей SSH возникает ошибка «Permission denied (publickey, password)», то это может быть связано с неправильно введенной парольной фразой. Если парольная фраза была потеряна, ее нельзя восстановить, и потребуется сгенерировать новую пару значений для Secure Shell.
Для более удобного использования опций IdentitiesOnly и IdentityFile можно установить их в конфигурационном файле SSH ~/.ssh/config. Это позволит SSH использовать только указанные идентификаторы при подключении к хостам.
Восстановление публичного ключа
Если вы потеряли открытую часть из пары ключей, не волнуйтесь, так как ее можно легко восстановить с помощью стандартных инструментов OpenSSH.
Для этого вы можете воспользоваться утилитой ssh-keygen. Просто откройте терминал и выполните следующую команду:
- ssh-keygen -y -f ~/.ssh/id_rsa
В этой команде замените ~/.ssh/id_rsa на путь к файлу вашего закрытого ключа. В результате вы получите открытую часть вашего ключа, которую затем можно добавить на сервер.
Если вы используете среду Windows, вы можете достичь того же результата с помощью утилиты PuTTYgen, которая входит в пакет PuTTY. Просто загрузите свой закрытый ключ в утилиту с помощью кнопки Load, а затем скопируйте открытый ключ, отображаемый в поле Public key for… (Открытый ключ для…).
Важно отметить, что закрытый ключ не может быть восстановлен из открытого ключа. Это сделано специально для обеспечения безопасности системы.
Ошибки конфигурации клиента
Иногда, проблема кроется в неправильной подготовке к соединению. Возможно, вы просто некорректно настроили порты, протоколы и учетные данные на вход. Проверьте форматы ключей, сертификатов, валидность данных для входа и порты, которые вы указываете во время использования клиентов.
Конфликт конфигурационного файла
Убедитесь, что настройки в файле /etc/ssh/sshd_config не противоречат друг другу. Например, если аутентификация по паролю отключена или вход root запрещен, могут возникнуть конфликты.
Обычный пример конфликта — когда параметр PasswordAuthentication установлен в yes, а параметр PermitRootLogin установлен в no или without-password. Это может привести к тому, что сервер не сможет аутентифицировать пользователей, и установит запрет на доступ всем.
Права доступа
OpenSSH — это безопасный протокол для удаленного доступа к серверам, который применяет строгие правила владения и разрешения для файлов. Для обеспечения безопасного доступа важно проверить и установить соответствующие разрешения как на стороне сервера, так и на стороне клиента.
На стороне сервера должны быть установлены следующие разрешения:
- Каталог ~/.ssh должен иметь разрешение 700.
- Директория ~/.ssh должна принадлежать текущему пользователю.
- Файл ~/.ssh/authorized_keys должен иметь разрешение 600.
- Файл ~/.ssh/authorized_keys должен принадлежать текущему пользователю.
Аналогично, на стороне клиента необходимо проверить следующие разрешения:
- Файл ~/.ssh/config должен иметь разрешение 600.
- Файлы ~/.ssh/id_* должны иметь разрешение 600.
Право собственности на эти файлы очень важно, поскольку попытка подключения от другой учетной записи пользователя без разрешения на чтение содержимого защищенных каталогов может привести к отказу в доступе. Обеспечение правильного владения и разрешений позволяет аутентификации проходить гладко и безопасно.
Кроме того, OpenSSH больше не поддерживает использование старых типов ключей, основанных на алгоритме цифровой подписи (DSA), для безопасных серверных соединений. Ключи, использующие алгоритм ssh-dss, считаются слишком слабыми для обеспечения надежной защиты.
Для пользователей со старыми ключами оптимальным решением является генерация и добавление новых ключей на основе более безопасных алгоритмов. Однако в качестве альтернативы можно изменить файл /etc/ssh/sshd_config и установить параметр PubkeyAcceptedKeyTypes на «+ssh-dss», чтобы продолжать использовать ключи на основе DSA. Этот подход несет свои риски.
Дополнительные параметры могут потребоваться на SSH-клиенте при подключении к устаревшим серверам, которые давно не обновлялись. Например, для подключения к хостам CentOS 6, поддержка которых закончилась в конце 2020 года, пользователи должны добавить параметр «-oHostKeyAlgorithms=+ssh-dss», чтобы решить любые проблемы.
Сторонние сервисы
Проблемы аутентификации могут возникать и при использовании сторонних сервисов. Например, при подключении к API возникает сообщение user authorization failed invalid session. Устранение такого сбоя в частном порядке невозможно, стоит написать в техническую поддержку.