Можно ли использовать пересылку агента, исключая из пересылки все ключи, кроме специально указанных? В качестве альтернативы, есть ли какие-либо способы указать порядок, в котором ключи проверяются за сеанс?
С помощью ssh-agent требует управления разными сокетами: https://superuser.com/questions/357602/use-a-specified-key-from-ssh-agent/401737#comment396923_358604
Есть ли альтернативные агенты, которые легче настроить?
Например:
Client A --> ssh/agent-forwarding --> Server B --> Server C
|
------> Server D
Я хочу разрешить только один ключ в переадресации агента, что позволяет: A -> B -> C, и нет A -> B -> D. Или, по крайней мере, укажите порядок использования ключей.
(Отредактировано для ясности после ответа @ jeff-ferland.)
Такая функция, как запрошенная, будет принадлежать ssh-клиенту.
Для ssh-agent было бы слишком сложно определить, когда он взаимодействует через пересылку, а когда - с локальным ssh-клиентом. Позволить серверу применить ограничение было бы недостатком безопасности. Таким образом, клиент ssh остается единственным местом, где такая функция может существовать.
Быстрый просмотр исходного кода openssh привел меня к функции client_request_agent в clientloop.c. Из того, что я там вижу, создается впечатление, что клиент ssh просто пересылает необработанный поток байтов, не пытаясь понять, какие ключи используются. Это означает, что для добавления этой функции клиенту потребуются значительные усилия.
Еще одна связанная функция, которую можно было бы добавить с меньшими усилиями, - это возможность использования двух разных агентов. Один агент может использоваться для аутентификации на сервере, в то время как другой агент может быть перенаправлен на сервер.
Обе функции были бы полезными, и я бы тоже ими воспользовался, но, увы, в openssh их нет (пока).
Если эта проблема возникает исключительно при развертывании приложения с использованием различных частных репозиториев, для которых требуются разные ключи:
Вы можете вообще пропустить переадресацию агента. Скопируйте файлы на машину, содержащую различные ключи, затем выполните синхронизацию клонированных репозиториев с сервером, на котором происходит развертывание.
Client A
|
* private keys
* `git clone ...` private repos
* /tmp/repos
|
| ------------> rsync/scp -----------> Server B
Вы можете автоматизировать этот процесс с помощью псевдонимов, сценариев оболочки и т. Д. Capistrano даже имеет это встроенное. Это называется стратегией копирования: http://rubydoc.info/github/capistrano/capistrano/master/Capistrano/Deploy/Strategy/Copy
Мне не известны какие-либо агенты, которые позволяют избирательную пересылку ключей, как вы схематически изображали. Когда ключ пересылается на хост, он как будто хранится локально и может использоваться для аутентификации на любом хосте оттуда.
Глядя на ваш вопрос на другом уровне, у меня есть две идеи о том, что вы, возможно, пытаетесь сделать:
Если это ваша цель, вы не можете достичь ее с помощью управления ключами аутентификации. Вы должны контролировать доступ через архитектуру и ограничения хоста, чтобы ни один хост, к которому можно получить удаленный доступ, не мог получить доступ к «безопасному» хосту.
Если это ваша цель, значит, вы не понимаете, как защитить ключи. Сами ключи никогда не пересылаются. Передается возможность доступа к ssh-агенту для аутентификации по ключу. Однако такая переадресация может быть использована только при наличии пересылки и только в том случае, если машина, на которую вы переадресовали своего агента, управляется ненадежным администратором (добровольно или путем компрометации). Таким образом, на вашей диаграмме, если вы успешно не войдете с машины B -> D и переадресация экспорта из A -> B -> D, вы не рискуете раскрыть свои учетные данные. Вы можете безопасно пересылать из A -> B, если доверяете B.
Предлагаю вам прочитать очень подробное объяснение как работает переадресация с диаграммами если вам все еще неясна концепция.