Вход на Linux-сервер с ключом FIDO2: настройка SSH и запасной доступ

MAATRIX · 17 октября 2026 · 8 мин чтения

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

OpenSSH поддерживает ключи безопасности FIDO. Для входа пользователь подключает устройство, а при соответствующих настройках подтверждает действие касанием и проверкой пользователя, например PIN. Это удобно для администраторов и разработчиков, которые регулярно работают с VPS.

Настроим такой вход на тестовом сервере. Главный принцип прост: сначала проверяется новый способ и запасной ключ, затем принимается решение об отключении старых способов. Обратный порядок превращает настройку безопасности в занятие по восстановлению доступа.

Проверьте совместимость всей цепочки

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

На рабочем компьютере посмотрите версию ssh -V и список типов через ssh -Q key. Наличие sk-ssh-ed25519@openssh.com или другого типа SK показывает возможность клиента работать с таким форматом, но ещё не проверяет USB-доступ и сам токен.

Сравните требования с руководством Yubico по FIDO2 и SSH и документацией производителя вашего устройства. Не все FIDO-ключи поддерживают Ed25519; в некоторых случаях используется ecdsa-sk.

Для начального стенда подходит MAATRIX Ba Lite с 1 vCPU и 2 GB памяти на поддерживаемой Ubuntu или Debian. Криптографическая подпись выполняется с участием устройства пользователя, поэтому покупать большой VPS ради одной этой функции не требуется.

Касание, PIN и пароль файла — разные вещи

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

Не называйте любое касание «двухфакторной авторизацией» без понимания фактической схемы. Важно, что именно проверяет устройство и что требует сервер. Если рабочая политика требует подтверждение пользователя, настройка должна обеспечивать это на стороне проверки, а не только в привычках администратора.

Учтите ограничения числа неверных попыток PIN. Не экспериментируйте с подбором на рабочем токене, если не знаете процедуру восстановления. Сброс устройства может удалить зарегистрированные ключи, после чего придётся заново настраивать доступ в сервисах.

Перед началом убедитесь, что аппаратный ключ работает в обычном пользовательском сеансе ОС. Запуск клиента от root ради доступа к USB иногда маскирует проблему прав и создаёт ненужную путаницу с файлами.

Создаём ключ на рабочем компьютере

Подключите устройство. Создайте отдельную пару для административного доступа:

ssh-keygen -t ed25519-sk \
  -O verify-required \
  -f ~/.ssh/id_work_sk \
  -C 'workstation hardware key'

Если устройство не поддерживает этот алгоритм, после проверки его документации используйте совместимый вариант, например ecdsa-sk. Не снижайте требования подтверждения только ради того, чтобы команда перестала задавать вопросы.

Во время создания система может запросить PIN и касание. Сохраните файл под новым именем, не перезаписывая единственный рабочий ключ. Задайте парольную фразу, если это соответствует вашей схеме хранения и использования.

После завершения появятся локальный файл ключа и публичная часть с расширением .pub. У FIDO-ключа локальный файл содержит необходимые данные для обращения к устройству; это не обычная копия приватного материала, позволяющая подписывать без токена. Тем не менее файл нужно защищать и резервировать по выбранной схеме.

Подробности параметров описаны в руководстве ssh-keygen. Для первого испытания проще использовать обычный нерезидентный вариант, а переносимость resident keys рассмотреть отдельно.

Добавляем публичную часть на сервер

Оставьте текущую административную SSH-сессию открытой и проверьте доступ к консоли VPS. Затем добавьте публичный ключ в нужную учётную запись. Если система поддерживает ssh-copy-id, пример выглядит так:

ssh-copy-id -i ~/.ssh/id_work_sk.pub operator@server.example.com

Здесь operator и адрес сервера — учебные значения. Используйте существующий согласованный способ авторизации для добавления ключа. На сервер передаётся только публичная часть.

Если требуется обязательная проверка пользователя устройства, у соответствующей строки authorized_keys настройте поддерживаемую опцию verify-required. Она должна относиться именно к добавленному SK-ключу. Не изменяйте все строки файла поиском и заменой без проверки, особенно если там есть служебные ключи автоматизации.

Опции авторизованных ключей описаны в руководстве sshd. Убедитесь, что версия сервера понимает выбранные требования. Права каталога .ssh и файла должны запрещать запись посторонним пользователям.

Доказываем, что вход действительно аппаратный

Откройте новое окно терминала и выполните:

ssh -o IdentitiesOnly=yes \
  -i ~/.ssh/id_work_sk \
  operator@server.example.com

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

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

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

Не отключайте проверку ключа хоста. Аппаратная защита пользователя не заменяет проверку подлинности сервера, к которому он подключается.

Второй ключ готовят до потери первого

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

Не рассчитывайте скопировать аппаратный секрет обычной командой резервного копирования. Резервный токен — самостоятельная учётная возможность, которую нужно зарегистрировать заранее. Если потерян один ключ, второй позволяет войти и отозвать первый.

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

При потере устройства удалите его публичные ключи или отзовите соответствующие сертификаты на всех затронутых серверах. Отдельно оцените открытые сессии. Удаление строки из authorized_keys запрещает следующий вход, но не обязательно завершает уже установленное соединение.

Покупка второго ключа дешевле аварийного выходного

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

Для командного сервера добавьте в перечень доступа владельца каждого ключа и дату проверки. После замены устройства удаляйте старую строку из разрешённых ключей на всех машинах, где она использовалась. Сам факт покупки нового токена старый доступ не отзывает. Раз в несколько месяцев выполните вход запасным устройством и убедитесь, что помните необходимый PIN. Проверка занимает минуты; восстановление забытых деталей в момент отказа обычно требует гораздо более творческого подхода.

Нужны ли resident keys

Резидентный ключ позволяет восстановить необходимые локальные представления с устройства на другом совместимом компьютере. OpenSSH поддерживает создание с опцией resident и получение таких ключей через ssh-keygen -K.

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

Не начинайте миграцию всей команды с наиболее сложной схемы. Сначала проверьте один компьютер, один сервер и запасное устройство. Затем документируйте повторяемую процедуру для поддерживаемых ОС.

Для рабочих мест с виртуализацией, удалённым столом или USB-перенаправлением отдельно исследуйте поддержку токена. Устройство, которое работает в локальном браузере, не обязано автоматически быть доступным SSH-клиенту внутри другой среды.

Что аппаратный ключ не исправляет

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

Не включайте перенаправление SSH-агента по умолчанию. Для доступа через промежуточный сервер изучите ProxyJump и схему, где ключ остаётся на рабочем компьютере. Любое расширение доступа должно соответствовать реальной задаче.

Автоматическим заданиям обычно нужен отдельный способ аутентификации. Не отключайте требование касания для личного ключа только ради ночного развёртывания. Разделите доступ человека и машины, задайте каждому свои ограничения и процедуру отзыва.

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