У меня есть серверы баз данных, веб-серверы, серверы SVN и т.д. Часто я использую ssh среди них ... или они автоматически используют ssh.
Как мне управлять тем, какой сервер получает доступ к другим?
Я использую Puppet, и у меня есть класс, определенный для каждого ключа, а затем классы, которые включают эти классы для определения «групп» ключей, которые у меня есть (для нас это люди - так что специалисты уровня L1, специалисты уровня L2, менеджеры, разработчики - но вы может делать серверы БД, файловые серверы, серверы SVN и т. д.). Затем у различных типов машин есть свои собственные манифесты, которые определяют, какая из этих групп имеет доступ к этому типу машины, поэтому в коробках разработки есть L1, L2 и разработчики, у prod-серверов есть L1 и L2, у чувствительных серверов есть только L2, такого рода вещи. Добавление новой машины - это просто вопрос решения, к какому классу она принадлежит, и добавления нескольких строк туда и сюда, что мы задокументировали в наших процедурах ввода в эксплуатацию новых машин.
MIT Kerberos v5.
Kerberos - это безопасная, ориентированная на привилегии, основанная на билетах система, которая понимает концепции пользователей, областей, ролей, машин и т. Д. Вы сначала аутентифицируетесь с помощью билета-билета, который затем получает служебные билеты для вас, когда вы запрашиваете определенные привилегии / логин на машине. Вы можете контролировать, какие участники могут входить в какие учетные записи с централизованно управляемыми файлами ~ / .k5login, возможно, через Puppet / cfengine. Базовые машины конфигурации могут иметь свои собственные участники / ключи и т. Д., Чтобы иметь возможность автоматически обновлять другие системы. Вам также потребуется физически защитить KDC и заблокировать его, возможно, для одного или двух критически важных пользователей, поскольку именно здесь вы отзываете принципалов и т. Д.
Я уверен, что ваша реализация будет сильно отличаться, но приведенное выше является очень общим обзором установки, которую мы использовали для запуска.
Это сложная система, которая может потребовать радикальных изменений с вашей стороны в части реализации и процедур безопасности. Однако, по моему опыту, после того, как система установлена и правильно настроена, она становится прозрачной и значительно снижает нагрузку на различные участвующие команды.
Вы можете прочитать больше об этом здесь:
Мы используем OpenLDAP для хранения:
Он стабилен, легко расширяется, имеет много документации и функций интеграции, поэтому я рекомендую его.
Это может немного упростить вашу задачу: используйте ssh-copy-id [-i [identity_file]] [user@]master-host для подключения с каждого из этих серверов к одному из них. Использовать clusterssh отдать эту команду сразу всем серверам. Затем скопируйте authorized_keys keys файл от главного хоста ко всем остальным хостам: например, с участием clusterssh и scp. Так просто, быстро, красиво и ... один раз :)
Возможно, вас заинтересует концепция ssh-agent, в которой вы можете позволить соединению ssh-client запрашивать "назад" через ssh-соединение (я), используемое для перехода к текущему местоположению с учетными данными.
Это очень удобно.