OpenSSH с открытыми ключами из базы данных

Можно ли получить открытые ключи из базы данных вместо файла авторизованных ключей?

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

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

Так,

1. Прежде всего, RedHat (и варианты) имеют поддерживаемый патч для OpenSSH , который добавляет AuthorizedKeysCommandи AuthorizedKeysCommandRunAsварианты. Патч был объединён с openssh 6.2. Цитировать из справочной страницы :

   AuthorizedKeysCommand

   Определяет программу, которая будет использоваться для поиска открытых ключей пользователя. Программа будет вызываться с ее первым аргументом - именем авторизованного пользователя, и она должна выдавать в стандартных выходных строках AuthorizedKeys (см. AUTHORIZED_KEYS в sshd (8)). По умолчанию (или если задана пустая строка) AuthorizedKeysCommand не запускается. Если AuthorizedKeysCommand не может успешно авторизовать пользователя, авторизация переходит к AuthorizedKeysFile. Обратите внимание, что этот параметр действует только при включенной аутентификации PubkeyAuthentication.

   AuthorizedKeysCommandRunAs

   Указывает пользователя, под учетной записью которого запускается AuthorizedKeysCommand. Пустая строка (значение по умолчанию) означает, что используется авторизованный пользователь.

   Сегодня вечером в своих экспериментах я обнаружил, что из коробки это не работает из-за политик SELinux по умолчанию. Вы можете обойти это, отключив принудительное применение SELinux с помощью setenforce 0. Поскольку использование SELinux, вероятно, является плохой идеей, вместо этого вы можете создать правильную политику. В моем случае это было так же просто, как попытка войти в систему с помощью AuthorizedKeysCommandопции, настроенной, /etc/ssh/sshd_configа затем с помощью audit2allow -a -M local && semodule -i local.pp. Это в основном просматривает журналы аудита и находит вещи, которые были предотвращены, и генерирует исключения для них. Если у вас есть другие вещи, которые могут попасть в белый список, вам, вероятно, стоит узнать больше о том, audit2allowчтобы убедиться, что вы правильно выбрали новую политику.

2. Существуют другие различные (вероятно, менее проверенные и проверенные) патчи для добавления аналогичной функциональности. Например, есть openssh-script-auth . Вы также можете найти патч, который использовал RedHat, и применить его напрямую. Быстрый бой Googling раскрывает https://launchpadlibrarian.net/89063205/openssh-5.3p1-authorized-keys-command.patch и https://launchpadlibrarian.net/105938151/openssh-authorized-keys-command.patch, которые основанный на версиях RH, но которые были обновлены для более новых версий OpenSSH.

3. Патч OpenSSH для поиска ключей непосредственно из какого-то магазина (например, как это сделали GitHub, CodeBaseHQ и другие). Насколько мне известно, GitHub не открывал этот патч с открытым исходным кодом, но я знаю, что в прошлом я встречал версии для поиска ключей MySQL и PostgreSQL. Я пытался найти их снова только сейчас, но мне не повезло.

4. Есть также несколько вариантов на основе FUSE. Например, существует LPKFuse, который позволяет вам обслуживать открытые ключи из LDAP путем изменения AuthorizedKeysFileместоположения на один в файловой системе LPKFuse. LPKFuse FS создает виртуальные файлы, содержимое которых поддерживается полями с сервера каталогов.

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

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

Кроме того, вы можете захотеть увидеть этот вопрос: Система для распространения открытых ключей SSH

Я считаю, что в более новых версиях openssh вы можете хранить ключи в записи LDAP пользователя. Если вы уже используете LDAP или AD для управления учетными записями, вы также сможете использовать их для управления ключами.