Двухфакторная аутентификация по SSH с TOTP

Зачем добавлять второй фактор к SSH, если уже используется ключ

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

Двухфакторная аутентификация по протоколу TOTP (Time-based One-Time Password, одноразовый пароль на основе времени) добавляет второй, независимый канал подтверждения личности — код, генерируемый отдельным приложением на телефоне пользователя, синхронизированным по общему секрету с сервером. Даже при компрометации файла закрытого ключа злоумышленнику дополнительно потребуется физический доступ к устройству с приложением-аутентификатором, что кардинально повышает порог для успешной атаки.

Реализация выполняется через модуль PAM (Pluggable Authentication Modules) с открытым исходным кодом google-authenticator, который встраивается в стандартный процесс аутентификации SSH-демона на уровне операционной системы, без изменения самого протокола SSH или необходимости в стороннем сервисе.

Установка и настройка PAM-модуля google-authenticator

Пакет с PAM-модулем и утилитой генерации секрета доступен в стандартных репозиториях большинства дистрибутивов Linux.

# Debian / Ubuntu
apt install libpam-google-authenticator

# RHEL / AlmaLinux / Rocky (требуется репозиторий EPEL)
dnf install epel-release
dnf install google-authenticator

После установки каждый пользователь, для которого требуется включить TOTP, самостоятельно (от своего имени, не от root) запускает интерактивную утилиту google-authenticator, которая сгенерирует уникальный секрет, покажет его в виде текста и QR-кода прямо в терминале, и задаст несколько вопросов о параметрах работы.

google-authenticator
# Do you want authentication tokens to be time-based (y/n) y
# ... QR-код и секретный ключ выводятся в терминал ...
# Your new secret key is: JBSWY3DPEHPK3PXP
# Your emergency scratch codes are:
#   12345678
#   87654321
#   ...

QR-код нужно отсканировать приложением-аутентификатором на телефоне (Google Authenticator, Authy, FreeOTP или любое другое, реализующее стандарт TOTP) сразу в момент генерации — секрет больше нигде не будет показан повторно в открытом виде. Утилита также сохраняет конфигурацию в файл ~/.google_authenticator в домашнем каталоге пользователя, включая резервные (scratch) коды одноразового использования на случай недоступности телефона.

Настройка PAM и sshd_config

После генерации секрета для пользователя нужно подключить модуль в цепочку PAM для службы SSH и явно указать sshd, что аутентификация теперь требует прохождения через PAM с использованием клавиатурно-интерактивного режима (keyboard-interactive), а не только стандартной проверки ключа или пароля.

# /etc/pam.d/sshd — добавить строку (обычно в начало файла)
auth required pam_google_authenticator.so

# /etc/ssh/sshd_config
ChallengeResponseAuthentication yes
UsePAM yes
AuthenticationMethods publickey,keyboard-interactive

Директива AuthenticationMethods со значением publickey,keyboard-interactive — ключевая часть конфигурации: она требует, чтобы клиент успешно прошёл оба метода аутентификации по порядку — сначала подтвердил владение приватным ключом, затем ввёл одноразовый код через клавиатурно-интерактивный запрос, реализованный PAM-модулем. Без этой директивы sshd по умолчанию считает успешным первый же успешно пройденный метод и не запросит второй фактор вовсе, что сводит на нет весь смысл настройки.

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

sshd -t
systemctl restart sshd

Проверка перед закрытием текущей сессии

Самая опасная ошибка при настройке двухфакторной аутентификации по SSH — протестировать новую конфигурацию, закрыв единственную открытую сессию, и обнаружить, что вход больше не работает из-за опечатки в sshd_config или PAM. На удалённом VPS без физического доступа к консоли это означает полную потерю доступа к серверу до момента, пока провайдер не предоставит альтернативный способ входа (веб-консоль, VNC, восстановительный режим).

Правильная последовательность действий: не закрывая текущую действующую сессию SSH, открыть второе, отдельное подключение в новом окне терминала и попробовать подключиться заново с учётом новых требований — ввести код TOTP при запросе. Только убедившись, что новая сессия успешно подключилась именно с проверкой второго фактора, можно закрыть первую, «страховочную» сессию.

ssh -v user@server.example.ru
# ... в логе видно последовательность методов аутентификации ...
# debug1: Next authentication method: keyboard-interactive
# Verification code:

Флаг -v при подключении полезен для диагностики: он показывает, какие методы аутентификации сервер предлагает и в каком порядке клиент их проходит, что помогает быстро определить, применилась ли директива AuthenticationMethods так, как задумано, или сервер по какой-то причине принял только один из двух факторов.

Резервные коды и план восстановления доступа

При первом запуске google-authenticator утилита выдаёт набор из нескольких (обычно пяти) резервных (scratch) кодов — каждый из них можно использовать вместо кода из приложения ровно один раз, после чего он становится недействительным. Эти коды нужно сохранить в надёжном месте, физически отдельном от телефона с приложением-аутентификатором и от самого сервера — например, в менеджере паролей или распечатанными и убранными в сейф, а не в текстовом файле на том же ноутбуке, с которого выполняется подключение к серверу.

Если резервные коды исчерпаны или изначально не были сохранены, а доступ к приложению-аутентификатору утрачен вместе с телефоном, единственный оставшийся путь восстановления — доступ к серверу в обход SSH: через консоль провайдера VPS (обычно доступна из панели управления как VNC-доступ или serial console), где можно временно закомментировать строку pam_google_authenticator.so в /etc/pam.d/sshd, перезапустить sshd, войти обычным способом и перегенерировать секрет заново.

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

Комбинация с ключевой аутентификацией: два независимых режима

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

# требовать либо ключ + TOTP, либо пароль + TOTP
AuthenticationMethods publickey,keyboard-interactive password,keyboard-interactive

На практике для VPS с реальной production-нагрузкой разумная конфигурация — полностью отключить вход по паролю (PasswordAuthentication no) и требовать связку «ключ плюс TOTP» для всех интерактивных пользователей. Использование пароля вместе с TOTP вместо ключа технически возможно, но объединяет два относительно слабых по отдельности механизма (пароль подвержен подбору и фишингу, а TOTP-код можно перехватить в реальном времени при удачной фишинговой странице, имитирующей ввод) в конфигурацию, которая всё равно уступает по надёжности связке ключа с TOTP.

Для служебных, полностью автоматизированных подключений (деплой-скрипты, системы CI/CD, резервное копирование по расписанию) интерактивный ввод одноразового кода несовместим с самой природой процесса — практическое решение — завести отдельного технического пользователя с ограниченными правами, доступ для которого разрешён только по ключу без второго фактора, и явно исключить этого пользователя или его группу из требования TOTP через блок Match в конфигурации sshd.

# /etc/ssh/sshd_config
Match User deploy
    AuthenticationMethods publickey

Плюсы и минусы TOTP по сравнению с одним лишь SSH-ключом

Главное преимущество добавления TOTP поверх ключа — защита от сценария, в котором сам файл закрытого ключа оказался скомпрометирован независимо от сервера: на рабочей станции администратора, через бэкдор в другом приложении или банальную кражу ноутбука без шифрования диска. Без второго фактора такой инцидент немедленно даёт полный доступ к серверу; с TOTP злоумышленнику дополнительно требуется физический доступ к отдельному устройству.

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

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

Синхронизация времени и окно допуска кода

Алгоритм TOTP генерирует новый код каждые 30 секунд на основе общего секрета и текущего времени, округлённого до этого интервала — что означает полную зависимость корректной проверки кода от того, насколько точно синхронизированы системные часы сервера и телефона с приложением-аутентификатором. Если часы сервера отстают или спешат больше чем на один-два интервала, PAM-модуль будет отклонять даже правильно введённые коды как недействительные, и разобраться в причине без понимания этого механизма может быть неочевидно.

timedatectl status
# System clock synchronized: yes
# NTP service: active

PAM-модуль google-authenticator по умолчанию допускает небольшое расхождение (окно в одну итерацию в каждую сторону), но полагаться на этот запас — плохая практика; правильное решение — обеспечить, что на сервере включена и работает служба синхронизации времени (chrony или systemd-timesyncd), как описано в отдельной статье про NTP и chrony, а не увеличивать окно допуска в конфигурации PAM, что фактически ослабляет защиту, продлевая время действия каждого кода.

На стороне телефона рассинхронизация часов встречается реже, поскольку современные мобильные операционные системы синхронизируют время автоматически по сети, но при ручном отключении автоматической синхронизации времени в настройках телефона (например, в целях приватности) TOTP-коды тоже начнут генерироваться со сдвигом и перестанут приниматься сервером.

TOTP в сравнении с аппаратными ключами и push-уведомлениями

TOTP — не единственный способ реализовать второй фактор для SSH, и стоит понимать его место среди альтернатив. Аппаратные ключи безопасности на основе стандарта FIDO2/WebAuthn (например, YubiKey) обеспечивают более сильную защиту от фишинга, поскольку криптографически привязывают подтверждение к конкретному серверу и не могут быть введены на поддельном сайте-двойнике, — TOTP-код, в отличие от них, теоретически можно перехватить и использовать в реальном времени, если пользователь введёт его на фишинговой странице, имитирующей приглашение к вводу.

На практике для доступа по SSH (в отличие от веб-форм входа) риск классического фишинга ощутимо ниже, поскольку подключение инициируется явной командой ssh к заранее известному адресу, а не переходом по присланной ссылке — это делает TOTP разумным практическим компромиссом между уровнем защиты и простотой внедрения: не требуется покупка и раздача физических ключей каждому администратору, а настройка укладывается в несколько команд на уже имеющемся оборудовании.

SMS-коды как второй фактор для SSH практически не используются и не стоят рассмотрения — эта схема требует стороннего сервиса отправки SMS, привязки к номеру телефона, и хорошо известна уязвимостью к атакам через подмену SIM-карты (SIM swapping); TOTP-приложение, работающее полностью офлайн на основе локально хранимого секрета, не зависит от доступности сотовой сети и не подвержено этому классу атак вовсе.

Логирование попыток входа и защита от подбора кода

Каждая попытка аутентификации через PAM-модуль google-authenticator записывается в системный журнал (обычно через syslog в /var/log/auth.log на Debian-семействе или journalctl -u sshd на системах с systemd), с указанием пользователя, времени и результата проверки — успешного или неуспешного. Регулярный просмотр этого журнала помогает вовремя заметить не только попытки подбора пароля, что актуально и без TOTP, но и аномальную частоту неудачных попыток ввода кода, которая может указывать либо на реальную атаку, либо на рассинхронизацию часов у легитимного пользователя.

journalctl -u sshd --since "1 hour ago" | grep -i "authentication fail"

Fail2ban, уже используемый на многих серверах для блокировки IP-адресов после серии неудачных попыток входа по паролю, точно так же реагирует на неудачные попытки, зафиксированные в журнале аутентификации, независимо от того, вызвана ли неудача неверным паролем, неверным TOTP-кодом или их комбинацией — включённая двухфакторная аутентификация не требует отдельной настройки fail2ban, она продолжает работать поверх обычного журнала аутентификации sshd, дополнительно снижая практическую эффективность автоматизированного перебора против сервера с TOTP.

Дополнительная мера, снижающая шум в журналах и общую поверхность атаки, — по возможности не привязывать доступ по SSH к порту 22 по умолчанию, а также ограничивать список IP-адресов, с которых разрешено подключение, через firewall, если круг администраторов работает с предсказуемого набора адресов — это не заменяет двухфакторную аутентификацию, но сокращает количество попыток аутентификации, которые вообще доходят до проверки TOTP-кода.