Вопрос: Разрешать только определенные ключи в пересылке агента?


Можно ли использовать переадресацию агента, исключая пересылку всех ключей, кроме тех, которые конкретно указаны? Кроме того, есть ли способы указать порядок проверки ключей на сеанс?

С помощью 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.)


7
2018-03-17 03:11


Источник




Ответы:


Я не знаю никаких агентов, которые допускают выборочную пересылку ключей, как вы нарисовали на диаграмме. Как только ключ пересылается хосту, он как бы локально хранится и может использоваться для аутентификации на любом хосте оттуда.

Рассматривая свой вопрос на другом уровне, у меня есть две идеи о том, что вы пытаетесь сделать:

  • Запретить кому-либо проходить проверку подлинности на определенных хостах без физического присутствия в месте.

Если это ваша цель, вы не сможете добиться этого путем контроля ключей аутентификации. Вы должны контролировать доступ с помощью ограничений архитектуры и хоста, так что ни один хост, к которому можно получить доступ удаленно, не имеет доступа к «безопасному» хосту.

  • «Защитите» определенные клавиши, чтобы они не были открыты.

Если это ваша цель, это непонимание того, как защитить ключи. Ключи сами никогда не пересылаются. Перенаправляется возможность доступа к агенту ssh для аутентификации по ключу. Однако эта пересылка может быть использована только в том случае, если переадресация на месте и только если машина, на которую вы перенаправили своего агента, управляется ненадежным администратором (добровольно или через компромисс). Таким образом, на вашей диаграмме, если вы не выполните успешную запись с машины B -> D а также экспорт из A -> B -> D, вы не рискуете подвергать свои учетные данные. Вы можете переходить из A -> B в безопасное место, если вы доверяете B.

Я предлагаю вам прочитать очень подробное объяснение как экспедирование работает с диаграммами если вы все еще не поняли эту концепцию.


1
2018-03-17 18:13



Цель состояла в том, чтобы обойти тот факт, что порядок, используемый ключами на «сервере Б», не может быть легко настроен при пересылке агента. Все работает, используя обычную сессию .ssh с .ssh / config. Тем не менее, во время пересылки агента кажется, что у вас нет контроля над заказом проверенных ключей. Вопрос был скорее любопытством, чем практическими / соображениями безопасности. Спасибо за подробный ответ и извините за путаницу. - dgo.a
кажется вполне законным доверять B только для конкретной задачи и, следовательно, только пересылать ключи, которые могут аутентифицировать задачи B-ish на B. Таким образом, вы, кажется, недопонимаете, почему «Защитить определенные ключи, чтобы они не были открыты», является разумной целью. Если ключ может использоваться для аутентификации, доступ к тому, что он защищает, может быть потерян, а затем был ли открыт ключ или нет, не имеет значения. - user239558


Если эта проблема возникает только для развертывания приложений, используя различные частные репозитории, которым требуются разные ключи:

Вы можете вообще пропустить переадресацию агента. Скопируйте файлы на компьютер, содержащий различные ключи, затем rsync клонированные репозиции на сервер, на котором происходит развертывание.

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


1
2018-03-18 05:36





Функция, подобная запрашиваемой, будет принадлежать клиенту ssh.

Ssh-agent будет слишком сложно понять, когда он обменивается данными через пересылку и когда он обменивается данными с локальным клиентом ssh. Предоставление серверу применения этого ограничения было бы недостатком безопасности. Это оставляет клиент ssh единственным местом, где такая функция может существовать разумно.

Быстрый просмотр источника openssh приведет меня к функции client_request_agent в clientloop.c. Из того, что я вижу там, создается впечатление, что клиент ssh просто перенаправляет поток сырого байта, не пытаясь понять, какие ключи используются. Это означает, что для добавления этой функции клиенту потребуются значительные усилия.

Еще одна связанная с этим функция, которая может быть добавлена ​​с меньшими затратами, - это вариант использования двух разных агентов. Один агент может использоваться для аутентификации с сервером, в то время как другой агент может быть перенаправлен на сервер.

Оба были бы полезными функциями, которые я бы использовал, но увы, похоже, не существует в openssh (пока).


1
2018-03-29 19:19