SSH: Как найти механизм аутентификации пользователя, используемый в конфигурации sshd во время выполнения

Я хотел бы изменить файл sshd_config для запуска одного сценария, если пользователь ssh подключен с паролем, и другого сценария, если пользователь ssh подключен к серверу с использованием подписанного сертификата SSH. Я вижу, это может быть возможно с комбинацией Match и ForceCommand, но мне трудно понять, как определить, использовал ли пользователь PasswordAuthentication для входа или SSH Cert для входа на сервер.

Например, что-то вроде ниже:

Соответствие (если пользователь использовал пароль) ForceCommand / usr / sbin / passwordscript

Соответствие (если пользователь использовал pubkey) ForceCommand / usr / sbin / pubkeyscript

Match (если пользователь использовал TrustedUserCAKeys (?)) ForceCommand / usr / sbin / sshcertdscript

Есть ли способ узнать, как пользователь пытается выполнить ssh на сервере, будь то пароль, открытый ключ или TrustedUserCAKeys (SSH Cert)?

Заранее спасибо..

— Quick Learner
источник

В authorized_keys файл , вы можете указать команду для использования при аутентификации с определенной парой ключей. Вы также можете установить переменную окружения, используя environment опция:

command="/path/script",command="KEY_WAS_USED=yes" ssh-rsa ...

И затем вы можете проверить наличие переменной в каком-либо скрипте запуска, чтобы выполнить ваш «неключевой» (пароль) скрипт.

— Martin Prikryl
источник

Спасибо, Мартин. Может быть, если пользователь настраивает переменную окружения, чтобы избежать выполнения определенного сценария. Например: если я хочу иметь MFA в случае использования пароля, а не в случае использования ключей, тогда пользователь "может" установить эту переменную среды, которая KEY_WAS_USED = yes, и мы можем увидеть это значение и для случая использования пароля. Это может быть возможно. Я прав? Просто чтобы быть любопытными, нет никакого способа узнать, что в файле sshd_config во время выполнения?

— Quick Learner

Я знаю, что это не идеальное решение, но я не знаю ничего лучше.

— Martin Prikryl