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

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

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

Источник

3 ответа

Решение

Я нашел этот вопрос, пытаясь ответить на него сам. После некоторых поисков и экспериментов я нашел несколько других вариантов для этого. Я собираюсь пропустить часть о распределении ключей в качестве альтернативы, так как Мэтт Симмонс рассказал об этом. Кроме того, я знаю, что бывают ситуации, когда этого недостаточно. Например, если вы являетесь 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. Существуют и другие различные (вероятно, менее проверенные и проверенные) патчи для добавления аналогичной функциональности. Например, есть https://github.com/mizzy/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 для управления учетными записями, вы также сможете использовать их для управления ключами.

Источник
Другие вопросы по тегам