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

В октябре 2025 года Launchpad добавил поддержку аппаратно защищённых SSH-ключей ed25519-sk и ecdsa-sk для git+ssh и SFTP-загрузок в PPA. Новость короткая, но из неё следует полноценная практика внедрения: ключ нужно не просто выпустить, а провести через безопасную миграцию и проверить отказовые сценарии.

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

OpenSSH описывает FIDO-ключ как две связанные части. На компьютере находится key handle в файле приватного ключа, а внутри аутентификатора — уникальный секрет, который нельзя экспортировать. Во время входа устройство объединяет эти части и подписывает challenge. Копии файла с диска недостаточно: нужен сам токен.

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

Для начала OpenSSH и Launchpad предлагают ed25519-sk:

ssh-keygen -t ed25519-sk -C "engineer@example.com"

Тип ecdsa-sk стоит оставить для окружений, где совместимость с ed25519-sk ещё не подтверждена. Не выбирайте алгоритм по памяти: проверьте версии клиентского OpenSSH, серверов, bastion-хостов, Git-платформ и используемых агентов. Поддержка ключа на ноутбуке бесполезна, если критическая точка входа отклоняет его формат.

Resident key — удобство с другой моделью риска

Обычный FIDO SSH-ключ зависит от двух предметов: токена и файла key handle на компьютере. Resident key сохраняет handle на самом FIDO2-аутентификаторе. Такой ключ легче переносить между рабочими станциями и восстанавливать с устройства.

Создание resident key выглядит так:

ssh-keygen -t ed25519-sk -O resident -C "engineer@example.com"

OpenSSH предупреждает о компромиссе: когда обе части находятся на аутентификаторе, кража устройства повышает вероятность его успешного использования атакующим. Resident keys обычно требуют настроенного PIN, но PIN не отменяет необходимость быстрого отзыва публичного ключа после потери токена.

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

Начните с инвентаризации, а не с удаления старых ключей

Самая опасная часть миграции — не генерация, а момент отключения прежнего доступа. Сначала составьте список SSH-контуров: Git-хостинг, bastion, production-серверы, сетевое оборудование, SFTP, аварийные каналы и локальные инструменты, которые используют ssh-agent. Отдельно отметьте неинтерактивные процессы. CI job не должен зависеть от физического касания токена сотрудника.

Пилот проводите на обратимом маршруте:

  1. выпустите аппаратный ключ с понятным комментарием и сохраните его fingerprint в реестре доступа;
  2. добавьте новый публичный ключ рядом с действующим, не удаляя старый;
  3. проверьте реальный сценарий: клонирование и push, вход через bastion или SFTP — в зависимости от системы;
  4. отключите и снова подключите токен, чтобы убедиться, что клиент не использовал другой ключ из агента;
  5. проверьте вход с резервным токеном или другой утверждённый recovery-путь;
  6. только после успешной проверки отзовите прежний ключ.

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

Резервный токен — часть системы, а не личная рекомендация

Launchpad прямо советует держать отдельный backup key. Для команды этого недостаточно сформулировать как «купите второй токен». Нужны правила хранения и отзыва.

Основной и резервный токены должны иметь разные ключи и fingerprints. Тогда потерю одного устройства можно обработать точечно. Резерв не стоит постоянно носить вместе с основным: одна потерянная сумка уничтожит обе линии восстановления. При этом backup должен быть доступен по известной процедуре, иначе во время инцидента он окажется формальностью.

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

Для критического production-доступа заранее определите break-glass-механизм с отдельным контролем и аудитом. Он не должен превращаться в постоянный обход аппаратных ключей. Его задача — пережить утерю или несовместимость, а затем вернуть пользователя в обычный контур.

Не отключайте touch ради автоматизации

OpenSSH поддерживает опцию no-touch-required, но сервер по умолчанию отклоняет такие подписи, если администратор явно не разрешил их в authorized_keys. Это полезная безопасная граница. Если pipeline требует неинтерактивного SSH, не снимайте подтверждение присутствия с человеческого ключа только ради удобства скрипта.

Разделите идентичности. Человеку подходит аппаратный ключ с touch и, при необходимости, PIN. Автоматизации нужна машинная учётная запись с минимальными правами, ограниченным назначением, контролируемой ротацией и журналом использования. Тогда компрометация CI не превращает персональный ключ инженера в универсальный credential, а увольнение сотрудника не ломает pipeline.

FIDO2 не заменяет проверку удалённого сервера

Аппаратный токен защищает пользовательский секрет, но SSH по-прежнему должен подтвердить, к какому серверу подключается клиент. Для этого OpenSSH использует host keys и known_hosts. Настройка StrictHostKeyChecking определяет поведение при новом или изменившемся ключе сервера.

Не приучайте инженеров игнорировать предупреждение о смене host key. FIDO-токен может честно подписать вход на неверный узел, если пользователь не проверяет идентичность сервера. Управляемый список host keys, проверяемые fingerprints и аккуратная ротация серверных ключей остаются отдельным обязательным слоем.

Ограничения, которые нужно принять заранее

Аппаратный ключ добавляет физическую зависимость. Токен можно забыть, сломать или потерять; USB и NFC могут быть недоступны в конкретной рабочей среде; resident key меняет последствия кражи. Старые клиенты и промежуточные SSH-реализации способны не поддержать *-sk.

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

Главная практика проста: сначала добавьте аппаратный ключ как вторую проверяемую линию доступа, испытайте обычный и аварийный сценарии, затем удаляйте старый credential. FIDO2 снижает ценность украденного файла, но надёжность всей системы создают миграция, резервирование, отзыв и проверка host key.

Источник и лицензия

  • Автор: Finn Gärtner (finnrg).
  • Организация и корпоративный блог: Launchpad Blog, Canonical Ltd.
  • Исходная статья: Support for FIDO2 SSH Keys, 27 октября 2025 года.
  • Лицензия исходного материала: Creative Commons Attribution 2.0 UK: England & Wales.
  • Это самостоятельная русская адаптация: исходный материал переведён, сокращён и редакционно переработан для DevOps/SRE/Platform-аудитории; команды и ограничения сверены с актуальной документацией OpenSSH, добавлены план миграции, recovery-процедуры и эксплуатационные границы. Canonical и автор исходной статьи не одобряли эту публикацию и не связаны с ней.