Централизованная система управления ключами SSH?

27

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

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

Кто-нибудь знает такую систему, коммерческую или с открытым исходным кодом?

ПРИМЕЧАНИЕ. Чтобы уточнить, нам необходимо управление ключами для довольно большого количества облачных серверов (подобных EC2) и небольшого количества пользователей услуг. Я предполагаю, что патч LDAP +, предложенный ниже, может быть подходящим.

ssh cloud keys

— SyRenity
источник

7

Только я думаю, что «закрытые ключи и облако» - это как «пить и водить». Оба смеются отдельно, но никогда не идут вместе.

— mailq

1

«Облако» - это, вероятно, неправильное слово - звучит так, как будто они хотят получить централизованную аутентификацию с единообразием по всему миру

— voretaq7

Здравствуй. Именно то, что мы ищем.

— SyRenity

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

— Том Х

Userify охватывает то, что вы ищете (см. Serverfault.com/questions/647797/… )

— Джеймисон Беккер,

8

Есть много способов сделать это. Хранилище ключей LDAP упоминалось пару раз, и я сделал это, и оно работает, насколько это возможно. У LDAP есть свои собственные управленческие курьезы, которые требуют некоторого обучения.

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

— romble
источник

Этот подход, безусловно, является хорошим, и, как указывает Уомбл, у него есть преимущество в том, что серверы работают и работают (и становятся доступными) в случае, если LDAP не работает - каждая система с поддержкой LDAP должна (осмелюсь сказать, должна ) иметь хотя бы один пользователь, чьи ключи выталкиваются так, как описывает Womble. Недостатком является то, что вы должны выполнить настройку для де-авторизации пользователей. Не проблема для «экстренной учетной записи» только с несколькими авторизованными пользователями. Большая проблема для большого количества аккаунтов :)

— voretaq7

1

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

— Уомбл

Я согласен, к сожалению, деловые потребности / менталитет не делают: Паранойя во многих местах (включая мою) диктует, что изменения конфигурации происходят в нерабочее время, но новый персонал / уходящий персонал может произойти в любое время: - /

— voretaq7

1

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

— womble

2

Здравствуй. Так что хорошей идеей было бы использовать Puppet для этого, например?

— SyRenity

23

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

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

Публичная половина предоставляется вам (любым механизмом, который вы хотите: веб-форма, электронная почта, «дай-мне-на-CD»), чтобы быть централизованным, как вы хотите. В некоторых местах хранятся открытые ключи в LDAP. Другие выталкивают authorized_keysфайлы, используя свою систему развертывания.

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

На каждом из наших сайтов есть пара серверов LDAP, синхронизированных с нашим ведущим с репликацией LDAP, что обеспечивает согласованность (и доступность) данных в каждом месте.

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

— voretaq7
источник

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

— SyRenity

1

@SyRenity: LDAP поддерживает репликацию и кластеризацию, поэтому очень хорошо масштабируется

— Хуберт Карио

@SyRenity Теоретически вы можете поддерживать неограниченное количество компьютеров в неограниченном количестве мест (подумайте «Действительно большое развертывание Active Directory» - AD - это в основном LDAP с некоторыми модными аксессуарами). Для пользователей сервисов я предлагаю стандартизировать их в вашей среде и распространять стандартизированные файлы /etc/passwdи /etc/groupфайлы (позволяет компьютерам нормально работать и запускать / запускать связанные сервисы, даже если LDAP недоступен)

— voretaq7

@ voretaq7 То есть пользователи службы будут управляться отдельно от LDAP через управление конфигурацией?

— SyRenity

@SyRenity yes - и, что более важно, доступно для сервисов, которые их используют, если LDAP не работает . Планируйте неудачи, иначе вы столкнетесь с катастрофами.

— voretaq7

9

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

Тем не менее, я мог видеть вариант использования для своего рода централизованного хранилища открытых ключей пользователей. Один из вариантов - хранить открытые ключи в OpenLDAP - последние версии OpenSSH могут считывать ключи из LDAP.

— EEAA
источник

2

Есть ли открытый ключ LDAP в основном в OpenSSH? Я знаю только о патче LPK (за который я могу ручаться - он прекрасно работает). Также +1 за сохранение закрытых ключей в секрете.

— voretaq7

@ voretaq7 Полагаю, я слышал, что он сливается с магистралью, но сам пока не проверял. Мы создаем общие домашние каталоги через NFS, так что мы позаботимся о нашем распределении ключей для нас.

— EEAA

+1 ну я этого не знал. это спасло бы меня от неприятностей. вот теперь в моем списке вещей, чтобы посмотреть.

— Том Х

1

Я знаю, что это немного более старый вопрос, но Google возвращает его довольно высоко при поиске такого рода вещей.

Для тех из нас, кто ищет решение помимо LDAP, я просто нашел проект "SKM": https://sites.google.com/site/jeromeboismartel/code-s-corner/ssh-key-management-with-skimp

— fukawi2
источник

1

Есть много отличных коммерческих и открытых решений, таких как Userify [1] (там, где я работаю), Universal Key Manager [2], SSH Key Box [3] и т. Д. Это зависит от ваших потребностей и от того, кто вы искать что-то, что централизует управление и децентрализует работу (чтобы ваши серверы не полагались на центральные полномочия для входа в систему ... в этом случае вы не сможете войти ни на один из ваших серверов, если, скажем, ваш Сервер LDAP не работает!)

Смотрите также это Slant обсуждение:

https://www.slant.co/topics/8010/~managers-for-ssh-keys

— Джеймисон Беккер
источник