Нидерландах от 390р
Классическая задача админа: подключиться к бастиону (bastion host) и уже с него попасть на внутренние серверы. При этом приватные ключи хочется держать только на рабочей машине, а не раскидывать по промежуточным хостам. Для этого и существует SSH Agent Forwarding: удалённая машина получает возможность «попросить» ваш локальный ssh-agent подписать запрос, но не получает приватный ключ.
В терминах OpenSSH это выглядит как проксирование сокета ssh-agent — своего рода socket proxy. На удалённой стороне появляется псевдо-сокет, а реально операции подписи выполняются локально, через уже установленный SSH-канал.
Зачем вообще нужен SSH Agent Forwarding
Agent forwarding решает две практические проблемы: «не копировать ключи на сервер» и «не плодить зоопарк ключей по инфраструктуре». Особенно это заметно, когда через bastion вы:
- заходите на несколько внутренних хостов по цепочке;
- работаете с Git-репозиториями с bastion (например, чтобы быстро проверить deploy-скрипт или вытянуть конфиги);
- запускаете Ansible/скрипты, где SSH нужен сразу на набор целей.
Однако удобство здесь напрямую связано с доверием к машине, на которой форвардинг включён: если bastion (или ваша сессия на нём) будет скомпрометирован, агент может начать работать «против вас».
Как это устроено: SSH_AUTH_SOCK и «socket proxy»
Когда у вас запущен ssh-agent, он создаёт UNIX-сокет, а путь к нему экспортируется в переменную окружения SSH_AUTH_SOCK. Любой процесс, который может читать/писать в этот сокет, способен попросить агент выполнить операцию подписи (например, для аутентификации на другом сервере).
Когда вы подключаетесь с включённым форвардингом (ssh -A), OpenSSH на удалённой стороне создаёт новый сокет (обычно в /tmp или в runtime-директории пользователя) и выставляет на него SSH_AUTH_SOCK в вашей сессии. Этот сокет не хранит ключи: он пересылает запросы по защищённому SSH-каналу обратно на вашу машину, к реальному агенту.
Быстрая проверка, что форвардинг реально работает
echo $SSH_AUTH_SOCK
ssh-add -l
Если ssh-add -l на bastion показывает ключи (точнее, их отпечатки), значит запросы успешно уходят к локальному агенту. Если ключей нет — либо форвардинг отключён, либо агент пустой, либо используется другой механизм (например, аппаратный ключ), где поведение может отличаться.
Россия
Нидерланды
Чем опасен Agent Forwarding: модель угроз и agent hijack
Главное правило: если вы включили agent forwarding на хосте, которому не доверяете на 100%, вы фактически разрешили любому процессу на этом хосте (с доступом к вашему сокету) использовать ваш агент, пока сессия активна.
Agent forwarding обычно не «утаскивает» приватный ключ, но позволяет злоумышленнику использовать ваш агент как удалённую подпись. Этого достаточно, чтобы ходить на другие хосты от вашего имени, пока агент доступен.
Типовой сценарий agent hijack
Вы подключились на bastion с -A. Дальше возможны типовые варианты, при которых третья сторона получает доступ к сокету из вашей сессии:
- вредоносный процесс под вашим пользователем (украденная сессия, троян в dotfiles, компрометированный аккаунт);
- уязвимость на bastion, позволяющая доступ к файлам/процессам вашего пользователя или повышение привилегий;
- подмена инструментов, которые вы запускаете вручную (alias, wrapper-скрипт, вредоносный бинарник в
PATH, компрометированный git-hook).
Если злоумышленник может обращаться к SSH_AUTH_SOCK в рамках вашей сессии, он сможет инициировать подключения к другим серверам, где ваш ключ доверен. То есть «прыжок» произойдёт уже не через bastion как контролируемый шлюз, а через ваш агент.
Почему это особенно критично для bastion
Bastion часто является точкой концентрации доступа: много пользователей, много ручных сессий, утилиты для администрирования, ключевые конфиги инфраструктуры. Поэтому ошибки в гигиене bastion (обновления, права, аудит) сильно повышают риск злоупотребления агентом.
Когда agent forwarding оправдан
Agent forwarding полезен, если вы контролируете bastion и можете обеспечить минимально необходимую «гигиену»: обновления, минимум софта, разделение ролей, мониторинг, жёсткие политики доступа. Тогда это рабочий инструмент для удобства.
Чаще всего оправданные кейсы выглядят так:
- короткие админские сессии «зашёл, сделал, вышел»;
- проброс агента только на bastion, а не «дальше по цепочке»;
- работа с Git на bastion без хранения приватных ключей на сервере;
- аварийные работы, когда нужно быстро восстановить доступ без копирования ключей.
Как включать форвардинг безопасно: точечно и управляемо
Самая частая ошибка — включить ForwardAgent yes глобально. Намного безопаснее включать форвардинг только для конкретных хостов и по возможности использовать jump-подключение, а не «вручную ходить с бастиона дальше».
Точечное включение через SSH config
Host bastion
HostName bastion.example
User admin
ForwardAgent yes
Host internal-*
ProxyJump bastion
ForwardAgent no
Идея: агент доступен на bastion (если вам это действительно нужно), но на внутренние хосты по умолчанию не прокидывается. Для конкретных серверов можно сделать отдельные исключения.
Разовый запуск: -A и принудительное отключение
Для единичного подключения удобнее использовать ssh -A без правок конфигов. А если форвардинг включён в конфиге, но именно сейчас не нужен — лучше отключить явно:
ssh -o ForwardAgent=no bastion
Защита от agent hijack: практические меры
1) Минимизируйте время жизни ключей в агенте
Не держите ключи загруженными «вечно». Загружайте на время работ и используйте TTL:
ssh-add -t 1h ~/.ssh/id_ed25519
ssh-add -l
Через час ключ автоматически исчезнет из агента, и окно атаки станет существенно меньше.
2) Подтверждение на каждую подпись (ssh-add -c)
Опция подтверждения заставляет агент спрашивать разрешение на использование ключа. Это снижает риск «тихого» злоупотребления:
ssh-add -c ~/.ssh/id_ed25519
Для ключей с доступом к продакшену это часто разумный компромисс.
3) Разделяйте ключи по назначению
Один ключ на всё — плохая практика. Отдельные ключи для Git, bastion, продакшена и аварийного доступа позволяют локализовать последствия даже при успешной атаке на агент.
4) Жёстко контролируйте bastion
Agent forwarding безопаснее ровно настолько, насколько безопасен bastion. На практике помогает:
- минимальный набор пакетов и пользователей;
- регулярные обновления безопасности;
- запрет входа по паролю (только ключи/сертификаты);
- персональные аккаунты вместо общих учёток;
- аккуратные правила
sudoпо принципу минимально необходимых прав.
5) Понимайте, где именно доступен SSH_AUTH_SOCK
Если вы используете на bastion tmux, длительные сессии или часто заходите под sudo, переменная SSH_AUTH_SOCK может «жить» дольше, чем вы ожидаете. Например, оставленный tmux на bastion часто означает, что сокет агента будет доступен в прикреплённой сессии до её завершения.
Альтернативы agent forwarding: когда лучше отказаться
ProxyJump без форвардинга
Во многих сценариях bastion нужен только как сетевой шлюз. Тогда достаточно ProxyJump, а агент на bastion не требуется. Подключение идёт «сквозным» образом, а аутентификация выполняется на вашей машине; ForwardAgent можно не включать вообще.
Host internal-db
HostName 10.10.0.10
User admin
ProxyJump bastion
ForwardAgent no
SSH certificates вместо постоянных ключей
Если у вас много серверов и пользователей, вместо раздачи публичных ключей по authorized_keys часто удобнее использовать сертификаты OpenSSH: вы выдаёте короткоживущий сертификат (например, на 15 минут) и логинитесь им. В такой модели agent forwarding часто становится не нужен или используется только локально для хранения ключа, которым подписываются сертификаты, а не для доступа «везде и сразу».
По теме сертификатов полезно держать под рукой разбор практик TTL/отзыва: OpenSSH CA: сертификаты, TTL и отзыв.
Отдельный деплой-ключ на bastion (контролируемый риск)
Иногда (например, для CI или GitOps на bastion) логичнее держать отдельный деплой-ключ прямо на bastion с минимальными правами: read-only на репозиторий, без доступа к продакшену. Да, ключ хранится на сервере, но риск локализован и управляем.
Диагностика проблем: когда forwarding не работает
Симптомы
ssh-add -lна bastion пишет «Could not open a connection to your authentication agent»;- переменная
SSH_AUTH_SOCKпустая; - Git по SSH на bastion просит пароль или «не видит» ключ;
- через
ProxyJumpна внутреннем хосте ключ не используется (а вы ожидали обратного).
Проверки на локальной машине
ssh-add -l
echo $SSH_AUTH_SOCK
ssh -G bastion | grep -i forwardagent
ssh -G показывает итоговую конфигурацию после применения всех Include и Host-правил. Это один из самых быстрых способов понять, почему ForwardAgent включился или, наоборот, выключился.
Проверки на удалённой стороне
echo $SSH_AUTH_SOCK
ls -l $SSH_AUTH_SOCK
ssh-add -l
Если SSH_AUTH_SOCK задан, но ssh-add -l не работает, часто виноваты права на сокет, нестандартная среда, либо форвардинг запрещён на сервере в sshd_config (параметр AllowAgentForwarding).
Рекомендуемая политика для продакшена
Практический набор правил, который хорошо живёт в реальных инфраструктурах:
- по умолчанию форвардинг выключен;
- включается точечно для bastion и только под конкретные задачи;
- ключи в агенте живут ограниченное время (
ssh-add -t); - критичные ключи требуют подтверждения (
ssh-add -c); - для масштабных сред — переход на SSH certificates и короткоживущие доступы;
- bastion рассматривается как компонент безопасности, а не просто «ещё один сервер».
Итоги
SSH agent forwarding — это удобный механизм проксирования сокета ssh-agent через SSH_AUTH_SOCK, который помогает работать через bastion без копирования приватных ключей. Но удобство легко превращается в риск: при компрометации bastion или пользовательской сессии возможен agent hijack, и злоумышленник сможет использовать ваш агент для доступа к другим системам, пока он доступен.
Оптимальная стратегия — включать форвардинг минимально и управляемо, ограничивать время жизни ключей, а в зрелых инфраструктурах рассмотреть SSH certificates как более безопасную и масштабируемую альтернативу. Если bastion у вас живёт на отдельной машине, иногда удобнее вынести его на VDS, чтобы жёстко контролировать окружение и обновления.
