Я работаю в двух компаниях (назовем их RedCorp и BlueCorp). Они оба доверяют мне, но не доверяют друг другу, и я не хочу раскрывать секреты друг другу.
У ssh-agent моего ноутбука есть два закрытых ключа, по одному для доступа к каждой компании. Я могу бегать:
ssh -A redcorp-server1
и получить оттуда доступ ко всем другим серверам redcorp благодаря моему перенаправленному агентскому соединению.
Точно так же я могу запустить:
ssh -A bluecorp-server1
и получить доступ ко всем другим серверам bluecorp оттуда.
Проблема в том, что всякий раз, когда я вхожу в redcorp-server1, пользователь root может установить свой $ SSH_AUTH_SOCK так, чтобы он указывал на мое перенаправленное соединение агента, и злоупотреблял другим моим удостоверением, чтобы взломать BlueCorp.
Как я могу это предотвратить?
Параметр IdentitiesOnly ssh не выполняет то, что я хочу. Это только контролирует, какой ключ я предлагаю при аутентификации на redcorp-server1; это не меняет того факта, что мое перенаправленное соединение агента позволяет процессу ssh на redcorp-server1 аутентифицироваться с использованием любого из моих идентификаторов.
Единственное решение, которое я нашел, - это запустить два отдельных ssh-агента и загрузить только один ключ в каждый из них. Однако это огромная проблема: в разделе ssh_config нет способа указать, какой из моих агентов мне следует использовать при подключении к данному хосту. Вместо этого мне пришлось создать на моем ноутбуке псевдонимы оболочки для каждого из двух корпусов, которые указывают $ SSH_AUTH_SOCK на правильный агент перед запуском ssh. Кроме того, я использую rsync и дюжину других инструментов, которые используют ssh в качестве транспорта, и каждый из них должен быть настроен с использованием другого синтаксиса, чтобы заставить его вызывать ssh особым образом.
Есть лучший способ сделать это?
Я реализовал ssh-агент-фильтр для себя, использую с:
$ afssh -c id_bluecorp -- server1.bluecorp.com
$ afssh -c id_bluecorp -- server2.bluecorp.com
$ afssh -c id_redcorp -- server42.redcorp.com
Это уже есть в Debian (и Ubuntu).
Вы можете использовать несколько агентов и указать каждого отдельно, используя IdentityAgent и добавьте нужные ключи с помощью IdentityFile и установить AddKeysToAgent к yes. Вам нужно будет указать сокет unix для каждого ssh-agent связать с -a вариант. Вы также можете, конечно, добавить ключи вручную с помощью ssh-add, после создания каждого из них.
Сначала создайте своего агента:
ssh-agent -a ~/.ssh/redcorp-agent
Тогда в вашем .ssh/config есть что-то вроде этого:
Host redcorp* *.redcorp.com
IdentityFile ~/.ssh/redcorp.pem
IdentityAgent ~/.ssh/redcorp-agent
AddKeysToAgent yes
ForwardAgent yes
Есть патч для openssh, который перенаправляет ssh-agent, указанный в SSH_AUTH_SOCK_FORWARD переменную окружения на удаленный хост и используйте обычный SSH_AUTH_SOCK окр. var. агент для аутентификации на хосте.
Это означает, что вы можете использовать фильтр ssh-agent, чтобы отфильтровать только тот ключ, который вы хотите получить на удаленном компьютере, и изменить env. var из фильтра ssh-agent в SSH_AUTH_SOCK_FORWARD оставив все свои ключи в SSH_AUTH_SOCK агент.
Вы можете найти патч здесь:
https://bugzilla.mindrot.org/show_bug.cgi?id=1937
Надеюсь, он будет применен к openssh.
Я не понимаю проблемы. Если вы установите и экспортируете $ SSH_AUTH_SOCK в соответствующее значение, тогда программы, вызывающие ssh, не нуждаются в каких-либо изменениях. Конечно, цель, например, вызов rsync должен быть совместим с выбором ssh-agent.