Двухфакторную аутентификацию SSH на сервере: частые ошибки и решения

MAATRIX

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

Ошибка: код вообще не спрашивается

Вы всё настроили, перезапустили SSH, входите — а второго фактора нет, пускает как раньше. Причин обычно две. Первая: в /etc/ssh/sshd_config не включена интерактивная проверка. Без KbdInteractiveAuthentication yes и UsePAM yes демон просто не обращается к модулю, который спрашивает код. Проверьте обе строки и перезапустите сервис.

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

AuthenticationMethods publickey,keyboard-interactive

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

Ошибка: запер себя снаружи

Классическая беда — включили второй фактор, закрыли терминал, а войти обратно не можете: телефон не под рукой, резервные коды не сохранены, а конфиг требует TOTP жёстко. Сервер отвечает отказом на каждый вход.

Правильная профилактика — всегда держать вторую SSH-сессию открытой до конца настройки и обязательно сохранять резервные коды, которые выдаёт генератор, вне сервера. Если беда уже случилась, спасает аварийный доступ провайдера. Через панель управления или веб-консоль можно зайти в обход SSH и откатить изменения: временно вернуть в PAM опцию nullok или убрать строку подключения модуля. Именно поэтому хостинг с полноценной консолью восстановления — часть защиты. У MAATRIX такой доступ есть по умолчанию, так что даже полная блокировка SSH не оставит вас без сервера.

Ошибка: неверный код при каждой попытке

Приложение показывает код, вы вводите его точь-в-точь, а сервер отвечает «неверно». В девяти случаях из десяти виновато рассинхронизированное время. TOTP завязан на часы: если время на сервере ушло на минуту от времени телефона, коды перестают совпадать. Проверьте синхронизацию времени на сервере и включите NTP:

timedatectl
timedatectl set-ntp true

Убедитесь, что System clock synchronized: yes. Если время плыло, после синхронизации коды начнут приниматься сразу. На стороне телефона тоже включите автоматическое время. При генерации секрета имеет смысл разрешить небольшой допуск по сдвигу, чтобы мелкая рассинхронизация не ломала вход.

Реже причина в том, что вы отсканировали QR-код не того пользователя или пересоздали секрет, а телефон хранит старый. Тогда сотрите запись в приложении и отсканируйте свежий код заново.

Ошибка: nullok забыли убрать

На этапе внедрения опцию nullok в PAM ставят намеренно — чтобы пользователи без настроенного второго фактора могли войти, пока не пройдут генерацию. Ошибка в том, что про эту опцию забывают и оставляют навсегда. В результате любой аккаунт без файла секрета входит вообще без кода, и вся двухфакторность превращается в фикцию для тех, кто просто не настроился.

Когда вся команда прошла настройку и проверила вход, уберите nullok из строки в /etc/pam.d/sshd. С этого момента вход без второго фактора становится невозможным ни для кого. Перед этим убедитесь, что у каждого пользователя действительно есть файл ~/.google_authenticator, иначе снятие nullok заблокирует тех, кто не настроился.

Ошибка: сломался автоматический деплой и бэкапы

Частая неприятность после внедрения 2FA — перестают работать автоматические подключения: скрипты деплоя, бэкапы, мониторинг. Они не умеют вводить интерактивный код, поэтому упираются в запрос второго фактора и падают. Люди в панике начинают откатывать защиту целиком, хотя решение аккуратнее.

Автоматику выносят на отдельного пользователя и отдельный ключ, для которого второй фактор не требуется, но доступ жёстко ограничен: только нужные команды, только с нужных адресов. В PAM для таких случаев настраивают исключение по условию, а не отключают 2FA глобально. Так живые администраторы ходят с двумя факторами, а сервисные подключения работают по строго урезанному ключу. Это и безопаснее, и не ломает процессы.

Ошибка: второй фактор на root вместо обычного пользователя

Иногда 2FA настраивают прямо для root и потом удивляются странному поведению, особенно если параллельно запрещён прямой вход под root. Правильная схема — заходить под обычным пользователем со вторым фактором, а привилегии повышать через sudo уже внутри. Так вы не завязываете единственный вход на самый опасный аккаунт и не конфликтуете с политикой PermitRootLogin.

Если вы всё же настраивали второй фактор под root, а вход под ним запрещён ключом-настройкой демона, коды могут не спрашиваться или спрашиваться не там, где ждёте. Перенесите второй фактор на рабочего пользователя, проверьте, что он есть в sudoers, и входите под ним. Это чище и надёжнее с точки зрения разграничения прав.

Как убедиться, что 2FA работает правильно

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

Затем проверьте крайние случаи: вход с одним резервным кодом (он должен сработать один раз), синхронизацию времени, автозапуск сервисных подключений. Убедитесь, что аварийный доступ через панель провайдера у вас настроен и вы знаете, как им воспользоваться. Когда все эти сценарии проходят предсказуемо, двухфакторную аутентификацию SSH на сервере можно считать надёжно рабочей.

Частые вопросы