Система распространения открытых ключей SSH

26

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

Проблема в том, что открытыми ключами, установленными в системах, нужно как-то управлять. Люди приходят и уходят, ключи могут быть скомпрометированы, обязанности меняются (лицо, уполномоченное войти в одну систему сегодня, может получить право доступа к другой системе завтра). В настоящее время мы управляем этим путем ручного редактирования файлов ~ / .ssh / authorized_keys для каждой учетной записи, которая нуждается в этом, но это много работы и подвержено ошибкам.

Есть ли готовый инструмент для управления открытыми ключами в таком сценарии? У вас есть свои решения? Или вся эта идея управления системами таким образом ошибочна?

ssh ssh-keys public-key Яцек Конечны
источник
Я не могу ответить на ваш вопрос, но когда я прочитал его, я услышал, как он кричит о какой-то системе баз данных.
Джон Гарденье
Действительно, я вижу место для базы данных на «бэкэнде» («сервере ключей»), хотя я бы предпочел ограничить доступ к базе данных и распределить ключи по каналу SSH. Не открывать никакие другие каналы связи в управляемых системах. На самом деле я чувствую, что могу реализовать такой инструмент / систему самостоятельно, хотя предпочел бы что-то готовое и доказавшее свою эффективность.
Яцек Конечны

Ответы:

18

Как уже упоминалось в Pulegium, любое общее программное обеспечение для управления конфигурацией, такое как Puppet , Chef , Bcfg2 или cfengine, может выполнить эту задачу.

Поскольку authorized_keys файл не так сложен, вы можете также использовать Rsync или (D) SCM как мерзавец или рт.ст. для управления этим файла. У вас есть «главный» файл на одном из ваших серверов, который вы обслуживаете через rsync / git / hg /…. На каждом другом сервере вы запускаете задание cron, которое периодически извлекает главную копию (если она была изменена) и копирует ее в правильное локальное местоположение. Черт, это будет работать даже с чистым HTTP или FTP.

Суть заключается в следующем: имейте одну «главную» копию вашего файла author_keys и обновляйте ее. Позвольте "клиентам" (компьютерам, на которых должен быть установлен текущий файл author_keys) получить его с вашего главного сервера и развернуть его локально.

Joschi
источник
1
Мы с комфортом используем puppet для управления ~ 200 серверами Linux (ключи публикации - это просто файл, который используется как атрибут пользователя).
ForgeMan
1
Я приму этот ответ, кажется, я не поправлюсь. Кажется, для меня есть выбор: 1. Сохранить все как есть. 2. Собрать собственную цепочку инструментов для управления файлами author_keys. 3. Использовать какой-то существующий универсальный инструмент для управления серверами, например, Puppet или Chef… хотя эти инструменты кажутся слишком большими для это простое задание. 4. Используйте другой механизм аутентификации / авторизации (например, Kerberos)… хотя это также кажется слишком сложным инструментом для простой задачи. Спасибо.
Яцек Конечны
эта система так же безопасна, как и канал, по которому передается мастер-копия.
yrk
1
Ansible - это очень легкая система CM, в которой есть модуль для взлома авторизованных файлов ключей через ssh. См. Ansible.cc/docs/modules.html#authorized-key
RS
11

Для OpenSSH имеется исправление, позволяющее использовать открытые ключи с сервера LDAP, но это действительно имеет смысл, только если проверка подлинности / учетных записей также выполняется на этом сервере LDAP (именно так настроена моя среда). Кроме того, он безопасен только для вашей конфигурации LDAP (поэтому вы хотите использовать SSL и проверочные ключи).

См. Http://code.google.com/p/openssh-lpk/ для исправления и получения дополнительной информации. Я не знаю ни одной ОС, которая поставляется с этим патчем по умолчанию, но если вы используете FreeBSD, это дополнительный патч, если вы используете OpenSSH из портов.

voretaq7
источник
1
Между прочим, использование pam_ldap также позволяет решить проблему «кто-то, у кого есть права доступа к машине A сегодня, может быть, и не имеет права доступа к ней завтра» - прочитайте pam_ldap, если вы заинтересованы в этом аспекте ...
voretaq7
5

я запускаю очень простое решение, которое делает то же самое с firewall-rules

пример файла hosts.conf:

192.168.0.1
192.168.2.99
192.168.2.100

distribute.sh:

#!/bin/bash
for d in `cat ./hosts.conf`; do
  echo "copying to $d ...";
  scp /root/.ssh./authorized_keys root@$d:/root/.ssh./authorized_keys
done;

вот и вся магия :-)

bmaeser
источник
5

В настоящее время я проверяю SSH KeyDB . Он предназначен именно для этого, администрирует роли, серверы и пользователей, распределяет пользовательские ключи, собирает ключи хостов и т. Д. Он даже имеет то, что называется «местоположениями».

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

andsens
источник
1

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

pboin
источник
1

У вас есть две (которые обычно превращаются в 3) разные проблемы, которые вы пытаетесь решить:

  • Аутентификация (Кто ты?)
  • Авторизация (Вам разрешен доступ к этому серверу?)
  • Аудит (что вы делали?)

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

Вот где такие решения, как Kerberos, вступают в игру. В мире Windows Active Directory решает эту проблему. В мире Unix существует множество вариантов, и это хорошо и плохо.

Я бы ознакомился с проектом Red Hat FreeIPA , представляющим собой пакет программного обеспечения, который позволяет легко и быстро запустить систему, подобную AD, Kerberos / LDAP / DNS.

duffbeer703
источник
Я понимаю разницу между аутентификацией, авторизацией и аудитом. А авторизованные ключи SSH предоставляют данные как для аутентификации, так и для авторизации. Это далеко не идеально, но это просто. А простота часто является большим преимуществом, в том числе и в плане безопасности. Kerberos с его сложной инфраструктурой может потерпеть неудачу в безопасности многими способами, чем ssh с его файлами author_keys. Впрочем, это не значит, что одно или другое безопаснее.
Яцек Конечны
Управление файлами author_keys - это np для нескольких серверов, но вы быстро достигнете точки, когда невозможно управлять. Я не пытался сказать, что это «плохое» решение. Аналогично, сложности в Kerberos не подходят для двух серверов ... но инвестиции в проектирование / реализацию kerberos того стоят в большей среде.
duffbeer703
1

Вы можете использовать Bcfg2 с bcfg2-счетов для распространения authorized_keys. В качестве дополнительного бонуса у вас будет возможность контролировать пользователей и группы.

Bcfg2 позволяет без боли обслуживание /etc/ssh/ssh_known_hostsс SSHbase , а также.

Мирослава
источник