Как найти и устранить причину, по которой на Ubuntu VPS сохраняется вход по паролю после его отключения

1. Проверка доступности входа по SSH-ключам

В рамках этой инструкции не рассматривается настройка SSH-ключей. Предполагается, что доступ по ключам у вас уже настроен и работает корректно. Перед внесением любых изменений необходимо убедиться, что вы можете подключаться к серверу именно по ключу, без использования пароля.

Если вход по ключам на данный момент не настроен или вы не уверены в его работоспособности, рекомендуется сначала выполнить первичную настройку сервера с аутентификацией по SSH-ключам, и только после этого переходить к выполнению следующих шагов.

2. Определение фактического применяемого статуса входа по паролю

На этом этапе важно понять не то, что записано в конфигурационных файлах, а то, какие параметры SSH реально использует в данный момент. Для этого выполните следующую команду:

sudo sshd -T | grep -i passwordauthentication

• sshd -T — выводит конфигурацию SSH-сервера так, как он её применяет после обработки всех файлов, директив Include и внутренних значений по умолчанию.
• | — (pipe) передаёт вывод предыдущей команды на вход следующей команде.
• grep -i passwordauthentication — отбирает строку, отвечающую за возможность входа по паролю, игнорируя регистр символов.

Если на этом шаге вы видите passwordauthentication yes, значит где-то в дополнительных конфигурационных файлах параметр включается повторно, и именно это мы будем искать на следующих шагах.

3. Проверка наличия дополнительных конфигурационных файлов SSH

sudo ls -a /etc/ssh/sshd_config.d/

• ls -a — стандартная утилита для вывода списка файлов и каталогов с опцией -a (all), которая указывает отображать все объекты, включая скрытые файлы.

Если каталог пуст, то причину нужно искать в основном конфиге или вне SSH.

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

На большинстве VPS вы увидите файл:

50-cloud-init.conf

Именно он чаще всего включает вход по паролю.

4. Просмотр содержимого файла 50-cloud-init.conf

sudo cat /etc/ssh/sshd_config.d/50-cloud-init.conf

• cat — выводит содержимое файла в терминал.

Чаще всего внутри присутствуют параметр PasswordAuthentication yes — это означает, что даже если в sshd_config вы указали PasswordAuthentication no, данная настройка будет переопределена при запуске SSH.

5. Отключение перебивающей конфигурации SSH

На этом этапе уже установлено, что вход по паролю включается дополнительным конфигурационным файлом, созданным cloud-init. Переопределение параметров через более поздние конфигурационные файлы в данном случае не даст результата, поэтому необходимо полностью исключить этот файл из обработки SSH.

Отключение файла 50-cloud-init.conf

Безопасно отключаем файл путём переименования, без удаления:

sudo mv /etc/ssh/sshd_config.d/50-cloud-init.conf /etc/ssh/sshd_config.d/50-cloud-init.conf.disabled

• mv — стандартная утилита для перемещения и переименования файлов. В данном случае используется именно для переименования файла внутри одного и того же каталога.

После переименования файл:

• перестаёт обрабатываться SSH, так как не имеет расширения .conf;
• остаётся в системе как индикатор того, что он был создан cloud-init;
• может быть легко восстановлен при необходимости.

6. Проверка конфигурации SSH на ошибки перед перезапуском сервиса

Перед тем как перезапускать SSH, обязательно проверьте синтаксис:

sudo sshd -t

• sshd -t — выполняет синтаксическую проверку файла конфигурации SSH-сервера в тестовом режиме.

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

7. Перезапуск SSH

После изменения настроек SSH необходимо перезапустить службу, чтобы новые параметры вступили в силу:

sudo service ssh restart

8. Повторная проверка применяемых настроек

Повторите проверку итоговых значений:

sudo sshd -T | grep -i passwordauthentication

Ожидаемый результат:

passwordauthentication no

9. Контрольная проверка входа

Я всегда проверяю результат после любых изменений. Опыт показал, что даже если в инструкции указано, что после правки sshd_config вход по паролю должен быть отключён, это не гарантирует, что сервер действительно перестал принимать пароль. Именно так в своё время я и столкнулся с перебивающей конфигурацией, из-за которой эта инструкция и появилась в моей базе знаний.

Поэтому после внесения изменений я рекомендую проверить результат:

1. Проверить вход по ключу;
2. Проверить запрет входа по паролю.