OpenSSH и FIDO-ключ: что остаётся в файле и зачем серверу подтверждение касанием
Аппаратные ecdsa-sk и ed25519-sk, resident credentials, PIN, агент и границы защиты удалённого SSH-доступа.
Аппаратный ключ не заменяет SSH целиком
Поддержка FIDO/U2F появилась в OpenSSH 8.2, выпущенном 14 февраля 2020 года. Она добавила типы ecdsa-sk и ed25519-sk и соответствующие варианты сертификатов. Это историческая точка появления механизма, а не дата сегодняшнего обновления. Такой ключ участвует в аутентификации пользователя внутри SSH, сохраняя обычную структуру соединения и серверную проверку открытого ключа.
Устройство выполняет необходимую криптографическую операцию и обычно требует явного действия пользователя. Ключ должен быть доступен в момент использования. Но поддержка алгоритмов и дополнительных возможностей зависит от authenticator: наличие FIDO не гарантирует одинакового набора опций у всех устройств. В частности, поддержка Ed25519 исторически менее распространена, чем ECDSA-P256. Поэтому название физического разъёма или похожий корпус не подтверждают совместимость с конкретным типом SSH-ключа. На фотографиях показаны определённые устройства, а не универсальный сертификат поддержки всех рассматриваемых режимов.
Локальный файл всё равно существует
В обычной FIDO-модели OpenSSH локальный private-key-файл содержит key handle — часть, необходимую для обращения к ключу устройства. Самостоятельно этот файл не позволяет воспроизвести аппаратную операцию без соответствующего authenticator. Поэтому выражение «закрытый ключ остаётся в устройстве» не означает отсутствия любых файлов идентичности на компьютере.
Resident-режим хранит key handle на самом authenticator. Это упрощает перенос между компьютерами: необходимую информацию можно получить с устройства. При этом не экспортируется исходный аппаратный секрет в виде обычного программного закрытого ключа. Упрощение переноса имеет и другую сторону: похищенное устройство содержит больше необходимых частей для использования credential. Документация ssh-keygen прямо связывает resident keys с дополнительным риском при краже и необходимостью подходящего PIN. Удобство восстановления локальной идентичности и возможность её применения посторонним — связанные свойства одного режима, а не два независимых переключателя.
Resident не означает синхронизируемую облачную копию: речь идёт о размещении handle в authenticator. Возможность получить его на другом компьютере зависит от поддержки устройства и подходящего клиента. Обычное копирование одного локального файла, получение resident identity и создание нового независимого credential являются тремя разными операциями с разными результатами.
Версия клиента — только одно условие
Руководство Yubico указывает OpenSSH 8.2 как исходное требование для аппаратных FIDO-ключей, 8.3 — для получения resident keys через ssh-keygen, 8.4 — для verify-required. Эти границы описывают появление возможностей, а не рекомендацию устанавливать старые выпуски. Фактическая поддержка зависит также от сборки с FIDO-компонентами.
Например, руководство отдельно различает системную поставку macOS и сборку с libfido2. Поэтому одинаковый номер OpenSSH в двух окружениях не гарантирует одинаковой работы hardware-backed credentials. К выбору типа добавляются возможности устройства и его firmware. Ошибка при создании ed25519-sk не доказывает, что устройство вообще непригодно для любой FIDO-аутентификации: может отличаться набор алгоритмов. Аналогично наличие USB-C либо NFC описывает способ связи, а не автоматически доступные resident-опции. Совместимость складывается из клиента, поставщика FIDO, устройства и серверной политики, причём каждый из этих участников отвечает за отдельную часть операции.
Касание и PIN можно требовать на сервере
PubkeyAuthOptions у sshd содержит touch-required и verify-required. Первая опция требует свидетельства присутствия пользователя при подписи FIDO-ключом, обычно касания устройства. Вторая требует подтверждения проверки пользователя, например через PIN. Эти условия не оказывают действия на обычные не-FIDO типы открытых ключей.
По умолчанию сервер уже требует присутствия для FIDO-подписи, если отдельное authorized_keys-условие не изменило поведение. touch-required запрещает такое ослабление. Следовательно, простая надпись «ключ с касанием» в клиентской инструкции не является единственным местом настройки: сервер может закреплять требование независимо. Проверка присутствия и проверка пользователя не взаимозаменяемы. Касание показывает физическое взаимодействие, но не обязательно различает владельца устройства и другого человека рядом с ним. При этом парольная аутентификация, альтернативные ключи и другие способы входа описываются отдельными серверными настройками. Ужесточение одного FIDO-пути само по себе не утверждает, что все остальные разрешённые пути имеют такую же модель подтверждения.
| Опция | Подтверждение | Для обычных не-FIDO ключей |
|---|---|---|
| touch-required | Физическое присутствие, обычно касание | Не действует |
| verify-required | Проверка пользователя, например PIN | Не действует |
Источник: OpenBSD: PubkeyAuthOptions
Клиент выбирает, какую идентичность предлагать
IdentityFile задаёт файлы идентичности, а IdentitiesOnly ограничивает использование настроенными identities даже тогда, когда агент предлагает дополнительные. Это полезное различие для окружения с несколькими ключами. Наличие правильного аппаратного credential в агенте ещё не означает, что клиент выбрал именно его для данного хоста.
Конфигурация SSH использует секции Host и Match; для большинства параметров действует первое полученное значение. Поэтому более конкретные параметры и общие значения по умолчанию имеют значение в порядке чтения. IdentityFile относится к исключениям, допускающим накопление нескольких записей. ForwardAgent является отдельной настройкой и по умолчанию выключен. Он передаёт доступ к агенту удалённой стороне, а не копирует закрытый ключ на сервер. Но возможность использовать агент и возможность извлечь его ключевой материал различаются: удалённая сторона с соответствующим доступом может запросить операции, даже не получая файл. Аппаратная защита секрета не превращает любое предоставление доступа к агенту в нейтральное действие.
Агент хранит доступ к операциям, не вечную сессию
ssh-agent начинает без загруженных identities; они добавляются отдельно. Через сокет клиент обращается к агенту за операциями аутентификации. Для identities можно задавать срок жизни. Завершение агента и завершение конкретного соединения — разные события, а доступность сокета влияет на то, какие программы могут пользоваться его возможностями.
Для FIDO существует дополнительная граница между SSH и веб-аутентификацией. По умолчанию агент ограничивает подписи, которые могли бы выглядеть как запросы входа на сайты, и учитывает application string с префиксом ssh:. Руководство объясняет цель: forwarding SSH-агента не должен неявно превращаться в передачу возможности входить на веб-сайты тем же устройством. Это ограничение модели подписания, а не обещание защиты от всех действий вредоносного процесса. При работе с аппаратным authenticator по-прежнему важно различать сохранённую identity, доступ к агенту, физическое подтверждение и результат серверной проверки. Ни одно из этих состояний не описывает автоматически остальные.
