Двухфакторная аутентификация SSH: аппаратные ключи и TOTP без риска потерять доступ

Почему одного ключа недостаточно

Файл закрытого ключа можно скопировать незаметно. Вредоносное ПО на машине разработчика, незашифрованная резервная копия или утёкший образ диска дают атакующему рабочий вход без неудачных попыток, которые вы могли бы увидеть. Парольная фраза на ключе помогает, но защищает файл, а не вход. Второй фактор означает, что украденного файла самого по себе недостаточно. CISA утверждает, что пользователи, включившие MFA, значительно реже оказываются взломанными, и, что полезнее для выбора метода, что любая MFA лучше, чем её отсутствие, а устойчивая к фишингу MFA это стандарт, к которому стоит стремиться всем лидерам отрасли. Там же отмечено, что единственная широко доступная устойчивая к фишингу аутентификация это FIDO/WebAuthn.

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

Выбор второго фактора

Сравним оба варианта по тому, что важно для небольшого сервера:

• Ключ FIDO2 (ed25519-sk): аппаратная защита, требуется касание, не нужно вводить коды, не нужно дополнительное ПО на сервере. Нужен OpenSSH 8.2 или новее и физический ключ безопасности каждому администратору. Лучший выбор, если вы можете купить два ключа, один запасной.
• TOTP через PAM: работает с любым приложением-аутентификатором, не требует оборудования, подходит для старых систем. Добавляет на сервер модуль PAM и шаг настройки для каждого пользователя. Код могут выманить фишингом или передать в реальном времени.

Можно сочетать оба, но для одного-двух администраторов выберите один и сделайте его качественно. Что бы вы ни выбрали, оставьте вход по ключам первым фактором, а вход по паролю отключённым.

Вариант A: аппаратный ключ FIDO2

В OpenSSH 8.2 появилась поддержка аппаратных аутентификаторов FIDO/U2F. Согласно заметкам к релизу, устройства FIDO поддерживаются новыми типами открытых ключей ecdsa-sk и ed25519-sk через встроенный промежуточный слой, зависящий от libfido2. Сгенерируйте ключ на своей машине при подключённом ключе безопасности:

ssh-keygen -t ed25519-sk -O verify-required -C "admin-yubikey-1"

Опции объясняет руководство ssh-keygen. Аутентификаторы FIDO, как правило, требуют, чтобы пользователь подтверждал операции касанием. verify-required означает, что закрытый ключ должен требовать проверки пользователя для каждой подписи, и сейчас единственный поддерживаемый способ это PIN. Если добавить -O resident, дескриптор ключа хранится на самом аутентификаторе, для чего обычно сначала нужно задать PIN. Избегайте no-touch-required, который убирает проверку присутствия; sshd по умолчанию отклоняет такие подписи.

Скопируйте открытый ключ (id_ed25519_sk.pub) в ~/.ssh/authorized_keys на сервере. Чтобы сервер требовал проверку пользователя для ключей FIDO, задайте в sshd_config:

PubkeyAuthOptions verify-required

В руководстве по sshd_config сказано, что verify-required требует, чтобы подпись ключа FIDO подтверждала проверку пользователя, например через PIN, и что на другие типы ключей опция не влияет. Последнее важно: одна эта настройка не мешает войти с обычным ключом, который всё ещё в authorized_keys. Когда ваш ключ FIDO заработает, удалите обычные ключи администраторов. Зарегистрируйте второй аппаратный ключ как запасной и храните в надёжном месте.

Вариант B: TOTP через PAM

Модуль PAM Google Authenticator формирует коды на основе времени, которые умеет генерировать любое стандартное приложение-аутентификатор. Установите его (в Debian и Ubuntu пакет называется libpam-google-authenticator), затем каждый пользователь один раз запускает google-authenticator, чтобы создать секрет в домашнем каталоге и отсканировать QR-код. Сохраните аварийные коды, которые он выводит, в офлайн-месте.

В документации проекта строка PAM показана как auth required pam_google_authenticator.so. Опция nullok разрешает вход без кода тем, кто ещё не настроил его, что удобно при внедрении, но потом её нужно убрать. Модуль пытается компенсировать рассинхронизацию времени, а если код не подходит, в README советуют подождать 30 секунд (но не дольше), чтобы получить три разных кода. Держите часы сервера синхронизированными.

Затем велите sshd требовать ключ и после него код. В руководстве по sshd_config AuthenticationMethods определён как методы, которые должны быть успешно пройдены для предоставления доступа, с замечанием, что каждый указанный метод должен быть также явно включён. Поэтому включите keyboard-interactive и потребуйте оба:

KbdInteractiveAuthentication yes
UsePAM yes
PasswordAuthentication no
AuthenticationMethods publickey,keyboard-interactive

С запятой сначала проверяется ключ, затем код. В Debian и Ubuntu /etc/pam.d/sshd обычно подключает и системный парольный стек, поэтому закомментируйте там строку @include common-auth, если нужен только проверочный код, без дополнительного запроса пароля. Проверяйте каждое изменение так, как описано далее.

Внедрение без потери доступа

Изменение аутентификации единственное место, где опечатка стоит доступа к серверу. Каждый раз следуйте такому порядку:

1. Держите текущую сессию SSH открытой и подключите вторую.
2. Сделайте копию конфигурации: sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak. Проверьте и файлы в /etc/ssh/sshd_config.d/, потому что они могут переопределить вашу настройку.
3. Проверьте синтаксис командой sudo sshd -t и только потом перезагрузите конфигурацию: sudo systemctl reload ssh (в некоторых дистрибутивах юнит называется sshd).
4. С третьего терминала откройте совершенно новое подключение и убедитесь, что оно работает. Не закрывайте старые сессии, пока это не подтвердится.
5. Внедряйте по одному администратору. Для TOTP временно используйте nullok, затем уберите, когда все подключены.
6. Сохраните запасной путь: веб-консоль провайдера или режим восстановления, а также аварийные коды или запасной аппаратный ключ.

Задокументируйте, как подключается новый администратор и как вы отзываете доступ уходящего. Файл authorized_keys это список тех, кто может войти, поэтому регулярно проверяйте его; см. статью об authorized_keys.

Ограничения и с чем сочетать

Второй фактор защищает вход, а не сервер. Он не поможет, если уязвим какой-то сервис, если у атакующего уже есть сессия или если учётная запись администратора после входа может всё. Сочетайте его с остальной защитой: оставьте fail2ban и ограничения частоты для SSH, ограничьте круг входящих через AllowUsers и ограничьте возможности каждой учётной записи после входа, как описано в руководстве пользователи, sudo и минимальные привилегии.

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

Если после смены аутентификации вы не можете войти, используйте руководство потеряли доступ к VPS после смены SSH. Справка: TOTP (одноразовый пароль по времени), FIDO2 и WebAuthn (вход с аппаратным ключом) и PAM (подключаемые модули аутентификации).