Автоматизация развертывания 2FA для SSH через Ansible: инфраструктура безопасности как код

Внедрение двухфакторной аутентификации на SSH-серверах повышает безопасность, но превращается в рутину при масштабировании инфраструктуры. Развертывание на каждом хосте по отдельности требует времени и чревато ошибками. Готовое решение - Ansible-роль, которая централизованно устанавливает Google Authenticator, генерирует уникальные ключи для пользователей и настраивает PAM и SSH.

Этот подход превращает конфигурацию безопасности в повторяемый, документированный элемент инфраструктуры как код. Он сокращает человеческий фактор, обеспечивает единый стандарт и позволяет интегрировать процесс в CI/CD. Ниже представлен полный код роли и инструкции для немедленного использования.

Готовая Ansible-роль для автоматизации 2FA SSH: копируй и используй

Роль выполняет все необходимые шаги: установка зависимых пакетов, генерация TOTP-секретов, настройка PAM и SSH. Вы можете адаптировать её под свою инфраструктуру, указав целевые хосты и список пользователей.

Структура роли и ключевые файлы конфигурации

Роль имеет стандартную структуру Ansible. Основные файлы:

tasks/main.yml - последовательность задач.
templates/sshd_config.j2 и templates/sshd_pam.j2 - шаблоны конфигурационных файлов.
defaults/main.yml - переменные для настройки, например список пользователей.

Ключевые изменения, которые роль применяет:

В файл /etc/pam.d/sshd добавляется строка:

auth required pam_google_authenticator.so nullok

Параметр nullok разрешает вход без 2FA, если файл .google_authenticator отсутствует в домашнем каталоге пользователя. Это важно для аварийного доступа.

В файл /etc/ssh/sshd_config добавляются или изменяются параметры:

ChallengeResponseAuthentication yes
AuthenticationMethods publickey,keyboard-interactive

Порядок методов publickey,keyboard-interactive означает, что сначала проверяется SSH-ключ, затем запрашивается одноразовый код из приложения.

Быстрый старт: как запустить развертывание за 5 минут

Чтобы проверить работу роли на тестовом сервере:

Клонируйте репозиторий с ролью или скопируйте её структуру в свой проект Ansible.
Создайте inventory файл или определите переменные в playbook для указания целевых хостов и пользователей. Например, в defaults/main.yml задайте:
ssh_2fa_users: ['admin', 'deploy_user']
Запустите playbook, указав ваш inventory:
ansible-playbook -i hosts deploy_2fa.yml
После выполнения проверьте подключение к серверу с использованием SSH-ключа и одноразового кода из Google Authenticator.

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

Безопасное управление секретами и стратегия гарантированного отката

Самая критичная часть внедрения 2FA - управление секретными ключами и QR-кодами для пользователей. Их потеря или утечка сводит на нет всю безопасность. Также обязательна процедура отката на случай, если конфигурация заблокирует доступ.

Интеграция с HashiCorp Vault для динамической выдачи секретов

Хранение seed-ключей в виде переменных Ansible, даже защищённых Ansible Vault, не масштабируется для большого числа пользователей. Централизованное решение - интеграция с HashiCorp Vault.

Роль может быть расширена для работы с Vault:

Модуль hashivault в задачах Ansible генерирует секрет и записывает его в путь, например secret/ssh_2fa/{{ user }}.
Ключ и соответствующий QR-код хранятся в Vault, доступ к ним регулируется политиками.
Пользователь получает свой QR-код через безопасный веб-интерфейс или CLI Vault после развертывания.

Это даёт централизованное управление, аудит доступа и возможность автоматического ротации секретов.

Playbook для отката: как вернуть всё назад в случае проблем

Перед применением изменений роль создает резервные копии оригинальных файлов /etc/pam.d/sshd и /etc/ssh/sshd_config. Для отката используйте отдельный playbook rollback_2fa.yml.

Основные задачи playbook отката:

Восстановление оригинальных конфигураций PAM и SSH из backup.
Удаление файлов .google_authenticator из домашних каталогов указанных пользователей (опционально, с подтверждением через переменную).
Перезапуск службы sshd.

Важно помнить: откат конфигурации не удаляет знания ключа из приложения на телефоне пользователя. Если 2FA нужно полностью отключить для пользователя, следует удалить его файл секрета.

Для построения отказоустойчивой системы безопасности, включающей не только 2FA, но и модели авторизации, изучайте практическое руководство по аутентификации и авторизации.

Как работает решение: от установки пакетов до ввода кода пользователем

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

Установка пакета libpam-google-authenticator (или google-authenticator-libpam на RHEL/CentOS).
Для каждого пользователя из списка генерация уникального seed-ключа командой:
google-authenticator -t -d -f -r 3 -R 30 -w 3
Параметры задают тип TOTP (-t), отображение QR-кода (-d), запись в файл (-f), количество резервных кодов (-r 3), интервал времени (-R 30) и размер окна проверки (-w 3).
Настройка PAM: добавление строки auth required pam_google_authenticator.so nullok в файл /etc/pam.d/sshd.
Настройка SSH: установка ChallengeResponseAuthentication yes и AuthenticationMethods publickey,keyboard-interactive в sshd_config.
Перезапуск службы SSH: systemctl restart sshd или service ssh restart.
Действия пользователя: получение QR-кода или секретного ключа (например, через Vault), добавление учётной записи в приложение Google Authenticator или аналогичное, ввод одноразового кода при следующем SSH-подключении.

Детали настройки PAM и SSH: на что обратить внимание

Конфигурация PAM-модуля влияет на поведение аутентификации. Параметр nullok разрешает вход без второго фактора, если файл с ключом отсутствует. Это критично для создания аварийного метода доступа через отдельный учётную запись без 2FA.

Параметр SSH AuthenticationMethods определяет порядок и типы аутентификации. Вариант publickey,keyboard-interactive означает двухэтапный процесс: сначала проверяется SSH-ключ, затем выполняется challenge-response (ввод кода из приложения). Неправильный порядок, например keyboard-interactive,publickey, может привести к необходимости ввода кода даже при неудачной проверке ключа, что неудобно.

После изменения конфигураций обязателен перезапуск службы sshd. Для этого роль использует модуль service Ansible.

Проверка на совместимость: для каких систем решение точно работает

Роль была проверена на следующих дистрибутивах и версиях:

Ubuntu 20.04 LTS и 22.04 LTS
Debian 11 (Bullseye) и 12 (Bookworm)
CentOS/RHEL 8 и 9 (и их производные Rocky Linux, AlmaLinux)

Минимальная требуемая версия Ansible - 2.9. Версии OpenSSH должны поддерживать параметр AuthenticationMethods (обычно с 7.0+). PAM-модуль google-authenticator доступен в стандартных репозиториях этих дистрибутивов.

Перед применением в production рекомендуется запустить роль в dry-run режиме для проверки изменений:
ansible-playbook -i hosts deploy_2fa.yml --check

Решение проблем с SELinux и нестандартными конфигурациями

На системах с SELinux (RHEL, CentOS) могут возникнуть проблемы, потому что процесс google-authenticator пытается создать или прочитать файл .google_authenticator в домашнем каталоге пользователя, что может нарушать политики.

Решение:

Установить правильный контекст SELinux для этого файла:
semanage fcontext -a -t user_home_t "~/.google_authenticator"
restorecon -v ~/.google_authenticator
Проверить логи аудита SELinux на наличие ошибок:
ausearch -m avc -ts recent

Роль может включать эти команды как дополнительные задачи для целевых хостов с SELinux.

Для нестандартных установок, где бинарник google-authenticator или конфигурационные файлы находятся в других местах, можно переопределить переменные роли, например google_authenticator_bin_path.

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

Интеграция в CI/CD и управление пользователями после развертывания

После успешного развертывания система требует администрирования: добавление новых пользователей, сброс 2FA для утерянных устройств, управление резервными кодами.

Для добавления нового пользователя после первоначального развертывания:

Добавить его имя в переменную ssh_2fa_users в конфигурации роли или в отдельный playbook.
Запустить роль на целевых хостах. Для этого пользователя будет создан новый секретный ключ.
Обеспечить безопасную передачу QR-кода или секрета пользователю, например через HashiCorp Vault.

Для сброса 2FA пользователя (например, при утере телефона):

Удалить его файл .google_authenticator на сервере.
Запустить роль с этим пользователем в списке для генерации нового ключа.
Передать новый QR-код пользователю.

Резервные одноразовые коды генерируются при первоначальной настройке командой с параметром -f. Их следует передать пользователю безопасным способом и рекомендовать хранить отдельно от устройства с TOTP-приложением.

Интеграция роли в CI/CD позволяет сделать обновления безопасности частью автоматического процесса. Пример для GitLab CI/CD:

deploy_2fa:
  stage: deploy
  script:
    - ansible-playbook -i inventory/production deploy_2fa.yml
  only:
    - tags

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

Для управления всей инфраструктурой как код, включая сети, виртуальные машины и балансировщики нагрузки, рассмотрите готовый IaC стек для отказоустойчивого веб-приложения.

Если вашей команде требуется единый доступ к множеству моделей искусственного интеллекта для автоматизации различных задач, вы можете использовать агрегатор API, например AiTunnel. Он предоставляет единый интерфейс для более 200 моделей, включая GPT, Gemini и Claude, с оплатой в рублях и без необходимости VPN.