Проброс SSH-агента (agent forwarding)

Что такое проброс агента и как он работает

Программа ssh-agent хранит ваши закрытые ключи в памяти и подписывает запросы аутентификации от имени ssh. Согласно справке ssh-agent(1), ключи и парольные фразы никогда не передаются по сети. Проброс агента переносит это на следующий переход: когда вы подключаетесь к серверу через ssh -A, сервер получает канал обратно к агенту на вашей машине. С этого сервера можно запустить ssh или git к третьему хосту и пройти аутентификацию локальными ключами, не храня закрытый ключ на промежуточном сервере.

На удалённой стороне пробрасываемый агент виден как Unix-сокет, путь к которому лежит в переменной окружения SSH_AUTH_SOCK. По умолчанию проброс выключен: опция ForwardAgent из ssh_config(5) равна no, -A включает её для одного подключения, а -a выключает. Опция принимает также yes, явный путь к сокету или имя переменной, в которой хранится путь.

Как включить, проверить и безопасно протестировать

Включите проброс для одного подключения или только для одного именованного хоста в ~/.ssh/config:

ssh -A build

Host build
    HostName build.example.com
    ForwardAgent yes

Чтобы увидеть, что доступно на удалённой стороне, войдите и выполните echo "$SSH_AUTH_SOCK" и ssh-add -l. При включённом пробросе вторая команда выведет отпечатки ключей вашего локального агента, а без него сообщит, что агент недоступен. Сравните оба случая с ssh -a и ssh -A на тестовом сервере.

Ограничьте возможности пробрасываемого агента. ssh-add -c требует подтверждения при каждом использовании ключа (через askpass-программу), а -t задаёт срок жизни, например ssh-add -c -t 1h. В конфиге то же делает AddKeysToAgent confirm для ключей, которые ssh добавляет сам. Локально ssh-add -l показывает загруженные ключи, а ssh-add -D удаляет все. См. ssh-add(1).

Риски для безопасности и типичные ошибки

Справка ssh(1) говорит прямо: тот, кто может обойти права доступа к файлам на удалённом хосте, например root, получает доступ к вашему агенту через пробрасываемый сокет. Сами ключи он получить не может, но может использовать загруженные ключи для входа на любой хост, который их принимает, пока соединение открыто. Один скомпрометированный сервер на пути превращается в вход во всё, что открывают ваши ключи.

Типичные ошибки: ForwardAgent yes в блоке Host *, проброс на общие или управляемые клиентами машины, долгие сессии на сервере, который вы не полностью контролируете. Пробрасывайте агент только на хосты, которые вы администрируете, держите ключи с коротким сроком жизни и включайте подтверждение. Начиная с OpenSSH 8.9 есть также ограничения по назначению, ssh-add -h, которые задают, для каких хостов можно использовать ключ; в справке сказано, что они действуют только для совместимых клиентов и не мешают пробросить ключ дальше.

На сервере опция AllowAgentForwarding в sshd_config(5) по умолчанию равна yes.

Проброс агента и защита сервера

Безопасную альтернативу называет сама справка ssh(1): промежуточный хост (jump host). При ProxyJump клиент подключается через промежуточную машину, а аутентификация на конечном сервере выполняется напрямую с вашего компьютера, поэтому на промежуточном хосте сокета агента нет.

Host bastion
    HostName jump.example.com
    User ops

Host app
    HostName 10.0.0.12
    ProxyJump bastion

Эта схема описана в статье про бастионный хост. Оставьте AllowTcpForwarding включённым на промежуточном хосте, так как ProxyJump его использует, и не храните там закрытые ключи. На серверах, которым не нужен проброс агента, руководство по защите SSH рекомендует AllowAgentForwarding no. Справка оговаривает, что это помогает только если пользователям закрыт и shell: они могут запустить собственные средства проброса. Добавьте второй фактор по руководству по двухфакторной аутентификации и следите за отпечатками ключей в логах, как описано в руководстве по анализу логов.

Связанные термины: SSH, Bastion host (бастионный хост), sshd_config, Вход по ключам, Принцип наименьших привилегий.