Задний план: Я добавил аутентификацию токена OTP на свой веб-сервер. Я изменил /etc/ssh/sshd_config файл с ForceCommand /token/script команда.
Проблема: У меня есть локальный экземпляр Jenkins, подключающийся к веб-серверу для развертывания; Дженкинс не может вводить информацию о токене или отвечать на телефонные звонки (хотя, кто знает, держу пари, есть даже плагин для этого!).
Возможное решение: использовать ~/user/authorized_keys параметр command для принудительного выполнения сценария токена на всех ключах, кроме ключа, используемого jenkins.
Вопрос: Насколько менее безопасен, чем глобальный подход sshd_config, подход authorized_keys? Считаете ли вы это приемлемым компромиссом? Есть ли лучшее решение (которое позволяет Дженкинсу выполнять развертывание ведомых устройств, в то время как все остальные остаются заблокированными с помощью аутентификации по токену?).
Я пробовал оба подхода, и оба работают как шарм. Второй подход я считаю более практичным с точки зрения развертывания, но он вызывает у меня какие-то внутренние красные флажки. Не знаю, преследую ли я привидений (с красными флажками). Обсуди!
Использовать Match команда в вашем sshd_config применять разные правила к jenkins пользователь, чем вы делаете для других пользователей:
- Соответствие: Вводит условный блок. Если все критерии в строке Match удовлетворены, ключевые слова в следующих строках переопределяют те, которые заданы в глобальном разделе файла конфигурации, до тех пор, пока не появится другая строка Match или не будет конец файла.
Увидеть sshd_config страница руководства для полной документации.