SSH-сертификаты для AI-агентов и локальное хранение учетных данных

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

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

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

Сертификат ограничивает прием, а не владение

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

Это различие постоянно размывают. Сертификат относится к публичным данным. Файл id_ed25519-cert.pub можно положить рядом с закрытым ключом, скопировать на клиентскую машину и свободно просматривать. Секретом остается id_ed25519. Если агент получает этот закрытый файл, короткий срок действия сертификата ограничивает лишь время работы одного выданного сертификата. У агента по-прежнему остается пригодный для повторного использования ключ подписи.

OpenSSH описывает формат сертификатов в PROTOCOL.certkeys, а обычные параметры создания приведены в руководстве ssh-keygen. Команда подписи принимает закрытый ключ CA через -s, строку идентификатора через -I, разрешенные принципалы через -n и описание срока действия через -V. Это входные параметры авторизации, а не декоративные метаданные. Сервер должен быть настроен на доверие CA и обработку принципалов, прежде чем эти параметры начнут влиять на доступ.

Рассмотрим две схемы:

• В первой агент получает id_ed25519, сертификат и адрес CA. Он может сам подписывать SSH-запросы и, возможно, отправлять новые запросы на сертификаты.
• Во второй локальный исполнитель хранит id_ed25519 в защищенном хранилище. Агент запрашивает именованное SSH-действие, а исполнитель сам выполняет SSH-аутентификацию, не возвращая закрытые данные.

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

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

Локальное хранение меняет сценарий отказа

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

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

Распространенный неудачный компромисс заключается в том, что каталог с секретами монтируют в окружение агента только для чтения. Режим «только чтение» защищает от изменений, но не от чтения. Другой плохой вариант, когда закрытый ключ помещают в SSH-агент и дают каждому дочернему процессу доступ к SSH_AUTH_SOCK. Для строго контролируемой интерактивной оболочки это иногда приемлемо, но автономный агент программирования запускает инструменты, тесты, хуки пакетов и вспомогательные процессы. Каждый из них расширяет круг тех, кто может попросить агент подписать запрос.

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

Держите эту границу узкой. Компонент, владеющий закрытым ключом, не должен принимать произвольный текст оболочки и бездумно запускать его только потому, что его передал агент. Он должен знать хост, целевую учетную запись и действие, которое будет выполнять, а также записывать эти сведения до выполнения или одновременно с ним. Если нельзя восстановить, какой процесс запросил ssh deploy@host, локальное хранение превратилось в плохо подотчетную оболочку для секрета.

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

Срок действия сертификата должен учитывать допустимое время прерывания

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

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

Для многих автономных задач разумно начать с сертификата на 15-60 минут. Выбирайте нижнюю границу, если учетная запись может влиять на рабочие системы. Более длинное окно оправдано только реальной необходимостью, которую вы можете объяснить. Сертификат на несколько часов для задачи на десять минут обычно маскирует удобство под операционную необходимость.

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

Это меняет схему:

1. Задайте срок действия сертификата, ограничивающий новые аутентификации.
2. Отдельно ограничьте длительность команды или сессии в локальном исполнителе.
3. Не передавайте агенту повторно используемый управляющий сокет мультиплексирования.
4. В экстренной ситуации завершайте активные сессии, если нужно остановить само действие.

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

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

Продление должно подтверждать сохранение той же границы хранения

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

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

Команда создания сертификата на стороне издателя может выглядеть так:

ssh-keygen -s agent_user_ca -I run-4821 -n deploy-prod -V +30m agent-run-4821.pub

Эта команда подписывает agent-run-4821.pub закрытым ключом CA. Она создает сопутствующий публичный сертификат, обычно с именем agent-run-4821-cert.pub. Строка run-4821 помогает сопоставлять записи, deploy-prod задает разрешенный принципал, а +30m запрашивает интервал в тридцать минут. Издатель должен сам создавать строку идентификатора, а не доверять метке, переданной агентом.

Проверяйте каждый новый сертификат до того, как автоматизация начнет на него опираться:

ssh-keygen -L -f agent-run-4821-cert.pub

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

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

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

Принципалы и политика сервера определяют возможности сертификата

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

OpenSSH может доверять пользовательскому CA через TrustedUserCAKeys. Затем принятые принципалы можно сопоставить через AuthorizedPrincipalsFile или AuthorizedPrincipalsCommand. Второй вариант удобен, когда серверу нужно централизованное сопоставление учетных записей, но он добавляет зависимость входа от доступности этого сервиса. Статичный файл принципалов менее гибок, зато для небольшой инфраструктуры его обычно проще понимать и контролировать.

Ограниченная конфигурация сервера может выглядеть так:

TrustedUserCAKeys /etc/ssh/agent_user_ca.pub
AuthorizedPrincipalsFile /etc/ssh/auth_principals/%u
RevokedHostKeys /etc/ssh/revoked_agent_credentials.krl

Для локальной учетной записи deploy файл /etc/ssh/auth_principals/deploy может содержать только:

deploy-prod

Такая схема означает, что сервер принимает сертификат от указанного CA, только если в нем есть принципал deploy-prod и сертификат не отозван настроенным KRL. Проверяйте точную версию OpenSSH на своих серверах. Принципы конфигурации и поведение сертификатов стабильны, но упаковка дистрибутива и старые версии могут повлиять на то, на что можно рассчитывать.

Критические параметры и расширения сертификата позволяют еще сильнее ограничить применение. OpenSSH поддерживает такие критические параметры, как force-command и source-address, а также распознает расширения permit-pty, permit-port-forwarding и permit-agent-forwarding. Используйте их, если целевой процесс имеет узкую форму. Агенту, который запускает только помощник развертывания, не следует случайно выдавать обычную интерактивную оболочку.

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

Для экстренного отзыва недостаточно ждать истечения срока

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

Сначала остановите новую выдачу для нужной сессии, учетных данных или CA. Затем, если ситуация того требует, не позволяйте уже выданным учетным данным проходить аутентификацию. В OpenSSH список отозванных ключей, KRL, позволяет серверам отклонять отдельные сертификаты, публичные ключи или подписывающий CA.

Чтобы добавить выданный сертификат в KRL, оператор может использовать команду такого вида:

ssh-keygen -k -f revoked_agent_credentials.krl -s agent_user_ca.pub agent-run-4821-cert.pub

Аргумент -s указывает CA, подписавший сертификат. Распространите созданный KRL на целевые серверы, сохраняйте путь, соответствующий RevokedHostKeys, и перезагрузите sshd в соответствии с рабочей процедурой. Заранее проверьте весь процесс: создайте сертификат, успешно пройдите аутентификацию, добавьте сертификат в KRL, распространите файл, перезагрузите sshd и убедитесь, что новая аутентификация отклоняется.

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

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

Наконец, завершите активные сессии. Распространение KRL блокирует будущую аутентификацию, но не обязательно завершает SSH-соединение, которое сервер уже принял. Используйте средства управления сессиями хоста, диспетчер задач или сетевые средства, чтобы остановить текущую работу. Затем проверьте уже выполненные команды: отзыв учетных данных не отменит развертывание и не восстановит удаленный файл.

Издатель сертификатов должен закрывать доступ при неопределенности

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

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

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

Издатель также должен предотвращать расширение области доступа при продлении. Сессия, подтвержденная для deploy-prod, не должна продлеваться до root-prod или другого более широкого принципала только потому, что агент изменил план. Для другой учетной записи, группы целей или класса команд требуется новая граница авторизации. Именно здесь долгие автономные задачи часто становятся небезопасными: сессия начинается с узким доступом, а затем через логику продления накапливает исключения, которые никто не проверяет.

Используйте отдельные записи для выдачи и выполнения. Выдача подтверждает, что CA разрешил сертификат. Журналы SSH-сервера и записи активности исполнителя показывают, где использовались учетные данные и какая команда запускалась. Оба источника нужны, когда оператор выясняет, был ли сертификат выдан ошибочно или выдан правильно, но использован неправильно.

Проверяйте отзыв как плановое упражнение с замером времени

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

Используйте такую последовательность:

1. Выдайте сертификат с известным серийным номером и коротким документированным интервалом.
2. Один раз пройдите аутентификацию и запишите событие принятия на сервере.
3. Отключите продление для связанной сессии агента.
4. Добавьте сертификат в KRL, распространите его и перезагрузите целевые экземпляры sshd.
5. Попробуйте установить новое SSH-соединение и убедитесь, что сервер отклоняет его, затем завершите исходную активную сессию, если она существует.

Измеряйте фактическое время от запроса на сдерживание до отказа на каждой группе серверов. Не публикуйте целевой показатель, которого никогда не наблюдали. Он зависит от скорости доставки KRL вашей системой конфигурации и надежности перезагрузки sshd.

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

Сохраняйте свидетельства упражнения. Храните выданный сертификат, обновление KRL, запись исполнителя и журнал отказа целевого сервера. При реальном инциденте этот набор даст реагирующим проверенный путь действий, а не документ, который со временем превратился в пожелание.

Связывайте подтверждение, аудит и SSH-доступ

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

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

Для журнала аудита важна не только удобная просмотрка, но и защита от незаметных изменений. Sallyport строит журналы из зашифрованного аудита с цепочкой хешей, а sp audit verify позволяет оператору проверить эту цепочку офлайн без доступа к хранилищу. Выполняйте такую проверку во время разбора инцидента и при экспорте свидетельств: один лишь читаемый список действий не доказывает, что никто не удалил неудобное событие.

Не поручайте системе аудита отвечать за политику доступа, которую она не применяет. SSH-сервер по-прежнему должен доверять правильному CA, принимать только нужные принципалы, читать актуальный KRL и ограничивать целевую учетную запись. Локальный исполнитель должен защищать закрытые учетные данные и запрашивать выбранные вами подтверждения. Журналы дают свидетельства и помогают в работе. Они не исправляют учетную запись с чрезмерными полномочиями.

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