Двухфакторная аутентификация в RELS

Материал из Rosalab Wiki
Версия от 14:22, 5 июля 2017; Vladimir.potapov (обсуждение | вклад)

(разн.) ← Предыдущая | Текущая версия (разн.) | Следующая → (разн.)
Это снимок страницы. Он включает старые, но не удалённые версии шаблонов и изображений.
Перейти к: навигация, поиск

Настройка локальной двухфакторной аутентификации с использованием временных паролей в операционной системе 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

Google-auth.png

После генерации приложением QR-кода, на телефоне следует зайти в приложение FreeOTP и сканировать код. После сканирования, заходя в приложение FreeOTP можно будет получать временные пароли путём нажатия на иконку с названием логина.

Google-auth2.png Коды, полученные при запуске 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