Советы по управлению ключами SSH


13

Какую лучшую практику вы нашли для управления большим количеством пар ключей SSH?

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

Моя домашняя сеть состоит из моего ноутбука (ubuntu), двух рабочих столов (двойная загрузка ubuntu / fedora, двойная загрузка fedora / windows) и мультимедийной системы (ubuntu). На работе у меня есть свой личный ноутбук (который я использую для работы из дома), мой рабочий стол (fedora), производственная система (RHEL) и ноутбук с windows (вздох) и VM (fedora). Пока все хорошо.

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

Но теперь приходит Hadoop, большой кластер из более чем 100 систем, с еще большей сложностью, большим количеством пользователей и большим количеством пар ключей. Теперь мне нужно управлять ключами.

(Мне нужно уточнить. Я являюсь разработчиком программного обеспечения, консультирующимся с клиентом, который развертывает кластер Hadoop. Им нужно управлять ключами. Многие будут получать доступ к кластеру, которому нужно будет разместить свои открытые ключи в системе. Как резидент Linux savant, они попросили меня о помощи. Я посоветовал нанять системного администратора, но пока они не делают, я помогаю)

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

Какую наилучшую практику вы нашли для управления большим количеством ключей?

Спасибо!


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


Вы говорите о пары ключей пользователя или хоста? sshfpрешает проблему с ключом хоста, помещая подписи открытого ключа в DNS. Для учетных данных пользователя вы можете посмотреть либо сертификаты OpenSSH, либо использовать что-то вроде Spacewalk или puppet, чтобы сохранить все пары ключей в центральном месте и развернуть их по мере необходимости. Похоже, вы, вероятно, хотите последнее, так как вы просто настроили бы новый сервер в качестве клиента и затем развернули бы последнюю версию файла.
Братчли

У меня есть другой ноутбук (fedora) для сетевых дисков MyBook Live (под управлением linux), два встроенных рабочих стола, ожидающих жестких дисков, и планы еще на два для создания домашнего кластера hadoop (обучение). Да, мне нужно понять управление ключами.
ChuckCottrill

Ответы:


12

Как правило, у вас не должно быть более 1 ключа на клиентский компьютер (с акцентом на «в целом»). Я не уверен, правильно ли я понимаю ваш вопрос, но если вы говорите, что у вас есть отдельный ключ для каждой удаленной системы, то вы определенно делаете это неправильно.

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

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


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

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

Другой способ - воспользоваться новой функцией в ssh. Это директива конфигурации называется AuthorizedKeysCommand. По сути, это команда, которую sshd будет запускать каждый раз, когда нужно найти открытый ключ. Команда просто записывает открытый ключ запрашиваемого пользователя в его STDOUT. Это в основном используется, когда у вас нет смонтированных домашних каталогов, но все еще есть центральный сервер аутентификации ( FreeIPA использует это).

Конечно, вы можете выполнять другие действия, такие как cron job rsync /homeс центрального сервера. Но это не обычная практика.


У меня дома 8 машин и переменное количество «серверов» в облаке (масштабируется по мере необходимости). Было бы глупо иметь 300 клиентских ключей, когда я масштабирую до 300 экземпляров сервера. Итак, у меня есть 16 открытых ключей (по 2 пользователя на каждый из 8 хостов). Для жестких машин я нажимаю клавиши каждые 3 месяца. Для облачных экземпляров они интегрированы в пользовательское изображение.
Skaperen

2

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

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

если вы посмотрите на фактические ключи, хранящиеся в файле * author_keys *, вы увидите, что они уже содержат понятную человеку мета-информацию о происхождении ключа. Например, открытый ключ для user@fooобычно имеет следующую запись:

ssh-rsa AAAAB3Nza...LiPk== user@example.net

таким образом, очень легко проверять / извлекать / удалять определенные ключи (прикрепленные к определенным пользователям) из файла * authorized_keys *.

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

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


Каждый пользователь будет генерировать свои собственные ключи, я полагаю, вы говорите, что каждый пользователь должен указать имя пользователя @ имя хоста как часть источника ключа. Что означает, что скрипт, который обеспечивает это имя пользователя @ hostname, должен быть предоставлен, верно?
ChuckCottrill

это зависит от того, как они создают свои ключи; например ssh-keygen, добавит комментарий к этой форме user@host; другие генераторы ключей (например, те, что поставляются с замазкой) могут этого не делать. но да, это должно быть тривиально сделать небольшой скрипт, который гарантирует, что каждый ключ имеет поле комментария, которое идентифицирует комбинацию пользователь / хост.
umläute

1

Последние OpenSSH позволяют получать ssh-ключи из LDAP, см. «AuthorizedKeysCommand» на справочной странице sshd_config . Лично я предпочел бы сертификаты OpenSSH, а не ключи, см. Http://blog.habets.pp.se/2011/07/OpenSSH-certificates . Вы можете управлять ключами с помощью любого менеджера конфигурации, например cfengine, puppet, chef, salt ...


0

Другой способ, который очень прост в реализации и обеспечивает немного большую гибкость в плане добавления нескольких пользователей, заключается в использовании. https://userify.com/

Он позволяет вам определять разные группы серверов и включать или отключать ключи для разных пользователей для этих серверов.

Супер простая установка и управление.

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.