Кратко

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

Достоверная подпись не раскрывает замысел

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

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

Сообщение SSH_AGENTC_SIGN_REQUEST несёт blob открытого ключа, строку данных и flags. Успешный SSH_AGENT_SIGN_RESPONSE возвращает подпись. Стандарт не требует передавать имя исполняемого файла, человека, целевой машины, удалённого пользователя, команды, заявки на изменение или правила допуска. Данные могут содержать SSH-запрос аутентификации, однако общий протокол агента не утверждает, что это единственный сценарий, и не знает дальнейшего решения принимающей стороны.

Такое ограничение нормально. Ошибка появляется, когда панель управления переводит наблюдение «ключ подписал байты» в утверждение «владелец согласился». Why BTW Media Exists требует отличать наблюдаемую реальность от приписанной интерпретации. Криптографическая операция наблюдаема. Согласие и разрешение нуждаются в самостоятельной доказательной цепочке.

Сохранность ключа и управление вызовами — разные задачи

RFC 9987 прямо говорит: протокол агента не обеспечивает собственную аутентификацию клиентов или транспортную безопасность. В обычной системе используется локальный socket либо именованный канал, доступ к которому ограничивает ОС. Достигший этой точки процесс обычно может просить операции с видимыми идентификаторами. Поэтому защищать нужно не только байты ключа, но и интерфейс, заставляющий их работать.

Вредоносный процесс способен не суметь извлечь ключ и всё же использовать доступный агент без ограничений как подписывающий oracle. Спецификация также отмечает, что такой oracle особенно удобен для наблюдения побочных каналов. «Неэкспортируемый» — содержательный факт о хранении. Он не означает, что каждый вызов был правомерным. Для похищенного использования не всегда требуется похищенный секрет.

С аппаратным токеном важно называть слой. Загрузка идентификатора в агент может лишь делегировать будущую операцию устройству. Удаление из агента не должно стирать ключ на токене. Если аварийный отчёт говорит «ключ удалён» без указания хранилища, сессии и эпохи загрузки, команда может закрыть инцидент при сохранённой возможности снова добавить тот же идентификатор.

The Policy Mirror предлагает отражать реальное распределение контроля. ОС допускает клиента к каналу. Агент применяет ограничения. Токен защищает материал и, возможно, проверяет присутствие. SSH-сервер решает, подходит ли ключ запрошенной учётной записи. Прикладная политика разрешает действия после входа. Одна подпись проходит через эти уровни, но не объединяет их решения.

Ограничение имеет свою эпоху

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

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

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

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

Пересылка переносит право на использование

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

Структура канала ограничивает атрибуцию. agent-connect не передаёт идентификатор session channel, откуда пришло соединение. Одна SSH-связь способна нести несколько сессий, а локальный агент — видеть параллельные пересланные подключения. Знания о transport может не хватить, чтобы назвать конкретную оболочку, процесс или человека.

Running Code Primary возвращает внимание к работающим границам: владельцу и правам socket, доступным сведениям о peer, фактическому выбору пересылки, эпохе ограничений, времени запроса и результату проверяющей стороны. Записанная политика «не пересылать» сама по себе не доказывает путь отдельной подписи.

Вердикт аутентификации принадлежит серверу

В RFC 4252 сервер решает, допустим ли открытый ключ для запрошенного пользователя, и проверяет подпись. Подписываемая структура включает session identifier, имя пользователя, сервис, метод, алгоритм и ключ. Сервер может потребовать дополнительные факторы. Полную аутентификацию обозначает его SSH_MSG_USERAUTH_SUCCESS, а не более ранний ответ агента.

RFC 4253 создаёт защищённый транспорт и идентификатор сессии, RFC 4254 регулирует последующие каналы и сервисы, RFC 4251 задаёт общую архитектуру. Поэтому применение ключа, допуск к учётной записи и разрешение команды остаются тремя разными фактами.

Реестры алгоритмов также не выдают полномочия. RFC 8332 описывает RSA с SHA-2, RFC 8709 — Ed25519 и Ed448, RFC 8308 — согласование расширений. Реестр параметров SSH IANA закрепляет совместимые имена. Запись в нём не доказывает внедрение, доступность агента, согласие или авторизацию.

Шесть ступеней квитанции о намерении

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

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

Это предложение Daniel Kade по управлению, а не требование полей RFC 9987. Оно не заставляет агент понимать бизнес-контекст; оно не позволяет его узкому результату притвориться всей цепочкой полномочий.

Источники