2FA — различия между версиями

Материал из Rosalab Wiki
Перейти к: навигация, поиск
(Список ключей пользователя)
 
(не показана одна промежуточная версия этого же участника)
Строка 1: Строка 1:
 
== Введение ==
 
== Введение ==
  
Эта статья описывает настройку многофакторной (двухфакторной) аутентификация в операционных системах на базе платформ rosa2019.05 (Никель), rosa2021.1 и новее (ОС ROSA Fresh 12+, Chrome 12+).
+
=== О статье ===
  
Разбирается отдельно настройка **рабочей станции администратора** — компьютера, на котором будет производиться настройка токена — и **целевой рабочей станции** — компьютера (ПК или сервера), в установленную на котором операционную систему будут входить с использованием второго фактора — токена.
+
Эта статья описывает '''настройку многофакторной (двухфакторной) проверки подлинности''' (аутентификации) в операционных системах на базе платформ rosa2019.05 (Никель), rosa2021.1 и новее (ОС ROSA Fresh 12+, Chrome 12+).
 +
 
 +
Разбирается отдельно настройка '''рабочей станции администратора''' — компьютера, на котором будет производиться настройка токена — и '''целевой рабочей станции''' — компьютера (ПК или сервера), в установленную на котором операционную систему будут входить с использованием второго фактора — токена. При необходимости это может быть один и тот же компьютер.
 +
 
 +
=== Что считаем факторами проверки подлинности ===
 +
 
 +
Пользователю и только пользователю известен пароль (PIN-код) — уникальная последовательность символов.
 +
 
 +
У пользователя имеется устройство со встроенными криптографическими функциями — токен — или устройство с уникальной меткой радиочастотного распознавания (RFID) — смарткарта — и устройство для распознавания метки.
 +
 
 +
На токене, с использованием встроенных в него криптографических функций, создается криптографический ключ. Внутри ОС «РОСА» в специальный файл со списком разрешенных для конкретного пользователя и только для него ключей помещается открытый (публичный) ключ от созданного на токене ключа.
 +
 
 +
При входе в систему пользователь PAM-модуль [https://github.com/OpenSC/pam_p11 pam_p11] создает случайную последовательность символов, запрашивает у пользователя PIN-код как пароль от хранящегося на токене закрытого ключа, просит токен подписать созданную случайную последовательность и проверяет полученную от токена подпись по открытому ключу, хранящемуся в файле с разрешенными для пользователя ОС открытыми ключами. Если проверка проходит успешно, то pam_p11 разрешает вход пользователя в систему, если нет, то запрещает.
 +
 
 +
Получается, что первым фактором проверки подлинности является наличие устройства с уникальным ключом, а вторым — знание уникальной последовательности символов от этого ключа.
  
 
== Подготовка рабочих станций ==
 
== Подготовка рабочих станций ==
Строка 11: Строка 25:
 
Установите необходимые пакеты:
 
Установите необходимые пакеты:
 
для дистрибутивов на базе платформы rosa2021.1 и новее (Fresh/Chrome 12+):
 
для дистрибутивов на базе платформы rosa2021.1 и новее (Fresh/Chrome 12+):
  sudo dnf install task-smartcards
+
  sudo dnf install task-smartcards pam_p11
(в большинстве десктопных дистрибутивов необходимые пакеты имеются из коробки)
+
 
 +
При установке пакета task-smartcards создается группа пользователей tokenlogin. Приведенные ниже примеры конфигурационных файлов позволяют сделать так, чтобы состоящие в группе tokenlogin пользователи входили с применением второго фактора, а не состоящие в ней входили просто по паролю.
  
 
Включите pcscd.socket:
 
Включите pcscd.socket:
Строка 20: Строка 35:
 
В состав пакета pcsc-lite есть политика polkit (/usr/share/polkit-1/actions/org.debian.pcsc-lite.policy). Она разрешает демону pcscd давать всем пользователям доступ к любым токенам. При необходимости можно в /etc/polkit-1/ создать соответствующие файлы для переопределения таковой политики. В большинстве случаев этого не требуется.
 
В состав пакета pcsc-lite есть политика polkit (/usr/share/polkit-1/actions/org.debian.pcsc-lite.policy). Она разрешает демону pcscd давать всем пользователям доступ к любым токенам. При необходимости можно в /etc/polkit-1/ создать соответствующие файлы для переопределения таковой политики. В большинстве случаев этого не требуется.
  
== Подготовка токена Рутокен
+
== Подготовка токена Рутокен ==
  
 
Используется устройство Рутокен ЭЦП PKI, в выводе lsusb оно видно так:
 
Используется устройство Рутокен ЭЦП PKI, в выводе lsusb оно видно так:
Строка 39: Строка 54:
 
Генерируем пару ключей (RSA длиной 2048 бит) на токене:
 
Генерируем пару ключей (RSA длиной 2048 бит) на токене:
 
  pkcs15-init -G rsa/2048 --auth-id 02 --id 42 --label "SSH User's Key" --public-key-label "SSH User's Public Key"
 
  pkcs15-init -G rsa/2048 --auth-id 02 --id 42 --label "SSH User's Key" --public-key-label "SSH User's Public Key"
 +
 +
Будет запрошен пин-код:<br>
 +
User PIN [User PIN] required.<br>
 +
Please enter User PIN [User PIN]:<br>
 +
Вводим: «12345678».
  
 
== Извлечение и перенос ключа для SSH ==
 
== Извлечение и перенос ключа для SSH ==
Строка 47: Строка 67:
 
  ssh-keygen -D /usr/lib64/opensc-pkcs11.so -I 0:42 >> key.pub
 
  ssh-keygen -D /usr/lib64/opensc-pkcs11.so -I 0:42 >> key.pub
  
Теперь содержимое файла key.pub нужно добавить отдельной строкой в ~/.ssh/authorized_keys на целевой рабочей станции любым способом, например:
+
Теперь содержимое файла key.pub нужно добавить отдельной строкой в ~/.ssh/authorized_keys на целевой рабочей станции любым способом.
ssh-copy-id -p port user@ip
+
 
где:
+
Если вы редактируете файл ~/.ssh/authorized_keys вручную, то просто добавьте в него отдельной строкой содержимое файла key.pub (этот файл состоит из одной строки).
* port — числовое обозначение порта, на котором запущен sshd на целевой станции, обычно 22
+
 
* user ­— имя пользователя на целевой станции
+
PAM-модуль pam_p11 сам читает файл ~/.ssh/authorized_keys, OpenSSH не используется, нет необходимости в его обязательной установке и запуске на целевой рабочий станции.
* ip — адрес целевой станции
+
  
 
Обратите внимание, что на ОС Никель в файле /etc/security/limits.d/10-maxlogins.conf задано, что у одного пользователя может быть только одна активная сессия, поэтому нужно, чтобы пользователь, под которым входим по SSH на Никель, не имел запущенных сессий. Достаточно запустить ОС до экрана входа в систему.
 
Обратите внимание, что на ОС Никель в файле /etc/security/limits.d/10-maxlogins.conf задано, что у одного пользователя может быть только одна активная сессия, поэтому нужно, чтобы пользователь, под которым входим по SSH на Никель, не имел запущенных сессий. Достаточно запустить ОС до экрана входа в систему.
  
== Подготовка целевой станции
+
== Подготовка целевой станции ==
 +
 
 +
=== Настройка механизмов авторизации ===
 +
 
 +
==== Установка пакета ====
 +
 
 +
На целевой станции установите необходимый PAM-модуль:
 +
sudo dnf install pam_p11
 +
 
 +
==== Добавление пользователей в группу tokenlogin ====
 +
 
 +
Приведенные ниже примеры файлов /etc/pam.d/* сделаны так, чтобы система PAM требовала вход по токену (т.е. с применением второго фактора) только для пользователей, состоящих в группе toeknlogin.
 +
 
 +
===== Добавление локальных пользователей в группу tokenlogin =====
 +
 
 +
Чтобы добавить пользователя с именем пользователя user в группу tokenlogin, выполните команду:
 +
sudo usermod -a -G tokenlogin user
 +
где вместо user напишите имя пользователя.
 +
 
 +
Группа tokenlogin автоматически создается при установке пакета task-smartcards.
 +
 
 +
===== Добавление доменных пользователей в группу tokenlogin =====
 +
 
 +
Пакет libnss-role позволяет сделать так, чтобы члены некой группы пользователей считались членами другой группы. Предположим, что на контроллере домена AD (Samba AD/Microsoft Active Directory) или FreeIPA есть группа пользователей "Token Login". Если машина с Росой корректно введена в домен, то система будет знать, что доменный пользователь состоит в этой группе.
 +
 
 +
Установите пакет libnss-role:
 +
sudo dnf install libnss-role
 +
 
 +
При установке модуль role будет автоматически добавлен в раздел group в файле /etc/nsswitch.conf.
 +
 
 +
Задайте соответствие групп:
 +
sudo roleadd 'Token Login' tokenlogin
 +
Это внесет запись в файл /etc/role.
 +
 
 +
Теперь в выводе команды id можно будет увидеть, что доменный пользователь состоит в группах и "Token Login", и tokenlogin.
 +
 
 +
==== Список ключей пользователя ====
 +
 
 +
В файл ~/.ssh/authorized_keys нужного пользователя добавьте открытый ключ, как описано выше, то есть:
 +
 
 +
при подключенном токене выполните:
 +
ssh-keygen -D /usr/lib64/opensc-pkcs11.so -I 0:42
 +
и выведенный текст добавьте в файл ~/.ssh/authorized_keys в домашней папке пользователя, которому будет разрешен вход с использованием этого ключа, для этого выполните следующие действия от пользователя:
 +
 
 +
создайте папку:
 +
mkdir --mode=700 -p ~/.ssh
 +
 
 +
откройте файл на редактирование:
 +
nano ~/.ssh/authorized_keys
 +
и вставьте в него строку с выводом команды выше, сохраните.
 +
 
 +
Файл ~/.ssh/authorized_keys используется и при локальном входе не по SSH.
 +
 
 +
==== Общий файл настроек PAM ====
 +
 
 +
Создаем и открываем на редактирование файл /etc/pam.d/p11:
 +
sudo nano /etc/pam.d/p11
 +
Вставляем в него следующий текст:
 +
<pre>
 +
auth required pam_env.so
 +
#auth required pam_faillock.so preauth silent deny=5 unlock_time=900
 +
auth required pam_p11.so /usr/lib64/opensc-pkcs11.so
 +
#auth required pam_faillock.so authfail deny=5 unlock_time=900
 +
password optional pam_p11.so /usr/lib64/opensc-pkcs11.so
 +
</pre>
 +
и сохраняем (в редакторе nano для этого нужно последовательно нажать: Ctrl+O, Enter, Ctrl+X). Если нужен модуль pam_faillock, то уберите знак решетки из начала строк с ним.
 +
 
 +
Далее в другие файлы в каталоге /etc/pam.d/ при необходимости пропишем подключение этого файла.
 +
 
 +
Если ни один PAM-модуль в стеке до pam_p11 не запросил пароль, то pam_p11 запрашивает его как PIN-код, иначе использует уже имеющийся в стеке PAM пароль как PIN-код. В приводимых в этой инструкции примерах pam_p11 всегда запрашивает пароль первым.
 +
 
 +
==== Расширенная документация ====
 +
 
 +
В этой инструкции приводятся типовые примеры написания файлов настроек PAM, однако можно сделать иные, в т.ч. более сложные конструкции. С документацией по форматы файлов с настройками PAM можно ознакомиться в pam.conf(5):
 +
man pam.conf
 +
 
 +
==== Просмотр логов ====
 +
 
 +
После попытки входа под пользователем можно ознакомиться с логами так:
 +
sudo journalctl -b | grep pam_p11
 +
 
 +
==== Настройка входа в TTY ====
 +
 
 +
Описывается настройка, при которой токен будет использоваться только при входе в TTY (alt+ctrl+fN). Токен должен быть подключен к машине, на которой осуществляется вход.
 +
 
 +
Откройте файл /etc/pam.d/login на редактирование с правами root, например:
 +
sudo nano /etc/pam.d/login
 +
 
 +
Замените строку:
 +
auth include system-auth
 +
на:
 +
<pre>
 +
auth [default=1 success=ignore] pam_succeed_if.so user ingroup tokenlogin
 +
auth substack p11
 +
auth [default=ignore success=1] pam_succeed_if.so user ingroup tokenlogin
 +
auth substack system-auth
 +
</pre>
 +
 
 +
Замените строку:
 +
password include system-auth
 +
на:
 +
<pre>
 +
password [default=1 success=ignore] pam_succeed_if.so user ingroup tokenlogin
 +
password substack p11
 +
password [default=ignore success=1] pam_succeed_if.so user ingroup tokenlogin
 +
password substack system-auth
 +
</pre>
 +
 
 +
Сохраните изменения в файле.
 +
 
 +
Откройте TTY и попробуйте войти под пользователем, для которого добавили ключ SSH. При необходимости ознакомьтесь с логами, как описано выше.
 +
 
 +
==== Настройка входа через GDM ====
 +
 
 +
Описывается настройка GDM (менеджера входа по умолчанию в ROSA Fresh/Chrome 12+) для входа с использованием PIN-кода вместо пароля.
 +
 
 +
Откройте файл /etc/pam.d/gdm-password на редактирование с правами root, например:
 +
sudo nano /etc/pam.d/gdm-password
 +
 
 +
Здесь и далее под закомментированием строки понимается добавление символа решетки (#) в начало строки.
 +
 
 +
Закомментируйте следующие строки:
 +
<pre>
 +
auth        substack      password-auth
 +
auth        optional      pam_gnome_keyring.so
 +
</pre>
 +
После них добавьте строки:
 +
<pre>
 +
auth [default=1 success=ignore] pam_succeed_if.so user ingroup tokenlogin
 +
auth substack p11
 +
auth [default=ignore success=1] pam_succeed_if.so user ingroup tokenlogin
 +
auth substack password-auth
 +
</pre>
 +
 
 +
Закомментируйте следующие строки:
 +
<pre>
 +
password    substack      password-auth
 +
-password  optional      pam_gnome_keyring.so use_authtok
 +
</pre>
 +
После них добавьте строки:
 +
<pre>
 +
password [default=1 success=ignore] pam_succeed_if.so user ingroup tokenlogin
 +
password substack p11
 +
password [default=ignore success=1] pam_succeed_if.so user ingroup tokenlogin
 +
password substack system-auth
 +
</pre>
 +
 
 +
Сохраните изменения в файле.
 +
 
 +
Мы отключаем pam_gnome_keyring, поскольку он не имеет смысл в такой конфигурации: его смысл в том, чтоб автоматически разблокировать хранилище ключей пользователя, если пароль пользователя совпадает с паролем от хранилища.
 +
 
 +
Попробуйте войти через GDM. Вместо пароля будет запрошен PIN-код.
 +
 
 +
==== Настройка входа по SSH ====
 +
 
 +
В этом разделе описана настройка, при которой токен в качестве второго фактора будет использоваться только при входе по SSH. Токен при этом будет подключен к машине, с которой осуществляют вход, а на этой машине будет лишь публичный ключ в списке доверенных.
 +
 
 +
Содержимое открытого ключа должно быть добавлено в ~/.ssh/authorized_keys у нужного пользователя на целевой станции, что было описано ранее.
 +
 
 +
===== Вход по SSH по PIN-коду и паролю =====
 +
 
 +
====== Настройка целевой станции ======
  
=== Настройка входа по SSH ===
+
Рассмотрим такую настройку SSHD, когда для входа нужно ввести сначала PIN-код, а затем пароль пользователя. pam_p11 не требуется.
Содержимое открытого ключа должно быть добавлено в ~/.ssh/authorized_keys у нужного пользователя на целевой станции, что было описано в предыдущем пункте.
+
  
 
Необходимо запретить SSH-вход по паролю:
 
Необходимо запретить SSH-вход по паролю:
 
  echo "AuthenticationMethods publickey,keyboard-interactive" | sudo tee -a /etc/ssh/sshd_config
 
  echo "AuthenticationMethods publickey,keyboard-interactive" | sudo tee -a /etc/ssh/sshd_config
  
И перезапустить sshd:
+
При этом директива "UsePAM" в файле /etc/ssh/sshd_config должна иметь значение "Yes" (по умолчанию в Росе). При необходимости исправьте ее значение. Если поставите "No", то будет запрашиваться только PIN-код, а пароль не будет.
 +
 
 +
Перезапустите sshd:
 
  sudo systemctl restart sshd
 
  sudo systemctl restart sshd
  
== Вход по SSH ==
+
====== Вход с рабочей станции ======
  
При входе по SSH токен должен быть подключен к машине, с которой производится вход. Эта машина должна быть подготовлена в соответствии с разделом «Подготовка рабочих станций».
+
При входе по SSH токен должен быть подключен к машине, с которой производится вход (к рабочей станции). Эта машина должна быть подготовлена в соответствии с разделом «Подготовка рабочих станций».
  
 
Выполните:
 
Выполните:
Строка 82: Строка 263:
 
[[File:2022-04-19_15-11_cut.png]]
 
[[File:2022-04-19_15-11_cut.png]]
  
== Программная методика испытаний на Никеле
+
===== Вход по SSH по PIN-коду =====
 +
 
 +
====== Настройка целевой станции ======
 +
 
 +
Рассмотрим такую настройку SSHD, когда для входа нужно ввести только PIN-код, а пароль вводить не нужно.
 +
 
 +
Откройте на редактирование файл /etc/pam.d/sshd, например:
 +
sudo nano /etc/pam.d/sshd
 +
 
 +
Закомментируйте строку:
 +
auth      include      system-auth
 +
После нее добавьте строки:
 +
<pre>
 +
auth [default=1 success=ignore] pam_succeed_if.so user ingroup tokenlogin
 +
auth substack p11
 +
auth [default=ignore success=1] pam_succeed_if.so user ingroup tokenlogin
 +
auth substack system-auth
 +
</pre>
 +
 
 +
Закомментируйте строку:
 +
password  include system-auth
 +
После нее добавьте строки:
 +
<pre>
 +
password [default=1 success=ignore] pam_succeed_if.so user ingroup tokenlogin
 +
password substack p11
 +
password [default=ignore success=1] pam_succeed_if.so user ingroup tokenlogin
 +
password substack system-auth
 +
</pre>
 +
 
 +
И сохраните изменения в файле.
 +
 
 +
Директива "UsePAM" в файле /etc/ssh/sshd_config должна иметь значение "Yes" (по умолчанию в Росе), при необходимости исправьте.
 +
 
 +
====== Вход с рабочей станции ======
 +
 
 +
При входе по SSH токен должен быть подключен к машине, с которой производится вход (к рабочей станции). Эта машина должна быть подготовлена в соответствии с разделом «Подготовка рабочих станций».
 +
 
 +
Выполните:
 +
ssh -I /usr/lib64/opensc-pkcs11.so -p port user@ip
 +
где:
 +
* port — числовое обозначение порта, на котором запущен sshd на целевой станции, обычно 22
 +
* user ­— имя пользователя на целевой станции
 +
* ip — адрес целевой станции
  
Описан механизм тестирования данного функционала на ОС РОСА Никель.
+
Будет запрошен PIN-код.
  
1. Установить ОС на первую машину (под машиной здесь и далее понимается физический или виртуальный компьютер). Выключить машину.
+
[[File:2022-04-22_12-16.png]]
2. Установить ОС на вторую машину. Выключить вторую машину.
+
3. Выполнять пункт про подготовку рабочих станций не нужно: в ОС Никель имеются необходимые пакеты и включен pcscd.
+
4. Включить первую машину, войти под созданным при установке пользователем под уровнем s0.
+
5. Включить вторую машину, войти в систему, командой "/sbin/ip a" узнать IP-адрес, завершить сеанс.
+
6. Выполнить раздел "Подготовка токена Рутокен" на первой машине.
+
7. Выполнить раздел "Извлечение и перенос ключа для SSH" на первой машине, при выполнении ssh-copy-id произвести подключение ко второй машине.
+
8. Войти под s0 на второй машине.
+
9. Выполнить пункт "Настройка входа по SSH" на второй машине.
+
  
 
[[Категория:ROSA Server]]
 
[[Категория:ROSA Server]]

Текущая версия на 10:24, 9 февраля 2024

Введение

О статье

Эта статья описывает настройку многофакторной (двухфакторной) проверки подлинности (аутентификации) в операционных системах на базе платформ rosa2019.05 (Никель), rosa2021.1 и новее (ОС ROSA Fresh 12+, Chrome 12+).

Разбирается отдельно настройка рабочей станции администратора — компьютера, на котором будет производиться настройка токена — и целевой рабочей станции — компьютера (ПК или сервера), в установленную на котором операционную систему будут входить с использованием второго фактора — токена. При необходимости это может быть один и тот же компьютер.

Что считаем факторами проверки подлинности

Пользователю и только пользователю известен пароль (PIN-код) — уникальная последовательность символов.

У пользователя имеется устройство со встроенными криптографическими функциями — токен — или устройство с уникальной меткой радиочастотного распознавания (RFID) — смарткарта — и устройство для распознавания метки.

На токене, с использованием встроенных в него криптографических функций, создается криптографический ключ. Внутри ОС «РОСА» в специальный файл со списком разрешенных для конкретного пользователя и только для него ключей помещается открытый (публичный) ключ от созданного на токене ключа.

При входе в систему пользователь PAM-модуль pam_p11 создает случайную последовательность символов, запрашивает у пользователя PIN-код как пароль от хранящегося на токене закрытого ключа, просит токен подписать созданную случайную последовательность и проверяет полученную от токена подпись по открытому ключу, хранящемуся в файле с разрешенными для пользователя ОС открытыми ключами. Если проверка проходит успешно, то pam_p11 разрешает вход пользователя в систему, если нет, то запрещает.

Получается, что первым фактором проверки подлинности является наличие устройства с уникальным ключом, а вторым — знание уникальной последовательности символов от этого ключа.

Подготовка рабочих станций

Описаны действия, которые необходимо выполнить и на рабочей станции администратора, и на целевых рабочих станциях.

Установите необходимые пакеты: для дистрибутивов на базе платформы rosa2021.1 и новее (Fresh/Chrome 12+):

sudo dnf install task-smartcards pam_p11

При установке пакета task-smartcards создается группа пользователей tokenlogin. Приведенные ниже примеры конфигурационных файлов позволяют сделать так, чтобы состоящие в группе tokenlogin пользователи входили с применением второго фактора, а не состоящие в ней входили просто по паролю.

Включите pcscd.socket:

sudo systemctl enable --now pcscd.socket

В дистрибутивах платформы rosa2021.1 версии 12.3 и новее он включен из коробки, однако выполнение команды выше не выключит его (не навредит).

В состав пакета pcsc-lite есть политика polkit (/usr/share/polkit-1/actions/org.debian.pcsc-lite.policy). Она разрешает демону pcscd давать всем пользователям доступ к любым токенам. При необходимости можно в /etc/polkit-1/ создать соответствующие файлы для переопределения таковой политики. В большинстве случаев этого не требуется.

Подготовка токена Рутокен

Используется устройство Рутокен ЭЦП PKI, в выводе lsusb оно видно так:

Bus 001 Device 005: ID 0a89:0030 Aktiv Rutoken ECP

Подключите токен к рабочей станции администратора. Приведенные ниже команды выполнять либо от пользователя, либо от root, root необязателен.

Стираем информацию с токена:

pkcs15-init --erase-card -p rutoken_ecp

Создаем контейнер PKCS#15:

pkcs15-init --create-pkcs15 --so-pin "87654321" --so-puk ""

где 87654321 — пин-код администратора.

Присваиваем контейнеру пользовательский PIN (12345678) и PIN администратора (87654321):

pkcs15-init --store-pin --label "User PIN" --auth-id 02 --pin "12345678" --puk "" --so-pin "87654321" --finalize

Генерируем пару ключей (RSA длиной 2048 бит) на токене:

pkcs15-init -G rsa/2048 --auth-id 02 --id 42 --label "SSH User's Key" --public-key-label "SSH User's Public Key"

Будет запрошен пин-код:
User PIN [User PIN] required.
Please enter User PIN [User PIN]:
Вводим: «12345678».

Извлечение и перенос ключа для SSH

При необходимости можно использовать токен в качестве второго фактора аутентификации при входе по SSH. Описанные ниже действия можно сделать на любой из станций.

Копируем открытый ключ с токена в файл key.pub (файл появится в текущей директории):

ssh-keygen -D /usr/lib64/opensc-pkcs11.so -I 0:42 >> key.pub

Теперь содержимое файла key.pub нужно добавить отдельной строкой в ~/.ssh/authorized_keys на целевой рабочей станции любым способом.

Если вы редактируете файл ~/.ssh/authorized_keys вручную, то просто добавьте в него отдельной строкой содержимое файла key.pub (этот файл состоит из одной строки).

PAM-модуль pam_p11 сам читает файл ~/.ssh/authorized_keys, OpenSSH не используется, нет необходимости в его обязательной установке и запуске на целевой рабочий станции.

Обратите внимание, что на ОС Никель в файле /etc/security/limits.d/10-maxlogins.conf задано, что у одного пользователя может быть только одна активная сессия, поэтому нужно, чтобы пользователь, под которым входим по SSH на Никель, не имел запущенных сессий. Достаточно запустить ОС до экрана входа в систему.

Подготовка целевой станции

Настройка механизмов авторизации

Установка пакета

На целевой станции установите необходимый PAM-модуль:

sudo dnf install pam_p11

Добавление пользователей в группу tokenlogin

Приведенные ниже примеры файлов /etc/pam.d/* сделаны так, чтобы система PAM требовала вход по токену (т.е. с применением второго фактора) только для пользователей, состоящих в группе toeknlogin.

Добавление локальных пользователей в группу tokenlogin

Чтобы добавить пользователя с именем пользователя user в группу tokenlogin, выполните команду:

sudo usermod -a -G tokenlogin user

где вместо user напишите имя пользователя.

Группа tokenlogin автоматически создается при установке пакета task-smartcards.

Добавление доменных пользователей в группу tokenlogin

Пакет libnss-role позволяет сделать так, чтобы члены некой группы пользователей считались членами другой группы. Предположим, что на контроллере домена AD (Samba AD/Microsoft Active Directory) или FreeIPA есть группа пользователей "Token Login". Если машина с Росой корректно введена в домен, то система будет знать, что доменный пользователь состоит в этой группе.

Установите пакет libnss-role:

sudo dnf install libnss-role

При установке модуль role будет автоматически добавлен в раздел group в файле /etc/nsswitch.conf.

Задайте соответствие групп:

sudo roleadd 'Token Login' tokenlogin

Это внесет запись в файл /etc/role.

Теперь в выводе команды id можно будет увидеть, что доменный пользователь состоит в группах и "Token Login", и tokenlogin.

Список ключей пользователя

В файл ~/.ssh/authorized_keys нужного пользователя добавьте открытый ключ, как описано выше, то есть:

при подключенном токене выполните:

ssh-keygen -D /usr/lib64/opensc-pkcs11.so -I 0:42

и выведенный текст добавьте в файл ~/.ssh/authorized_keys в домашней папке пользователя, которому будет разрешен вход с использованием этого ключа, для этого выполните следующие действия от пользователя:

создайте папку:

mkdir --mode=700 -p ~/.ssh

откройте файл на редактирование:

nano ~/.ssh/authorized_keys

и вставьте в него строку с выводом команды выше, сохраните.

Файл ~/.ssh/authorized_keys используется и при локальном входе не по SSH.

Общий файл настроек PAM

Создаем и открываем на редактирование файл /etc/pam.d/p11:

sudo nano /etc/pam.d/p11

Вставляем в него следующий текст:

auth required pam_env.so
#auth required pam_faillock.so preauth silent deny=5 unlock_time=900
auth required pam_p11.so /usr/lib64/opensc-pkcs11.so
#auth required pam_faillock.so authfail deny=5 unlock_time=900
password optional pam_p11.so /usr/lib64/opensc-pkcs11.so

и сохраняем (в редакторе nano для этого нужно последовательно нажать: Ctrl+O, Enter, Ctrl+X). Если нужен модуль pam_faillock, то уберите знак решетки из начала строк с ним.

Далее в другие файлы в каталоге /etc/pam.d/ при необходимости пропишем подключение этого файла.

Если ни один PAM-модуль в стеке до pam_p11 не запросил пароль, то pam_p11 запрашивает его как PIN-код, иначе использует уже имеющийся в стеке PAM пароль как PIN-код. В приводимых в этой инструкции примерах pam_p11 всегда запрашивает пароль первым.

Расширенная документация

В этой инструкции приводятся типовые примеры написания файлов настроек PAM, однако можно сделать иные, в т.ч. более сложные конструкции. С документацией по форматы файлов с настройками PAM можно ознакомиться в pam.conf(5):

man pam.conf

Просмотр логов

После попытки входа под пользователем можно ознакомиться с логами так:

sudo journalctl -b | grep pam_p11

Настройка входа в TTY

Описывается настройка, при которой токен будет использоваться только при входе в TTY (alt+ctrl+fN). Токен должен быть подключен к машине, на которой осуществляется вход.

Откройте файл /etc/pam.d/login на редактирование с правами root, например:

sudo nano /etc/pam.d/login

Замените строку:

auth include system-auth

на:

auth [default=1 success=ignore] pam_succeed_if.so user ingroup tokenlogin
auth substack p11
auth [default=ignore success=1] pam_succeed_if.so user ingroup tokenlogin
auth substack system-auth

Замените строку:

password include system-auth

на:

password [default=1 success=ignore] pam_succeed_if.so user ingroup tokenlogin
password substack p11
password [default=ignore success=1] pam_succeed_if.so user ingroup tokenlogin
password substack system-auth

Сохраните изменения в файле.

Откройте TTY и попробуйте войти под пользователем, для которого добавили ключ SSH. При необходимости ознакомьтесь с логами, как описано выше.

Настройка входа через GDM

Описывается настройка GDM (менеджера входа по умолчанию в ROSA Fresh/Chrome 12+) для входа с использованием PIN-кода вместо пароля.

Откройте файл /etc/pam.d/gdm-password на редактирование с правами root, например:

sudo nano /etc/pam.d/gdm-password

Здесь и далее под закомментированием строки понимается добавление символа решетки (#) в начало строки.

Закомментируйте следующие строки:

auth        substack      password-auth
auth        optional      pam_gnome_keyring.so

После них добавьте строки:

auth [default=1 success=ignore] pam_succeed_if.so user ingroup tokenlogin
auth substack p11
auth [default=ignore success=1] pam_succeed_if.so user ingroup tokenlogin
auth substack password-auth

Закомментируйте следующие строки:

password    substack       password-auth
-password   optional       pam_gnome_keyring.so use_authtok

После них добавьте строки:

password [default=1 success=ignore] pam_succeed_if.so user ingroup tokenlogin
password substack p11
password [default=ignore success=1] pam_succeed_if.so user ingroup tokenlogin
password substack system-auth

Сохраните изменения в файле.

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

Попробуйте войти через GDM. Вместо пароля будет запрошен PIN-код.

Настройка входа по SSH

В этом разделе описана настройка, при которой токен в качестве второго фактора будет использоваться только при входе по SSH. Токен при этом будет подключен к машине, с которой осуществляют вход, а на этой машине будет лишь публичный ключ в списке доверенных.

Содержимое открытого ключа должно быть добавлено в ~/.ssh/authorized_keys у нужного пользователя на целевой станции, что было описано ранее.

Вход по SSH по PIN-коду и паролю
Настройка целевой станции

Рассмотрим такую настройку SSHD, когда для входа нужно ввести сначала PIN-код, а затем пароль пользователя. pam_p11 не требуется.

Необходимо запретить SSH-вход по паролю:

echo "AuthenticationMethods publickey,keyboard-interactive" | sudo tee -a /etc/ssh/sshd_config

При этом директива "UsePAM" в файле /etc/ssh/sshd_config должна иметь значение "Yes" (по умолчанию в Росе). При необходимости исправьте ее значение. Если поставите "No", то будет запрашиваться только PIN-код, а пароль не будет.

Перезапустите sshd:

sudo systemctl restart sshd
Вход с рабочей станции

При входе по SSH токен должен быть подключен к машине, с которой производится вход (к рабочей станции). Эта машина должна быть подготовлена в соответствии с разделом «Подготовка рабочих станций».

Выполните:

ssh -I /usr/lib64/opensc-pkcs11.so -p port user@ip

где:

  • port — числовое обозначение порта, на котором запущен sshd на целевой станции, обычно 22
  • user ­— имя пользователя на целевой станции
  • ip — адрес целевой станции

Сначала будет запрошен пин-код от токена, правильный ввод которого позволит произвести подпись с использованием хранимого на токене закрытого ключа, а затем пароль пользователя, под которым выполняется вход.

2022-04-19 15-11 cut.png

Вход по SSH по PIN-коду
Настройка целевой станции

Рассмотрим такую настройку SSHD, когда для входа нужно ввести только PIN-код, а пароль вводить не нужно.

Откройте на редактирование файл /etc/pam.d/sshd, например:

sudo nano /etc/pam.d/sshd

Закомментируйте строку:

auth       include      system-auth

После нее добавьте строки:

auth [default=1 success=ignore] pam_succeed_if.so user ingroup tokenlogin
auth substack p11
auth [default=ignore success=1] pam_succeed_if.so user ingroup tokenlogin
auth substack system-auth

Закомментируйте строку:

password   include	system-auth

После нее добавьте строки:

password [default=1 success=ignore] pam_succeed_if.so user ingroup tokenlogin
password substack p11
password [default=ignore success=1] pam_succeed_if.so user ingroup tokenlogin
password substack system-auth

И сохраните изменения в файле.

Директива "UsePAM" в файле /etc/ssh/sshd_config должна иметь значение "Yes" (по умолчанию в Росе), при необходимости исправьте.

Вход с рабочей станции

При входе по SSH токен должен быть подключен к машине, с которой производится вход (к рабочей станции). Эта машина должна быть подготовлена в соответствии с разделом «Подготовка рабочих станций».

Выполните:

ssh -I /usr/lib64/opensc-pkcs11.so -p port user@ip

где:

  • port — числовое обозначение порта, на котором запущен sshd на целевой станции, обычно 22
  • user ­— имя пользователя на целевой станции
  • ip — адрес целевой станции

Будет запрошен PIN-код.

2022-04-22 12-16.png