Назад | Перейти на главную страницу

Двухфакторная аутентификация OpenSSH в сочетании с Kerberos / открытым ключом

Я пытаюсь реализовать двухфакторную аутентификацию для OpenSSH. Среда - Centos 7 (ядро: 3.10.0-229.1.2.el7.x86_64) с OpenSSH_6.6.1p1, OpenSSL 1.0.1e-fips 11 февраля 2013 г. У нас развернуты Active Directory (LDAP) + Kerberos. Спецификация следующая:

Для выполнения процесса аутентификации второго фактора доступен сторонний модуль PAM, который ничего не знает о Kerberos. Итак, вот что я сделал:

Поместите эти строки в / etc / ssh / sshd_config:

# To enable PAM - this will make sshd use PAM with configuration /etc/pam.d/sshd
UsePam yes
ChallengeResponseAuthentication yes

# To enable Kerberos and public key authentication - it will let sshd use existing Kerberos tickets
GSSAPIAuthentication yes

# Enable public key authentication
PubkeyAuthentication yes

# Password validation should be done via the KDC
PasswordAuthentication yes
KerberosAuthentication yes
KerberosOrLocalPasswd yes

# Kerberos / Public Key + PAM
AuthenticationMethods gssapi-with-mic,keyboard-interactive:pam publickey,keyboard-interactive:pam password,keyboard-interactive:pam
# (only supported for OpenSSH 6.2 or higher)

Раздел auth конфигурации PAM для sshd (/etc/pam.d/sshd)

auth       [success=ignore default=1] pam_localuser.so
auth       substack     password-auth
auth       [success=1 default=ignore] pam_localuser.so
auth       required     pam_2fa.so [...some arguments...]
auth       include      postlogin

Модуль pam_2fa.so отвечает за запрос и проверку второго фактора.

Что касается Kerberos, он делает почти все, что я хотел достичь. Однако для локальных учетных записей это приводит к двум последующим запросам пароля. Это моя основная проблема. Это связано с тем, что в этом случае, как и ожидалось, используется путь «пароль, keyboard-interactive: pam». (Мне нужен этот путь аутентификации, чтобы кто-то с учетной записью Kerberos, но без действующего билета, мог получить билет, введя пароль, а затем OTP.) Если я полностью удалю подстек пароля аутентификации из конфигурации PAM, тогда учетные записи Kerberos останутся работающими а локальные учетные записи остаются неработающими. Мне кажется, что утверждение KerberosOrLocalPasswd yes игнорируется, потому что UsePAM yes также присутствует. Однако sshd действительно продолжает использовать KDC для проверки пароля, потому что в противном случае он не работал бы и для учетных записей LDAP.

Итак, еще раз, чтобы прояснить, что я хочу реализовать здесь, это псевдокод, описывающий желаемую логику аутентификации:

if gssapi_auth_ok(principal) or pubkey_auth_ok(pubkey):
  return second_factor_auth(user, read_otp())
else:
  if is_local_account(user):
    if local_passwd_auth(user, read_password()):
      return second_factor_auth(user, read_otp())
    else:
      return AUTH_ERR
  else:
    if krb5_auth(principal, read_password()):
      return second_factor_auth(user, read_otp())
    return AUTH_ERR

Так что мой сценарий я считаю не слишком сложным или амбициозным, но я все еще не мог найти четкого способа его реализации, несмотря на то, что потратил дни на исследования и эксперименты. Не могли бы вы помочь мне найти решение?

Заранее большое спасибо!

  • У пользователя с существующим действующим билетом Kerberos нужно запрашивать только второй фактор.

Этого нельзя добиться с помощью PAM.

Успешная аутентификация на основе ключей, выполненная для sshd, обходит auth стек ПАМ. Сюда входит GSSAPI, который является требованием для проверки подлинности Kerberos на основе билетов. У него нет другого выбора, кроме как сделать это, поскольку PAM просто не был разработан с учетом этого типа аутентификации.

Настройка UsePAM yes делает следующее:

  • ChallengeResponseAuthentication и PasswordAuthentication зацепит auth стек PAM для проверки пароля. Любая форма аутентификации, кроме этих двух методов, будет не прикоснуться к auth стек.
  • При успешной аутентификации account стек PAM будет вызываться, чтобы определить, разрешен ли доступ аутентифицированному пользователю. (всегда)
  • В session стек PAM будет вызываться для обработки задач настройки сеанса.

Резюме: нет абсолютно никакого способа получить приглашение двухфакторной аутентификации, расположенное в auth стек, чтобы активировать кого-то, кто прошел аутентификацию с помощью ключа GSSAPI или ssh. Ты можешь использовать account и session стеки в сочетании с этими методами аутентификации, но это все, что касается PAM.

Я не знаю, как сделать с PAM то, что вы хотите, без написания нового модуля pam. PAM относительно сложен, и, по моему опыту, sshd взаимодействует с PAM и kerberos так, что всегда есть крайний случай, который просто не работает.

То, что вы хотите, может быть возможным, я просто не знаю, как это сделать. Если вам нужно только защитить ssh, я бы предложил использовать

ForceCommand  /path/to/2fa_executable 

в вашем sshd_config. Это позволит вам реализовать желаемую логику, недостатком является то, что для 2fa_executable необходимо установить идентификатор для чтения любых секретов 2fa.

На веб-сайте Duo Security есть пример и код. Вы можете использовать оболочку duo setuid и любой код 2fa, который вы используете.

Конфигурация Duo Unix

Вот объяснение, как это сделать https://cern-cert.github.io/pam_2fa/

  • Основа: двухфакторная аутентификация с pam
  • Модуль pam, который больше разбирается в методах аутентификации ssh:

    auth [success = 2 ignore = ignore default = die] pam_ssh_user_auth.so

  • Недавний или исправленный OpenSSH, чтобы показать это pam

    AuthenticationMethods gssapi-with-mic, keyboard-interactive: pam publickey, keyboard-interactive: pam keyboard-interactive: pam