Спроба входу на сервер ESXi призводить до помилки "Немає підтримуваних методів автентифікації (сервер надіслано: відкритий ключ)"
Summary: Ця стаття містить детальний посібник із усунення проблем із SSH з точки зору ESXi. Однак концепції та рішення, які тут обговорюються, також застосовні до інших операційних систем на базі Linux, що робить цю інформацію цінною для ширшого спектру середовищ. ...
Symptoms
Спроба входу SSH до сервера ESXi призводить до помилки "Немає підтримуваних методів автентифікації (сервер надіслано: відкритий ключ)", як показано нижче:
При спробі входу з іншого сервера ESXi відображається така помилка:
Cause
Сервер відмовляється від сеансу SSH, оскільки параметр "challengeresponseauthentication" у файлі sshd_config встановлено на "no", а сервери неправильно налаштовані для аутентифікації (аутентифікація за відкритим і приватним ключем RSA).
В результаті спроба підключитися до сервера за допомогою Putty призводить до помилки "Немає підтримуваних методів аутентифікації доступно (сервер надіслано: відкритий ключ).
Аналогічна поведінка спостерігається, коли користувач намагається встановити SSH-з'єднання з іншого хоста ESXi. У цьому випадку користувач отримує помилку "Load key '/.ssh/id_rsa: error in libcrypto", але йому не пропонують ввести пароль, і з'єднання не вдається.
Якщо сервери не налаштовані належним чином для асиметричної автентифікації, але параметр «ChallengeResponseAuthentication» встановлено на «так», користувач отримує повідомлення про помилку, але потім йому пропонується ввести свій пароль. При правильному введенні пароля з'єднання успішно встановлюється.
Resolution
Підключіться до консолі цільового сервера за допомогою DCUI, а потім відредагуйте аутентифікацію challengeresponse на yes у файлі конфігурації /etc/ssh/sshd_config.
Аутентифікація ChallengeResponseAuthentication
Параметр ChallengeResponseAuthentication визначає, чи дозволена автентифікація за принципом «виклик-відповідь» для SSH-з'єднань. Якщо цей параметр увімкнено, сервер SSH вимагає, щоб клієнти відповіли на виклик, перш ніж дозволити їм пройти автентифікацію. Він увімкнений за замовчуванням у деяких реалізаціях SSH-сервера, але він може бути вимкнений з міркувань безпеки на деяких системах, наприклад, у Red Hat, як описано в статті Red Hat 336773.
ChallengeResponseAuthentication є застарілим псевдонімом для KbdInteractiveAuthentication. Посилання: OpenSSH: Примітки до випуску
Additional Information
Детальніше:
-
Комбінація налаштувань challengeresponseauthentication та passwordauthentication створює дещо інший запит:
Для ChallengeResponseAuthentication встановлено значення Ні, а для PasswordAuthentication встановлено значення Так:

challengeresponse автентифікацію встановлено на ні, а автентифікацію за паролем встановлено на yes, АБО обидва встановлені на yes:

Додаткові кроки з усунення несправностей:
-
На стороні клієнта використовуйте параметр -v у команді ssh, щоб вивести діагностичні повідомлення про прогрес у ssh. Кілька параметрів -v збільшують деталізацію (максимум дорівнює 3):

…

-
На цільовому сервері збільште рівень деталізації параметра LogLevel
, щоб отримати більше відомостей про невдалу спробу сеансу SSH:
LogLevel (Рівень журналу)
Визначає рівень деталізації, який використовується під час ведення журналу повідомлень з sshd(8).Можливі значення: QUIET, FATAL, ERROR, INFO, VERBOSE, DEBUG, DEBUG1, DEBUG2 і DEBUG3 За замовчуванням вказано INFO. DEBUG і DEBUG1 еквівалентні. DEBUG2 і DEBUG3 визначають вищі рівні виведення діагностики. Ведення журналу з рівнем DEBUG порушує конфіденційність користувачів і не рекомендується.
- Перегляньте auth.log /var/run/log/на цільовому сервері, щоб дізнатися більше про помилку.