Двухфакторная аутентификация в RELS
Настройка локальной двухфакторной аутентификации с использованием временных паролей в операционной системе ROSA Enterprise Linux Server 6.6
Многофакторная аутентификация (МФА, англ. multi-factor authentication, MFA) — расширенная аутентификация, метод контроля доступа к компьютеру, в котором пользователю для получения доступа к информации необходимо предъявить более одного «доказательства механизма аутентификации». К категориям таких доказательств относят:
- Знание — информация, которую знает субъект. Например, пароль, пин-код.
- Владение — вещь, которой обладает субъект. Например, электронная или магнитная карта, токен, флеш-память.
- Свойство, которым обладает субъект. Например, биометрия, природные уникальные отличия: лицо, отпечатки пальцев, радужная оболочка глаз, капиллярные узоры, последовательность ДНК.
В данная инструкция позволяет настроить двухфакторную аутентификацию, проверяющую как «знание», так и «владение». Для проверки «знания» используется обыкновенный пароль. Для проверки «владения» здесь используется механизм временных одноразовых паролей (TOTP - Time-based One-time Password Algorithm). В реализации, настраиваемой в этой инструкции механизм работает следующим образом:
- Пользователь, которому требуется такой механизм, генерирует некий секрет
- Секрет передаётся на внешнее устройство (в данном случае либо в виде QR-кода, либо перепечатывается в текстовом виде)
- На основе полученного секрета внешнее устройство генерирует одноразовые временные пароли, меняющиеся раз в 30 секунд.
После настройки, сначала будет запрашиваться пароль, затем будет запрашиваться временный одноразовый пароль в качестве дополнительного фактора.
Применимость
В инструкции описаны установка и конфигурирование утилит для аутентификации с использованием временных паролей, действующих в течение 30 секунд (TOTP) для ROSA Enterprise Linux Server 6.6.
Примечания
В инструкции приводятся базовые настройки, нацеленные только на задачу, состоящую в настройке модуля PAM для двухфакторной аутентификации в Gnome Desktop Manager. При блокировке экрана или при использовании терминала аутентификация с данными настройками работать не будет. Отдельно описана настройка того же механизма для удалённого доступа по SSH. Для корректной работы приложения время на телефоне и на хосте должно быть синхронизировано. В инструкции # - приглашение у пользователя «root», $ - приглашение у пользователей отличных от «root». При копировании приведённых ниже команд, копировать данные символы не нужно.
Установка требуемых компонентов (компьютер)
Требуются права администратора. В терминале:
$ su # yum groupinstall 'Desktop' # yum install google-authenticator qrencode
Теперь хост нужно перезагрузить.
Установка требуемых компонентов (телефон)
На телефоне надо установить приложение FreeOTP Authenticator.
Настройка google-authenticator для определённого пользователя
Открываем терминал, заходим за пользователя, для которого нужно настроить аутентификацию. В терминале:
$ su - <имя_пользователя>
Настраиваем для него работу google-authenticator (далее приведен снимок экрана для получения представления о возможных настройках). В терминале:
$ google-authenticator
После генерации приложением QR-кода, на телефоне следует зайти в приложение FreeOTP и сканировать код. После сканирования, заходя в приложение FreeOTP можно будет получать временные пароли путём нажатия на иконку с названием логина.
Коды, полученные при запуске google-authenticator стоит куда-нибудь записать. «Scratch codes» можно будет затем использовать при потере телефона.
Особое внимание нужно уделить «security key», его можно будет потом использовать в связке со скриптом.
Настройка PAM
Требуются права администратора. В терминале:
$ su # vi /etc/pam.d/password-auth
Отредактируем файл, чтобы он выглядел так, как представлено ниже:
#%PAM1.0 # This file is auto-generated. # User changes will be destroyed the next time authconfig is run. auth required pam_env.so auth required pam_unix.so auth sufficient pam_google_authenticator.so auth requisite pam_succeed_if.so uid >= 500 quiet auth required pam_deny.so
account required pam_unix.so account sufficient pam_localuser.so account sufficient pam_succeed_if.so uid < 500 quiet account required pam_permit.so
password requisite pam_cracklib.so try_first_pass retry=3 password sufficient pam_unix.so sha512 shadow nullok try_first_pass use_authtok password required pam_deny.so
session optional pam_keyinit.so revoke session required pam_limits.so session [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid session required pam_unix.so
После можно перезагрузиться и войти за пользователя, от имени которого была запущена программа google-authenticator. После перезагрузки GDM потребует сначала обычный пароль, а затем временный («verification code»), который отображается в приложении для телефона.
Конфигурация SSH
Для использования такого же механизма аутентификации при работе с хостом удалённо с использованием SSH можно не менять конфигурацию PAM и провести настройки только в конфигурации сервера SSH. Требуются права администратора. В терминале:
$ su # vi /etc/ssh/sshd_config
В тексте конфигураций поменять значение «ChallengeResponseAuthentication» на «yes» и перезапустить сервис. В терминале:
# service sshd restart
Дополнение
Для получения временных паролей также можно воспользоваться сценарием python (работает на версии по умлочанию в конфигурации «Стандартный сервер РОСА»). Код python:
import hmac, base64, struct, hashlib, time
def get_hotp_token(secret, intervals_no): key = base64.b32decode(secret, True) msg = struct.pack(">Q", intervals_no) h = hmac.new(key, msg, hashlib.sha1).digest() o = ord(h[19]) & 15 h = (struct.unpack(">I", h[o:o+4])[0] & 0x7fffffff) % 1000000 return h
def get_totp_token(secret): return get_hotp_token(secret, intervals_no=int(time.time())//30)
secret = 'U6E7O4DJEP22WN3C' #поменять на собственное значение print get_totp_token(secret)
Скрипт выводит одно текущее значение временного пароля.
Дополнение 2
Для того, чтобы двухфакторная аутентификация с использованием данного механизма работала в терминале необходимо проделать ту же процедуру, что в пункте 5 для пользователя «root» или для любого другого пользователя, имеющего доступ к таким же правам и отредактировать файл /etc/pam.d/system-auth. Привести файл к следующему виду:
#%PAM-1.0 # This file is auto-generated. # User changes will be destroyed the next time authconfig is run. auth required pam_unix.so auth sufficient pam_google_authenticator.so auth required pam_env.so auth sufficient pam_fprintd.so #auth sufficient pam_unix.so nullok try_first_pass auth requisite pam_succeed_if.so uid >= 500 quiet auth required pam_deny.so
account required pam_unix.so account sufficient pam_localuser.so account sufficient pam_succeed_if.so uid < 500 quiet account required pam_permit.so
password requisite pam_cracklib.so try_first_pass retry=3 type= password sufficient pam_unix.so sha512 shadow nullok try_first_pass use_authtok password required pam_deny.so
session optional pam_keyinit.so revoke session required pam_limits.so session [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid session required pam_unix.so