Почему SSH показывает PasswordAuthentication yes и как это исправить на Ubuntu 24.04 VPS

Вступление

После базовой настройки SSH многие ожидают, что сервер сразу перейдёт в режим входа только по ключу. Но на cloud VPS это работает не всегда. Даже если ты уже создал отдельного администратора, добавил SSH-ключ, запретил root-вход и прописал PasswordAuthentication no в своём hardening-файле, итоговая проверка может всё равно показывать:
passwordauthentication yes

Это означает, что парольный вход по SSH на сервере всё ещё разрешён. На cloud VPS частая причина в том, что cloud-init добавляет собственную SSH-настройку, а OpenSSH при чтении конфигурации обычно использует первое полученное значение параметра, а не “последнее из файлов”. Поэтому ранний файл вроде 50-cloud-init.conf с PasswordAuthentication yes может фактически сломать ожидаемую схему с 99-hardening.conf. В Ubuntu 24.04 это особенно важно учитывать ещё и потому, что openssh-server работает через systemd socket activation, а настройки из /etc/ssh/sshd_config и /etc/ssh/sshd_config.d/ читаются генератором systemd для настройки ssh.socket.

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

Когда нужен этот раздел

Этот шаг нужен, если после команды:

sudo sshd -T | egrep 'usepam|permitrootlogin|passwordauthentication|kbdinteractiveauthentication|pubkeyauthentication|allowusers|disableforwarding|x11forwarding|loglevel'

ты видишь в выводе строку:
passwordauthentication yes

Именно её и нужно исправить.

Что означает этот вывод

Если сервер показывает:
passwordauthentication yes

это значит:

• SSH всё ещё принимает парольный вход
• сервер ещё не переведён полностью в режим входа только по ключу
• hardening SSH на этом этапе ещё не завершён

Для боевого VPS это нужно исправить. Параметр ssh_pwauth в cloud-init как раз и отвечает за то, будет ли sshd настроен на приём парольной аутентификации.

Важно

Пока в effective-конфигурации SSH видно passwordauthentication yes, парольный вход остаётся активным.

Шаг 1. Проверяем, в каком файле включён парольный вход

Сначала нужно понять, откуда именно приходит эта настройка.

Открой терминал на сервере и выполни:

sudo grep -R -nH '^\s*PasswordAuthentication' /etc/ssh/sshd_config /etc/ssh/sshd_config.d/*.conf 2>/dev/null

Если на сервере есть конфликт, ты можешь увидеть примерно такой вывод:
/etc/ssh/sshd_config.d/50-cloud-init.conf:1:PasswordAuthentication yes
/etc/ssh/sshd_config.d/99-hardening.conf:3:PasswordAuthentication no

Это означает, что в одном SSH-файле парольный вход включён, а в другом выключен. Но здесь важно понимать главное: для OpenSSH обычно работает правило “first obtained value will be used”. Поэтому сам факт наличия PasswordAuthentication no в более позднем файле ещё не гарантирует, что итоговая effective-конфигурация реально выключила парольный вход.

Что проверить после шага

После этой команды ты должен точно понимать:

• в каком файле стоит PasswordAuthentication yes
• в каком файле стоит PasswordAuthentication no

Если у тебя есть строка с 50-cloud-init.conf, значит проблему, скорее всего, создаёт именно cloud-init. Это типичный сценарий для cloud-образов.

Ошибка новичка

Некоторые смотрят только в свой 99-hardening.conf и думают, что этого достаточно. Но SSH читает не один файл, а всю итоговую конфигурацию, включая дополнительные файлы из /etc/ssh/sshd_config.d/.

Шаг 2. Убираем конфликтующий SSH-файл cloud-init из активной конфигурации

Если ты увидел, что файл 50-cloud-init.conf включает парольный вход, не удаляй его сразу. Безопаснее убрать его из активной конфигурации через переименование.

Выполни:

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

После этого SSH больше не будет читать этот файл как активный конфиг, потому что он уже не заканчивается на .conf.

Что делает эта команда

Команда не удаляет файл навсегда, а просто меняет ему имя. Это удобно: при необходимости ты сможешь вернуть его обратно.

Что проверить после шага

Проверь, что активного файла с именем 50-cloud-init.conf больше нет:

ls -la /etc/ssh/sshd_config.d/

В списке должен быть файл:
50-cloud-init.conf.bak

а не 50-cloud-init.conf.

Важно

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

Шаг 3. Запрещаем cloud-init включать SSH-пароли

Теперь создадим отдельный файл настройки для cloud-init.

Открой новый файл:

sudo nano /etc/cloud/cloud.cfg.d/99-disable-ssh-password-auth.cfg

Вставь в него:

#cloud-config
ssh_pwauth: false

Сохрани файл.

Что означает ssh_pwauth: false

Эта настройка говорит cloud-init, что парольную аутентификацию по SSH включать не нужно. Документация cloud-init прямо описывает ssh_pwauth как параметр, который определяет, будет ли sshd настроен на приём парольной аутентификации.

Что проверить после шага

Проверь содержимое файла:

sudo cat /etc/cloud/cloud.cfg.d/99-disable-ssh-password-auth.cfg

Ты должен увидеть:
#cloud-config
ssh_pwauth: false

Ошибка новичка

Если убрать только 50-cloud-init.conf, но не задать ssh_pwauth: false, парольная аутентификация может вернуться позже при изменении cloud-конфигурации или пересоздании инстанса.

Шаг 4. Проверяем свой hardening-файл SSH

Теперь нужно убедиться, что твой основной hardening-файл действительно содержит правильные настройки.

Открой файл:

sudo nano /etc/ssh/sshd_config.d/99-hardening.conf

Приведи его к такому виду:

PermitRootLogin no
PubkeyAuthentication yes
PasswordAuthentication no
KbdInteractiveAuthentication no
UsePAM yes
PermitEmptyPasswords no

DisableForwarding yes
PermitTunnel no
PermitUserEnvironment no
X11Forwarding no

LoginGraceTime 30
MaxAuthTries 3
MaxSessions 4
MaxStartups 10:30:60

ClientAliveInterval 300
ClientAliveCountMax 2

LogLevel VERBOSE

AllowUsers your_admin_user

Замени your_admin_user на своего администратора, например:
AllowUsers slaoh

Что означает эта конфигурация

• PermitRootLogin no — запрещает вход по SSH под root
• PubkeyAuthentication yes — разрешает вход по ключу
• PasswordAuthentication no — запрещает SSH-пароли
• KbdInteractiveAuthentication no — отключает keyboard-interactive
• UsePAM yes — оставляет PAM включённым
• DisableForwarding yes — отключает forwarding
• PermitTunnel no — запрещает туннели
• PermitUserEnvironment no — запрещает пользовательское влияние через environment
• X11Forwarding no — отключает X11 forwarding
• AllowUsers ... — разрешает вход только нужному пользователю
• LogLevel VERBOSE — делает SSH-логи полезнее для проверки входа

Часть этих параметров — это уже твоя политика hardening, а не обязательные настройки Ubuntu по умолчанию. Но для сценария “боевой VPS с входом только по ключу” такая схема логична и последовательна. Повторю главное: здесь критичен именно итоговый результат через sshd -T, а не просто красивый файл на диске.

Что проверить после шага

Проверь содержимое файла:

sudo cat /etc/ssh/sshd_config.d/99-hardening.conf

И убедись, что там есть строка:
PasswordAuthentication no

Шаг 5. Проверяем синтаксис конфигурации SSH

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

Выполни:

sudo sshd -t

Если команда ничего не вывела, синтаксис в порядке.

Что проверить после шага

Если ошибок нет, ты просто вернёшься в приглашение терминала.

Если ошибка есть, SSH обычно покажет:

• имя файла
• номер строки
• причину проблемы

Важно

Нельзя перезапускать SSH вслепую после редактирования конфигов. Сначала всегда делай sudo sshd -t, иначе можно случайно отрезать себе доступ к серверу.

Шаг 6. Перезапускаем SSH и проверяем socket activation

Если синтаксис корректный, перезапусти SSH:

sudo systemctl restart ssh

После этого проверь состояние:

sudo systemctl status ssh --no-pager
sudo systemctl status ssh.socket --no-pager

Что проверить после шага

На Ubuntu 24.04 особенно важно проверить ssh.socket, потому что openssh-server использует systemd socket activation, а настройки из sshd_config и sshd_config.d/ участвуют в настройке ssh.socket. Именно поэтому после изменений нельзя ограничиваться проверкой только одной службы.

Ориентир здесь такой:

• ssh.socket должен быть активен и слушать
• sshd -t не должен показывать ошибок
• дальше итог нужно подтверждать через sshd -T

То есть главным доказательством правильной настройки считается не один только status, а итоговая effective-конфигурация.

Шаг 7. Проверяем итоговую effective-конфигурацию SSH

Теперь снова выполни итоговую проверку:

sudo sshd -T | egrep 'usepam|permitrootlogin|pubkeyauthentication|passwordauthentication|kbdinteractiveauthentication|x11forwarding|disableforwarding|loglevel|allowusers'

Правильный результат должен быть таким:
usepam yes
permitrootlogin no
pubkeyauthentication yes
passwordauthentication no
kbdinteractiveauthentication no
x11forwarding no
disableforwarding yes
loglevel VERBOSE
allowusers your_admin_user

Если у тебя вместо your_admin_user стоит slaoh, это нормально:
allowusers slaoh

Самая важная строка

В этом выводе тебя интересует в первую очередь: passwordauthentication no

Если ты видишь именно no, значит SSH действительно переведён в режим входа только по ключу. Именно effective-конфигурация здесь является главным критерием, потому что OpenSSH использует первое найденное значение параметра, а не просто “самый поздний файл”.

Что проверить после шага

Убедись, что в выводе одновременно есть:

• permitrootlogin no
• passwordauthentication no
• pubkeyauthentication yes
• allowusers your_admin_user

Если это так, значит SSH-hardening для этого этапа настроен правильно.

Шаг 8. Проверяем вход новым пользователем в отдельном окне

Перед тем как закрывать текущую SSH-сессию, обязательно открой новое окно терминала на своём компьютере и проверь вход под своим администратором.

Например:

ssh your_admin_user@your_server_ip

Или, если нужно явно указать ключ:

ssh -i ~/.ssh/id_ed25519 your_admin_user@your_server_ip

После входа на сервер выполни:

whoami
id
sudo -i
whoami

Правильный результат

Сначала ты должен увидеть:
your_admin_user

А после sudo -i:
root

Это означает, что схема работает правильно:

• прямой SSH-вход под root запрещён
• парольный вход по SSH запрещён
• вход по ключу под обычным администратором работает
• административные действия выполняются через sudo

Ошибка новичка

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

Итог

Если после команды sudo sshd -T ты видишь passwordauthentication yes, это значит, что где-то в активной SSH-конфигурации осталась другая настройка, включающая парольный вход. На cloud VPS частой причиной оказывается файл 50-cloud-init.conf, созданный cloud-init, а сама проблема усугубляется тем, что OpenSSH обычно использует первое полученное значение параметра. Поэтому правильная схема здесь такая: найти источник PasswordAuthentication yes, убрать конфликтующий 50-cloud-init.conf из активной конфигурации, зафиксировать ssh_pwauth: false через cloud-init, проверить свой 99-hardening.conf, затем перепроверить sshd -t, состояние ssh.socket и итоговую effective-конфигурацию через sshd -T. Если в финале сервер показывает passwordauthentication no, значит SSH действительно переведён в режим входа только по ключу.