То, что такое лучшие практики для управления SSH, вводит команду?

У меня была ситуация, когда мне нужно было предоставить доступ по SSH-ключу команде из 40 разработчиков к ~ 120 удаленным серверам клиентов.

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

В моей компании мы используем LDAP, чтобы иметь согласованный набор учетных записей на всех машинах, а затем используем инструмент управления конфигурацией (в нашем случае в настоящее время cfengine) для распространения authorized_keys файлы для каждого пользователя на всех серверах. Сами файлы ключей хранятся (вместе с другой информацией о конфигурации системы) в репозитории git, поэтому мы можем видеть, когда ключи приходят и уходят. cfengine также распространяет файл sudoers , который контролирует, кто имеет доступ к запуску чего-либо как root на каждом хосте, используя пользователей и группы из каталога LDAP.

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

У нас также есть хост-бастион, который используется для доступа к хостам в производственной сети , что позволяет нам иметь очень строгие правила брандмауэра для этой сети. У большинства инженеров есть специальная конфигурация SSH, чтобы сделать это прозрачным:

Host prod-*.example.com
     User jsmith
     ForwardAgent yes
     ProxyCommand ssh -q bastion.example.com "nc %h %p"

Добавление нового ключа или удаление старого требует небольшой церемонии в этой настройке. Я бы сказал, что для добавления нового ключа желательно, чтобы это была операция, которая оставляет контрольный след и видна всем. Однако из-за накладных расходов, я думаю, люди иногда пренебрегают удалением старого ключа, когда он больше не нужен, и у нас нет реального способа отследить это, кроме как убрать, когда сотрудник покидает компанию. Это также создает некоторые дополнительные трения при приеме на работу нового инженера, поскольку им необходимо сгенерировать новый ключ и отправить его на все хосты, прежде чем они смогут работать полностью.

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

При такой настройке утомительно иметь автоматизированные системы, которые принимают меры против рабочих хостов, поскольку их «хорошо известные» ключи SSH могут служить альтернативным путем доступа. Пока мы

Один из подходов, о котором я слышал, но не использовал сам, заключается в том, чтобы каждый пользователь имел пакет (например, .deb, .rpm), который также содержит конфигурацию их открытого ключа ssh. как любые точечные файлы, которые они любят настраивать (.bashrc, .profile, .vimrc и т. д.). Он подписывается и хранится в репозитории компании. Этот пакет также может отвечать за создание учетной записи пользователя, или он может дополнять что-то еще, создавая учетную запись (cfengine / puppet и т. Д.) Или центральную систему аутентификации, такую ​​как LDAP.

Эти пакеты затем устанавливаются на хосты с помощью любого механизма, который вы предпочитаете (cfengine / puppet и т. д., cron job). Один из подходов состоит в том, чтобы иметь метапакет, который зависит от пакетов для каждого пользователя.

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

Если у вас разнородные системы и вам нужно поддерживать файлы .rpm и .deb, я вижу, что это немного раздражает, хотя такие инструменты, как alien, могут сделать это несколько проще.

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

Лично мне нравится идея о том, что у каждого члена персонала есть один ключ на выделенной машине-бастионе ssh, на которой у них есть базовая учетная запись пользователя. Эта учетная запись пользователя имеет 1 ключ ssh, который предоставляет доступ ко всем серверам, которые им нужны. (эти другие серверы также должны быть отключены брандмауэром, чтобы был разрешен только ssh-доступ с машины-бастиона)

Затем на своих повседневных рабочих машинах, ноутбуках, планшетах и ​​т. д. они могут сделать свой собственный выбор, иметь один ключ между собой или несколько ключей.

Как системный администратор в этой сети, у вас есть минимальное количество ключей, за которыми нужно следить (по одному на разработчика), вы можете легко контролировать доступ по ssh через сеть (поскольку он все маршрутизируется через машину-бастион), и если разработчику нужно несколько ключи или только один, который они используют на своих машинах, это не проблема, так как вам нужно обновить только одну машину.

Лично я бы выбрал каждого пользователя, тогда вы сразу же получите ответственность и гораздо проще устанавливать ограничения - я не знаю, что думают другие?

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

Если у вас есть общие ключи между пользователями - даже если вы небольшая команда - отзыв ключа доставит неудобства всем остальным.

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

Подход может заключаться в настройке сервера NIS с общим доступом / home через NFS. Это в сочетании с sudo на серверах и позволяет только пользователям, которых вы хотите, на каждый сервер через конфигурацию ssh.

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

С уважением,

Рафаэль

Несколько лет назад Envy Labs написала инструмент под названием Keymaster (в партнерстве с клиентским Gatekeeper), чтобы справиться с чем-то подобным для команд разработчиков.

Проект не очень понравился последние два года, но, вероятно, вы могли бы поработать над этим и, возможно, вернуть его к жизни?

Репозиторий доступен на github: https://github.com/envylabs/keymaster