2FA для SSH через Google PAM

Мужчина держит смартфон.

Быстрые ссылки

Нужно ли это вообще?
Как включить двухфакторную аутентификацию для SSH
Настройка SSH для работы с Google PAM
Добавление доступа для служебных аккаунтов

Нужно ли это вообще?

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

Тем не менее 2FA для SSH имеет смысл в некоторых ситуациях:

Кража рабочего ноутбука с незашифрованным доступом к приватному ключу — 2FA добавит барьер.
Agent forwarding: при форвардинге SSH‑агента на публичный сервер уязвимость появляется, потому что скомпрометированный публичный хост может подписывать запросы от вашего имени. 2FA сокращает риск эскалации привилегий.
Требования комплаенса или внутренние политики безопасности, требующие двух факторов для удалённого доступа.

Важно: 2FA для SSH — это дополнительный инструмент, а не замена правильной защиты приватных ключей, шифрования диска и управления доступом.

Когда 2FA для SSH неэффективна

Если приватный ключ хранится без шифрования и к нему есть физический/программный доступ — 2FA может быть обойдена в зависимости от конфигурации.
Если вы активно используете автоматизированные службы, ожидающие безпарольного доступа (cron, CI), 2FA усложнит работу без корректной настройки исключений.
При неправильной конфигурации PAM и sshd можно случайно заблокировать доступ всем пользователям.

Как включить двухфакторную аутентификацию для SSH

Используем реализацию Google PAM, совместимую с Authy и Google Authenticator.

Установите пакет из менеджера пакетов дистрибутива:

sudo apt-get install libpam-google-authenticator

Запустите инициализацию для каждого пользователя, у которого хотите включить 2FA:

google-authenticator

При первой опции согласитесь на использование временных токенов (Time‑based). Терминал выведет большой QR‑код; откройте приложение TOTP (Google Authenticator, Authy и т. п.) и отсканируйте код напрямую с терминала — не со скриншота, если можете.

Огромный QR‑код в терминале.

Сделайте резервные копии секретного ключа и экстренных кодов (scratch codes). Они нужны для восстановления доступа, если вы потеряете устройство с приложением 2FA. Файл конфигурации создаётся как ~/.google-authenticator.

Рекомендуемые ответы на вопросы мастера настройки:

Да — обновить конфигурацию.
Да — запретить повторное использование одного и того же токена (each token can only be used once).
Нет — не расширять окно валидности кодов (лишняя гибкость снижает безопасность).
Да — включить rate limiting (блокирование атакующих после нескольких попыток).

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

Настройка PAM для работы с Google Authenticator

Откройте файл PAM для sshd: /etc/pam.d/sshd и добавьте в конец следующую строку:

auth required pam_google_authenticator.so nullok

Параметр nullok делает 2FA опциональной — в этот период вы тестируете настройку. Полезно оставить nullok пока не убедитесь, что всё работает.

Далее найдите строку, которая включает общую аутентификацию, и закомментируйте её, чтобы отключить вход по паролю (это предотвращает падение к паролям как запасному варианту):

# Standard Un*x authentication.

#@include common-auth

Обратите внимание: в некоторых дистрибутивах строка включения @include common-auth находится внутри файла и может выглядеть по‑другому. Цель — убедиться, что аутентификация по паролю отключена, если вы не хотите её поддерживать.

Настройка sshd

Откройте /etc/ssh/sshd_config. Включите challenge‑response аутентификацию (используется PAM):

# Change to yes to enable challenge-response passwords (beware issues with

ChallengeResponseAuthentication yes

По умолчанию SSH пропускает 2FA, если подключение прошло по ключу. Чтобы требовать одновременно публичный ключ и интерактивный ввод 2FA, добавьте в конец sshd_config:

AuthenticationMethods publickey,keyboard-interactive

Это заставит SSH требовать сначала корректный публичный ключ, затем вызовет PAM для ввода кода из приложения.

Перезапустите службу sshd:

sudo systemctl restart sshd.service

Тестирование: не закрывайте текущую сессию — откройте новую вкладку терминала и попробуйте подключиться. SSH должен запросить проверочный код. Если что‑то не работает, вы всё ещё можете оставить поле пустым (в тестовой конфигурации) или использовать экстренные коды из ~/.google-authenticator.

Когда убедитесь, что всё стабильно, удалите nullok из /etc/pam.d/sshd, чтобы сделать 2FA обязательной.

Добавление доступа для служебных аккаунтов

Для автоматизированных сервисов (rsync, backup, CI‑агенты) двухфактор может мешать. Обычно для таких учётных записей требуется исключение.

Создайте группу для служебных аккаунтов:

sudo groupadd service

Создайте/перенесите пользователя в группу:

sudo useradd 

sudo usermod -a -G service

В /etc/pam.d/sshd добавьте правило до проверки Google Authenticator, чтобы пропускать пользователей из группы service:

auth [success=done default=ignore] pam_succeed_if.so user ingroup service

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

Пошаговая методология внедрения (mini‑methodology)

Оценка потребностей: определите, какие пользователи/сервисы требуют 2FA и какие — нет.
Подготовка: резервное копирование ключей, создание группы service для исключений.
Тестовая настройка: включите PAM с nullok и отрегулируйте sshd_config в тестовой среде.
Тестирование: проверка входа из новых сессий, проверка отказов, проверка служебных аккаунтов.
Живой запуск: удалить nullok, задокументировать процесс восстановления.
Мониторинг: логирование неудачных попыток и периодические проверки конфигурации.

Чек‑лист для ролей

Администратор:
- Установил libpam-google-authenticator на целевых машинах.
- Настроил PAM и sshd, выполнил тестовые подключения.
- Настроил исключения для служебных аккаунтов и зафиксировал доступы.
- Документировал процесс восстановления и ротации кодов.
Разработчик/Обычный пользователь:
- Сгенерировал секрет и добавил аккаунт в приложение TOTP.
- Сохранил экстренные коды и секрет в защищённом хранилище.
- Протестировал вход из нового терминала.
DevOps/CI инженер:
- Для автоматизации использует ключи в сочетании со специальными служебными аккаунтами.
- Настроил мониторинг и оповещения при неудачных попытках входа.

План восстановления при потере доступа

Попробуйте экстренные scratch коды, показанные при настройке google-authenticator.
Если у вас есть доступ к другому аккаунту с sudo, скопируйте файл ~/.google-authenticator из резервной копии или пересоздайте секрет вручную.
Если ни один метод не помогает, восстановите доступ через консоль провайдера (для облачных серверов) или через локальный доступ к машине и временно откорректируйте /etc/pam.d/sshd (например, добавить nullok или закомментировать строку с pam_google_authenticator) для восстановления доступа, затем снова правильно включите 2FA и проконтролируйте логи.

Важно: любые изменения PAM и sshd делайте через сессию с root‑доступом и оставляйте одну живую сессию для отката.

Тесты и критерии приёмки

Критерии приёмки:

Авторизация по публичному ключу + ввод TOTP кода успешны для тестовой учётной записи.
Служебные учётные записи без 2FA успешно проходят аутентификацию.
При трёх неверных кодах срабатывает rate limiting.
Логи /var/log/auth.log или journalctl содержат записи об успешных и неудачных попытках с причинами.

Тестовые сценарии:

Успешный вход: ключ + корректный код.
Ошибка кода: ключ + неверный код (проверить блокировку/лимит).
Попытка входа с учётной записи в группе service — должна пройти без запроса кода.
Потеря устройства: доступ посредством scratch кодов.

Риски и способы смягчения

Риск блокировки всех администраторов: держите хотя бы одного пользователя с восстановительным методом (например, отдельный аккаунт с доступом через консоль облака).
Риск утечки секретов: храните секреты и scratch коды в зашифрованном хранилище (vault, менеджер паролей).
Риск ошибок конфигурации PAM: тестируйте в среде, имейте открытую админ‑сессию для отката.

Альтернативные подходы

Удостоверяющая печать по аппаратному ключу (U2F/WebAuthn) — более безопасна против фишинга, но поддержка в SSH требует дополнительных настроек и серверных модулей.
Сертификаты SSH (OpenSSH CA) — позволяют централизованно управлять сроком действия и отзывом ключей.
VPN с MFA перед доступом к SSH — ограничивает число входов и переносит 2FA на уровень сетевого доступа.

Ментальная модель

Думайте о 2FA для SSH как о «второй двери»: если приватный ключ — это ключ от входной двери вашего дома, то TOTP — это кодовый замок на второй двери внутри. Он не заменяет первый ключ, но усложняет атаку, когда первый ключ украден.

Безопасность и конфиденциальность

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

Краткое резюме

Двухфакторная аутентификация для SSH через libpam-google-authenticator даёт дополнительный уровень защиты и решает специфические риски, такие как агент‑форвардинг и кража устройств. Внедряйте 2FA постепенно: тестируйте с nullok, документируйте процедуры восстановления, создавайте исключения для автоматизированных сервисов и следите за логами.