Многочисленные пользователи, Несколько серверов, управления ключами SSH
За исключением того, что он помещает свой собственный ключ на сервер, где он мне нужен использовать ключи, которые я ему предоставляю.
У меня было несколько просьб об этом. Я добавил способ указать пару ключей в последней версии.
https://github.com/skavanagh/KeyBox/releases
https://github.com/skavanagh/KeyBox#supplying-a-custom-ssh-key-pair
Сообщите мне, если вы есть какие-либо проблемы. Спасибо!
Вы можете посмотреть на использование LDAP с открытыми ключами http://code.google.com/p/openssh-lpk/
Это значительно упростило бы повторную выдачу ключа пользователю в случае его взлома. Закрытый ключ каждого пользователя может управляться этим пользователем или сохраняться только в хранилище, к которому у него есть доступ (например, в домашнем каталоге).
Проверьте Userify, управляет учетными записями пользователей, SSH ключами и sudo ролями, и не нуждается в центральном сервере каталогов, который может выйти из строя (блокируя вас от всех ваших экземпляров... были там. )
Это довольно просто развернуть, используя пользовательские данные AWS (во вкладке Advanced при запуске экземпляра) или вставить их прямо в сценарий UserData для группы автомасштабирования или всякий раз, когда вы запускаете экземпляр вручную, что здорово, потому что это работает еще до того, как вы войдете в систему. (Или вы можете просто вставить одну строку в консоль сервера, но это не так весело...)
Она поддерживает Chef, Puppet, Ansible, CloudFormation/CloudInit и TerraForm для развертывания, и каждый пользователь (разработчик/admin/etc) получает свой собственный веб-логин для обновления нескольких ключей (просто вставьте). приличный интерфейс, довольно безболезненный.
.Похоже, Keyholder очень хорошо подойдет для ваших нужд.
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 и метаданные включены в отдельную ветвь репозитория исходных текстов .