Пересылка доступа к подмножеству идентификаторов ssh-agent

Я работаю на две компании (назовем их RedCorp и BlueCorp). Обе компании доверяют мне, но не доверяют друг другу, и я не хочу раскрывать секреты одной другой.

У моего ноутбука есть ssh-агент с двумя закрытыми ключами, по одному для доступа к каждой компании. Я могу запустить:

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 таким особым образом.

Существует ли лучший способ сделать это?

Теперь вы можете использовать несколько агентов и конкретно указывать каждый из них с помощью 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

Я реализовал ssh-agent-filter для себя, используйте его следующим образом:

$ afssh -c id_bluecorp -- server1.bluecorp.com
$ afssh -c id_bluecorp -- server2.bluecorp.com
$ afssh -c id_redcorp -- server42.redcorp.com

Он уже в Debian (и Ubuntu).

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

Это означает, что вы можете использовать фильтр ssh-agent, чтобы фильтровать только тот ключ, который вам нужен на удаленной машине, и изменить переменную окружения из фильтра 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-агента.