Двухфакторная аутентификация (2FA)

Почему это важно для серверов

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

Второй фактор для SSH

Для SSH практичные варианты это аппаратный ключ FIDO2 (ed25519-sk) и одноразовый код по времени через PAM. Оба варианта и безопасный порядок внедрения, не лишающий вас доступа, описаны в нашем руководстве по двухфакторной аутентификации SSH.

Какие входы вокруг сервера требуют второго фактора

На странице CISA о многофакторной аутентификации факторы делятся на три вида: то, что вы знаете (PIN или пароль), то, что у вас есть (приложение для аутентификации или телефон), и то, чем вы являетесь (отпечаток пальца или скан лица). Настоящий второй фактор принадлежит другому виду, чем первый, поэтому пароль плюс ещё один запоминаемый секрет остаются одним видом. Для организаций CISA называет приоритетными удалённый доступ, почту и системы выставления счетов, и это хорошо ложится на VPS.

• SSH входы администраторов. Эту дверь атакующие проверяют постоянно, а как добавить фактор, описано в руководстве по двухфакторной аутентификации SSH.
• Аккаунт хостинга. Панель провайдера с веб-консолью, режимом восстановления или сбросом пароля это отдельный путь внутрь, который настройки sshd не контролируют. Защитите его вторым фактором тоже.
• Почтовый аккаунт. Сброс паролей провайдера и домена обычно приходит туда, поэтому тот, кто контролирует ящик, часто может перехватить всё остальное.
• Аккаунты биллинга и DNS. Их потеря может означать потерю сервера или домена, даже если никто не трогал SSH.

Защищайте их в таком порядке по степени риска и выбирайте аппаратный ключ FIDO там, где провайдер его поддерживает, ведь CISA называет FIDO/WebAuthn единственным широко доступным фишингоустойчивым способом.

Проверьте, что фактор действительно работает, и подготовьтесь к плохому дню

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

sudo sshd -T | grep -iE '^(authenticationmethods|pubkeyauthentication|passwordauthentication|kbdinteractiveauthentication) '

В руководстве sshd_config сказано, что AuthenticationMethods задаёт комбинации, которые пользователь должен пройти, а значение any возвращает поведение по умолчанию: достаточно одного метода. Если в выводе всё ещё any, второй фактор не требуется, что бы ни казалось по остальным настройкам. Затем проверьте новым подключением только с ключом и убедитесь, что его недостаточно.

Продумайте восстановление заранее:

1. Зарегистрируйте запасной аппаратный ключ или храните одноразовые резервные коды офлайн, отдельно от ноутбука.
2. Знайте, как попасть в консоль провайдера, и держите доступным второй фактор для этого аккаунта.
3. Запишите, как подключают нового администратора и как отключают ушедшего.
4. Дайте автоматизации собственные ограниченные ключи, потому что задача развёртывания не ответит на запрос, и никогда не делите аппаратный ключ человека.

Пересматривайте список подключённых людей по расписанию, так же как authorized_keys.

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