Кратко

  • RFC 9987 задаёт протокол агента, который хранит закрытые ключи и принимает запросы на перечисление, загрузку, удаление, блокировку и подпись. В базовом протоколе нет аутентификации клиента и защиты транспорта; возможность обратиться к endpoint обычно и есть действующее разрешение.
  • Пересылка агента не копирует секретный материал на удалённый узел. Она переносит туда путь вызова закрытой операции, создавая транзитивное доверие и риск кражи использования без кражи ключа.
  • Время жизни, подтверждение и расширенные ограничения сужают возможность. Целевой сервер всё равно самостоятельно решает, подходит ли ключ учётной записи, верна ли подпись, нужны ли другие факторы и какие каналы разрешены.

Начнём с конца цепочки. Агент вернул корректную подпись. На целевом сервере это лишь входной материал для следующего решения. В SSH public-key authentication сервер должен признать открытый ключ допустимым аутентификатором конкретного пользователя и проверить подпись. Он может потребовать ещё один метод.

Поэтому ответ агента не равен входу. Вход не равен разрешению на shell, subsystem или forwarding. А открытый канал не доказывает, что команда сработала. Одна криптографическая истина не получает полномочия говорить за все последующие состояния.

Но есть и обратная сторона. Если атакующий сохранил живой доступ к агенту, он может попросить новую подпись для нового корректно сформированного сеанса. То, что старая подпись привязана к конкретному контексту и не является универсальным паролем, не устраняет злоупотребление онлайн-службой подписи.

Хранение секрета и доступ к операции

RFC 9987 опубликован в мае 2026 года как Proposed Standard. Протокол управляется клиентом: агент не посылает инициативных сообщений и отвечает по порядку. Клиент может запросить список ключей, добавить или удалить их, заблокировать агент и попросить закрытую операцию. Агент вправе отказать.

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

Однако базовый agent protocol не содержит собственной аутентификации или транспортной безопасности. На Unix границу формируют права сокета и проверка peer credentials, на Windows — security descriptor именованного канала. SSH_AUTH_SOCK сообщает путь к службе.

Доступ к этому endpoint обычно достаточен для закрытых операций. RFC прямо различает невозможность получить копию ключа и возможность украсть его использование. Аппаратная защита отвечает на первый вопрос, но не автоматически на второй.

Запрос подписи содержит public key blob, данные и flags. Успех означает, что агент подписал эти данные в текущем состоянии. Он не подтверждает полномочия процесса, одобрение назначения, принятие сервером или исполнение действия.

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

Ограничение срока просит агента удалить ключ через заданное число секунд после загрузки. Оно закрывает будущие вызовы данного агента, но не отзывает выданные подписи, не завершает принятые удалённые сессии и не отменяет изменения.

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

Следовательно, флаг «confirmation enabled» не доказывает осознанного разрешения. Нужны отображённый контекст, субъект решения и связь с запросом.

Extension constraint позволяет добавить правило реализации. Неизвестное ограничение нельзя безопасно пропустить, поэтому агент обязан прекратить разбор и отвергнуть ключ. Это fail closed. Но правило работает лишь в совместимом наборе клиента и агента, а его исполнение подтверждает тест.

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

Блокировка прекращает чувствительные операции до правильного unlock. Она локальна и не закрывает задним числом сеансы на других серверах.

Forwarding создаёт транзитивную связь

При agent forwarding удалённый socket передаёт protocol messages через SSH-канал к агенту клиента. Секрет не пересылается; пересылается возможность попросить его работать.

RFC называет это транзитивным доверием. Реализации не должны включать forwarding по умолчанию, а пользователи не должны направлять его на хосты, которым не доверяют полностью. Без дополнительных ограничений видимости и использования выбор становится «всё или ничего».

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

Атрибуция требует корреляции. Один SSH transport может мультиплексировать несколько sessions и одновременных agent connections. В agent-connect нет идентификатора исходного session channel. Клиент по своей политике может принять соединение без предыдущего session request и продолжить после закрытия исходной сессии.

Это допустимая гибкость, но не доказательство происхождения. Надо связать внешнее соединение, запрос forwarding, agent channel, ключ, ограничения, подпись и аутентификацию назначения.

Контекст подписи и решение сервера

RFC 4252 включает в подписанные данные session identifier, имя пользователя, service, метод, algorithm и ключ. Сервер отдельно проверяет допуск ключа и корректность подписи. Так одна подпись связывается с одним запросом.

Но живой caller способен сформировать следующий запрос и получить следующую подпись. Защита от replay не равна прекращению вызываемой способности.

Нужно различать: ключ загружен; endpoint доступен; агент согласился; подпись связана с контекстом; сервер принял; канал получил права; возник эффект. Каждому переходу нужен владелец и журнал.

Алгоритмы тоже не едины. Агент может поддерживать RSA или Ed25519, клиент запросить RSA/SHA-2, сервер принять другой набор, а политика организации быть строже. IANA координирует имена, но не доказывает включение и соответствие системы.

Полная доказательная линия

На исходной машине фиксируют процесс агента, права endpoint, peer identity, fingerprint, время загрузки, действующие ограничения, lock и удаление. Для токена добавляют provider library и изоляцию кода.

На границе forwarding фиксируют внешнее SSH-соединение, доверие к хосту, запрос, все agent channels и закрытие. Ищут каналы, живущие после session, и различают явную, унаследованную и opportunistic конфигурацию.

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

Затем наблюдают действие: command, subsystem, port forwarding, file operation или отказ. Завершение также проверяют: удаляют ключ, закрывают агент и каналы, снимают серверный допуск и видят отказ новой попытки.

Так утверждение «закрытый ключ не покидал устройство» остаётся полезным фактом, но перестаёт скрывать возможное использование.