Как дать контейнеру SSH-доступ и не отдать ключ
В статье разбирают схему, где контейнер может пользоваться SSH, но не получает сам приватный ключ. Это особенно важно для rootless Docker и для систем с ИИ-агентами, где лишний доступ к секретам лучше исключить заранее.
Почему простой ключ внутри контейнера — плохая идея
SSH нужен не только для серверов, но и для работы с приватными репозиториями, сабмодулями, автоматизацией и удалёнными командами. Проблема в том, что если приватный ключ или токен попадает в сам процесс, компрометация приложения может привести к утечке секрета.
Автор статьи отдельно подчёркивает: неважно, используете вы SSH или другой способ аутентификации, — если секрет доступен процессу, его можно прочитать. Даже монтирование ключа только для чтения не спасает, потому что чтение остаётся возможным.
Как устроена схема с ssh-agent и rootless Docker
Предлагается другой подход: в контейнер передаётся не приватный ключ, а Unix-сокет ssh-agent. Сам ключ остаётся вне контейнера, а приложение получает только возможность запрашивать у агента нужные SSH-операции.
Такой вариант хорошо подходит для rootless Docker, где контейнер не работает от root, файловая система может быть только для чтения, а Linux capabilities удалены. В этой схеме процесс внутри контейнера может подключаться к разрешённым ресурсам, но не получает прямого доступа к материалу ключа.
Где возникает сложность и кому это пригодится
Основная техническая проблема связана с UID: в rootless-контейнере идентификатор пользователя внутри контейнера не совпадает с тем, что виден на хосте. Из-за этого обычное монтирование SSH_AUTH_SOCK не всегда работает для non-root процесса, и автор обещает отдельно разобрать сопоставление UID/GID и способы настройки.
Подход особенно полезен для ИИ-агентов и промежуточных API-слоёв вроде MCP-серверов. Он помогает снизить риск утечки секретов, если агенту нужно работать с Git, удалёнными серверами или другими инструментами, которые используют OpenSSH.