Вот такая ситуация.
У меня 5000 серверов разбиты на "группы" по 100.
Каждая «группа» имеет 1 пару ключей SSH, которая разрешает доступ к любому из серверов в группе. У меня 60 пользователей (некоторые люди, некоторые нет), которым нужен доступ ко всем 5000 серверам. Все пользователи находятся на разных компьютерах, некоторые ПК (замазка) некоторые Linux (ssh).
вручную: Добавление нового сервера в «группу» кажется простым. Добавление / обновление пользователя было бы кошмаром. Добавление / обновление новой группы было бы кошмаром. Синхронизация групповых ключей с пользовательскими станциями была бы кошмаром.
ssh-agent / pageant работает для одного пользователя на одной рабочей станции, но не кажется масштабируемым.
Есть ли программное обеспечение, которое может справиться с этим управлением? Может быть, какой-то прокси? Или протокол автоматического извлечения ключей на основе сервера?
РЕДАКТИРОВАТЬ
Я ценю помощь до сих пор, однако я думаю, что я не совсем понимаю или не понимаю предложения.
Дополнительная информация: каждый из серверов представляет собой удаленную систему без доступа к Интернету, и скорость соединения обычно низкая. Каждый сервер имеет только одну запись в файле authorized_keys. Я не хочу и не нуждаюсь в индивидуальных пользовательских ключах. Я просто хочу, чтобы много разных людей использовали один и тот же ключ для каждой группы. Сейчас мы используем аутентификацию по паролю и храним список паролей для каждой группы на листе бумаги. Это работает для нашей команды. Но это не сработает, если мы перейдем на аутентификацию по ключу.
Есть ли смысл в предложениях? Если да, не могли бы вы уточнить детали реализации.
За исключением того, что он помещает свой собственный ключ на сервер, где вместо этого мне нужно использовать ключи, которые я ему предоставляю.
Я попросил пару человек об этом. Я добавил способ указать пару ключей в последней версии.
https://github.com/skavanagh/KeyBox/releases
https://github.com/skavanagh/KeyBox#supplying-a-custom-ssh-key-pair
Сообщите мне, если у вас возникнут проблемы. Спасибо!
Проверять, выписываться Userify, управляет учетными записями пользователей, ключами SSH и ролями sudo, и ему не нужен центральный сервер каталогов, который может выйти из строя (заблокировать вас из всех ваших экземпляров ... были там.)
Довольно легко развернуть с использованием пользовательских данных AWS (на вкладке «Дополнительно» при запуске экземпляра) или вставить его прямо в сценарий UserData для группы автомасштабирования или всякий раз, когда вы запускаете экземпляр вручную, что здорово, потому что оно работает еще до того, как вы войдите в систему. (Или вы можете просто вставить однострочник в консоль сервера, но это не так весело ..)
Он поддерживает Chef, Puppet, Ansible, CloudFormation / CloudInit и TerraForm для развертывания, и каждый пользователь (разработчик / администратор / и т. Д.) Получает свой собственный веб-логин для обновления нескольких ключей (просто вставьте). интерфейс приличный, довольно безболезненный.
Для ваших конкретных потребностей (то есть большого количества серверов в отдельных группах с отключенными / медленными веб-соединениями) я бы использовал саморазмещающийся Userify Express, установил очень высокое время опроса (не менее 90 секунд) и создал поддельные (не- человек) пользователи - по одному на каждую группу. Конечно, вы можете просто использовать настоящие учетные записи пользователей, поскольку вы можете удалить пользователей-людей с большой группы серверов или со всех серверов одним щелчком мыши в Userify, а затем сами пользователи могут распространять свои собственные ключи, просто обновляя свой ящик для ключей. Userify нужен только доступ https (443 TCP) с серверов к вашему серверу Userify.
(Хотя вы могли бы просто делиться такими ключами, иметь у людей свои собственные ключи безопаснее; разделение пользователей-людей с доступом к индивидуальной учетной записи нарушает ведение журнала и аудит на конечных серверах, хотя это не похоже на то, что здесь проблема, но большая часть безопасности структуры политик, такие как HIPAA и PCI, требуют одного человека-пользователя для доступа к индивидуальной учетной записи и запрета совместного использования кредитов. Тем не менее, вы можете сделать это в Userify и даже распределить закрытые ключи по группам серверов, но этот метод не рекомендуется, за исключением службы / системы / автоматизации учетные записи, такие как резервные копии или системы управления конфигурацией, такие как Ansible.) (отказ от ответственности: я работаю в Userify и помогал разработать исходную модель Userify.)
Вы можете посмотреть на использование LDAP с открытыми ключами http://code.google.com/p/openssh-lpk/
Это значительно упростит повторную выдачу ключа пользователю в случае его взлома. Закрытый ключ каждого пользователя может управляться этим пользователем или сохраняться в хранилище, к которому у него есть доступ (например, в домашнем каталоге).
Похоже на Брелок подойдет для ваших нужд.
Из страница вики:
Keyholder - это набор сценариев, которые позволяют группе пользователей использовать SSH-ключ, не делясь закрытым ключом с членами группы. Это достигается запуском заблокированного экземпляра ssh-agent и запуском ssh-agent-proxy перед ним.
После запуска и настройки ssh-agent-proxy пользователи проходят проверку подлинности, задав SSH_AUTH_SOCK указать на сокет прокси, а затем ssh-agent-proxy позволит пользователям аутентифицироваться только с помощью ключа, который им разрешено использовать на основании членства в локальной группе unix.
Конфигурация выглядит так:
---
group-name: ["ssh:key:fingerprint"]
И ключи хранятся отдельно, доступны только root.
Кто-то с доступом к root должен «активировать» службу держателя ключей один раз после перезагрузки сервера, тогда любой с соответствующим членством в группе может использовать ключи, которые хранятся в держателе ключей ssh_agent.
Поскольку я изначально написал этот ответ, ключевой держатель был извлечен из репозитория марионеток Викимедиа и получил надлежащую обработку, чтобы стать отдельным проектом. Теперь его использовать должно быть намного проще, особенно для пользователей debian, поскольку сценарии упаковки debian и метаданные включены в отдельный филиал из исходный репозиторий.