Украденный пароль или один приватный ключ больше не должны открывать SSH-доступ к серверу. Двухфакторная аутентификация SSH по TOTP добавляет второй шаг: после ключа или пароля администратор вводит одноразовый код из приложения-аутентификатора.
Схема работает локально. PAM-модуль pam_google_authenticator проверяет код на сервере, а секрет пользователя лежит в файле .google_authenticator в домашнем каталоге. Важно, чтобы файл принадлежал самому пользователю и был закрыт правами 0600, иначе модуль может отказаться его читать.
Для входа по ключу и TOTP в sshd_config используют связку AuthenticationMethods publickey,keyboard-interactive. Запятая здесь означает «оба фактора подряд»: сначала ключ, потом интерактивная проверка кода. Перед перезапуском sshd обязательно проверяют конфиг командой sshd -t и держат вторую открытую root-сессию.
Главный риск внедрения не в самом TOTP, а в самоблокировке. Поэтому раскатку начинают с одного тестового пользователя, заранее сохраняют резервные коды, проверяют доступ через консоль провайдера или IPMI/KVM и только потом переносят настройку на администраторов.
Для автоматизации нужны исключения. Ansible, бэкапы и мониторинг обычно входят по ключам без TOTP через отдельные service-аккаунты и блок Match User. Временный nullok можно использовать только на этапе миграции, с датой снятия в задаче, иначе часть учетных записей останется формально защищенной, но фактически без второго фактора.
Еще одна обязательная проверка: время. TOTP зависит от синхронизации часов, поэтому NTP на сервере и телефоне администратора должен работать стабильно. Если время уехало, правильный код будет отклонен.
Практичный порядок такой: включить модуль PAM, настроить один тестовый аккаунт, проверить вход в отдельной сессии, описать исключения для автоматизации, убрать временный nullok и только после этого масштабировать настройку на остальные серверы.