AuthenticationMethods

Синтаксис, значение по умолчанию и порядок проверки списков

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

AuthenticationMethods publickey,password publickey,keyboard-interactive

Эта строка требует ключ, а затем либо пароль, либо шаг keyboard-interactive. На каждом этапе предлагаются только методы, идущие следующими хотя бы в одном списке, поэтому пароль нельзя ввести раньше ключа. Доступны методы gssapi-with-mic, hostbased, keyboard-interactive, none, password и publickey. Keyboard-interactive можно привязать к механизму суффиксом, например keyboard-interactive:pam. Если указать publickey дважды, потребуются два разных ключа.

Руководство добавляет, что каждый перечисленный метод должен быть включён в конфигурации. Когда список не задан, sshd -T выводит authenticationmethods any, что видно в исходном коде servconf.c.

Ключ и второй шаг: publickey,keyboard-interactive

Типичный случай это ключ плюс одноразовый код. Включите нужные части, а затем потребуйте их по порядку:

PubkeyAuthentication yes
UsePAM yes
KbdInteractiveAuthentication yes
PasswordAuthentication no
AuthenticationMethods publickey,keyboard-interactive

Сначала проверяется ключ. Второй шаг это диалог PAM, поэтому код запрашивает модуль из стека PAM, например модуль Google Authenticator, описанный в статье про TOTP. Что именно спросят, решает стек. В Debian файл /etc/pam.d/sshd начинается с подключения common-auth, поэтому, если ничего не менять, может запрашиваться и системный пароль; это видно в шаблоне Debian.

При LogLevel VERBOSE sshd записывает первый шаг как "Partial publickey for" и имя пользователя, что подтверждает: ключ принят, а не хватает кода, как видно в исходном коде auth.c. О двух включающих переключателях читайте в статьях KbdInteractiveAuthentication и PubkeyAuthentication, а о полном порядке внедрения в руководстве по двухфакторной аутентификации SSH.

Риск блокировки и безопасная проверка

Именно в этой директиве опечатка стоит доступа к серверу. Классические ловушки: потребовать метод, который выключен, например keyboard-interactive при KbdInteractiveAuthentication no или password при PasswordAuthentication no. sshd отчасти вас страхует. При запуске и в sshd -t его исходный код останавливается с сообщением "AuthenticationMethods cannot be satisfied by enabled authentication methods", если ни один список выполнить нельзя, а при входе список с отключённым методом пропускается с записью в журнале. В комментарии в исходном коде отмечено, что блоки Match заранее проверить нельзя.

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

1. Держите одну сессию открытой и подготовьте консоль провайдера.
2. Отредактируйте файл и выполните sudo sshd -t.
3. Проверьте конкретное соединение командой sudo sshd -T -C user=deploy,addr=192.0.2.10,host=server | grep -i '^authenticationmethods '.
4. Перезагрузите службу и войдите из нового терминала.

Если что-то пошло не так, следуйте руководству по восстановлению доступа к SSH.

Блоки Match и место в усилении защиты

Руководство разрешает AuthenticationMethods внутри блоков Match, поэтому второй шаг можно требовать только там, где это важно, например для одной группы администраторов. Если ключевое слово встречается в нескольких подходящих блоках Match, по руководству применяется только первое, поэтому читайте результат через sshd -T -C:

Match Group sudo
    AuthenticationMethods publickey,keyboard-interactive

Выделите автоматизации отдельную учётную запись и ограниченный ключ, чтобы задаче не требовался код, и сочетайте правило с AllowUsers. Остальная база описана в статьях про двухфакторную аутентификацию, PasswordAuthentication no и MaxAuthTries.

По возможности выбирайте аппаратный ключ: почему, объясняет статья про FIDO2 и WebAuthn, а PubkeyAuthOptions verify-required может потребовать для ключей FIDO подтверждение пользователя, например PIN. Порядок работ описан в руководстве по усилению защиты SSH, а атаки, которые он ослабляет, разобраны в руководстве по защите от подбора паролей.

Связанные термины: sshd_config, Двухфакторная аутентификация, TOTP, PAM, PasswordAuthentication.