Можно ли получить открытые ключи из базы данных вместо файла authorized_keys?
Я хотел бы использовать такую настройку для управления ssh-доступом к таким вещам, как репозитории git, для нескольких пользователей без необходимости воссоздавать файл authorized_keys каждый раз при изменении или добавлении открытого ключа.
Я нашел этот вопрос, когда сам пытался на него ответить. После некоторых поисков и экспериментов я нашел несколько других вариантов для этого. Я пропущу часть о распространении ключей в качестве альтернативы, поскольку Мэтт Симмонс рассказал об этом. Кроме того, я знаю, что бывают случаи, когда это не достаточно хорошо. Например, если вы являетесь GitHub и должны хранить миллионы открытых ключей для одного пользователя, постоянное обновление файлов SSH authorized_keys и их синхронизация между потенциально десятками и сотнями периферийных блоков нецелесообразно или нежелательно.
Так,
Прежде всего, RedHat (и его варианты) имеют поддерживаемый патч для OpenSSH, который добавляет AuthorizedKeysCommand
и AuthorizedKeysCommandRunAs
параметры. Патч был добавлен в openssh 6.2. Цитата из страница руководства:
AuthorizedKeysCommand
Задает программу, которая будет использоваться для поиска открытых ключей пользователя. Программа будет вызвана с первым аргументом - именем авторизованного пользователя и должна выдать на стандартный вывод строки AuthorizedKeys (см. AUTHORIZED_KEYS в sshd (8)). По умолчанию (или при установке на пустую строку) AuthorizedKeysCommand не запускается. Если AuthorizedKeysCommand не может успешно авторизовать пользователя, авторизация переходит в AuthorizedKeysFile. Обратите внимание, что этот параметр действует только при включенной аутентификации PubkeyAuthentication.
AuthorizedKeysCommandRunAs
Указывает пользователя, под учетной записью которого запускается AuthorizedKeysCommand. Пустая строка (значение по умолчанию) означает, что используется авторизованный пользователь.
В своих сегодняшних экспериментах я обнаружил, что из коробки это не работает из-за политики SELinux по умолчанию. Вы можете обойти это, отключив принудительное применение SELinux с помощью setenforce 0
. Поскольку включение SELinux, вероятно, плохой idea, вместо этого вы можете создать правильную политику. В моем случае это было так просто, как попытка войти в систему с AuthorizedKeysCommand
опция настроена в /etc/ssh/sshd_config
а затем используя audit2allow -a -M local && semodule -i local.pp
. Это в основном просматривает журналы аудита и находит вещи, которые были предотвращены, и генерирует исключения для них. Если у вас, вероятно, есть другие вещи, которые могут попасть в белый список, вам, вероятно, следует узнать больше о audit2allow
чтобы убедиться, что вы правильно поняли новые правила.
Существуют и другие различные (вероятно, менее проверенные и надежные) исправления для добавления аналогичных функций. Например, есть openssh-script-auth. Вы также можете найти патч, который использовала RedHat, и применить его напрямую. Быстрый поиск в Google раскрывает https://launchpadlibrarian.net/89063205/openssh-5.3p1-authorized-keys-command.patch и https://launchpadlibrarian.net/105938151/openssh-authorized-keys-command.patch которые основаны на версиях RH, но были обновлены для более новых версий OpenSSH.
Патч OpenSSH для выполнения поиска ключей прямо из какого-либо магазина (например, GitHub и CodeBaseHQ и другие сделали). Насколько мне известно, GitHub не открыл исходный код этого патча, но я знаю, что в прошлом мне встречались версии для поиска ключей MySQL и PostgreSQL. Я пытался найти их снова только сейчас, но безуспешно.
Есть также несколько вариантов на основе FUSE. Например есть LPKFuse который позволяет вам обслуживать открытые ключи из LDAP, изменяя AuthorizedKeysFile
расположение к одному в файловой системе LPKFuse. LPKFuse FS создает виртуальные файлы, содержимое которых поддерживается полями с сервера каталогов.
В общем, я считаю, что вариант №1 - безусловно лучший, поскольку он официально поддерживается RedHat. Кроме того, он позволяет вам помещать в этот сценарий любую логику (включая обращение к базе данных) на любом языке, который вы хотите.
Насколько мне известно, OpenSSH не имеет такой возможности. Лучше всего, чтобы сценарий автоматически регенерировал файл каждую ночь (или так часто, как это необходимо).
Кроме того, вы можете захотеть увидеть этот вопрос: Система распространения открытых ключей SSH
Я считаю, что в более новых версиях openssh вы можете хранить ключи в записи LDAP пользователей. Если вы уже используете LDAP или AD для управления учетными записями, вы также сможете использовать их для управления ключами.