Настройка двухфакторной аутентификации
Двухфакторная аутентификация для SSH с использованием "Рутокен ЭЦП"
В данном разделе рассматривается пример настройки двухфакторной аутентификации с использованием "Рутокен ЭЦП".
Настройка двухфакторной аутентификации для SSH
Для примера настройки двухфакторной аутентификации для SSH консоли используется хост с гипервизором под управлением ROSA Virtualization 3.1. В качестве токена для аутентификации используется ранее подготовленный USB "Рутокен ЭЦП 2.0" для двухфакторной аутентификации на веб-портале ROSA Virtualization 3.1 для пользователя ovirtadmin. С процедурой подготовки токена можно ознакомиться в соответствующем разделе документации.
Последовательность действий для настройки двухфакторной аутентификации для SSH:
- Подключите токен к USB порту компьютера, на котором ранее выполнялась подготовка этого токена, и с помощью консольной команды проверьте его работоспособность:
pkcs11-tool --module /usr/lib64/librtpkcs11ecp.so -T
Available slots:
Slot 0 (0x0): Aktiv Rutoken ECP 00 00
token label : Rutoken
token manufacturer : Aktiv Co.
token model : Rutoken ECP
token flags : login required, rng, token initialized, PIN initialized
hardware version : 20.5
firmware version : 23.2
serial num : 3ac65c5d
pin min/max : 6/32
- Для просмотра объектов, хранящихся на токене, можно воспользоваться командой:
pkcs11-tool --module /usr/lib64/librtpkcs11ecp.so -O -l
Using slot 0 with a present token (0x0)
Logging in to "Rutoken".
Please enter User PIN: <PIN-код пользователя>
Private Key Object; RSA
label: login_ovirtadmin
ID: 10
Usage: decrypt, sign
Access: sensitive
Certificate Object; type = X.509 cert
label: login_ovirtadmin
subject: DN: O=EXAMPLE.COM, CN=ovirtadmin
ID: 10
- Создайте публичный ключ для консоли SSH на основе пользовательского сертификата, хранящегося на подключенном USB-токене:
$ ssh-keygen -D /usr/lib64/librtpkcs11ecp.so -I 0:10 > ovirtadmin_key.pub
- Используя утилиту ssh-copy-id, скопируйте полученный публичный ключ ovirtadmin_key.pub на хост, на котором требуется настроить двухфакторную аутентификацию для консоли SSH:
$ ssh-copy-id -f -i ovirtadmin_key.pub root@rosa-virt01.example.com
- Для включения двухфакторной аутентификации для консоли SSH на хосте с гипервизором отредактируйте конфигурационный файл SSH-сервера /etc/ssh/sshd_config, изменив или добавив соответствующие строки:
PubkeyAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys
PasswordAuthentication yes
PermitEmptyPasswords no
UsePAM yes
AuthenticationMethods publickey,password
- Такая конфигурация SSH-сервера будет требовать обязательной аутентификации по SSH-ключу и паролю, что приведёт к нарушению работы между виртуальной машиной СУСВ и хостом. Чтобы предотвратить такую ситуацию, необходимо в самом конце файла /etc/ssh/sshd_config добавить строки:
Match Address 192.168.1.164
AuthenticationMethods publickey password
В поле "Match Address" указывается IP-адрес виртуальной машины СУСВ. В результате сделанных настроек SSH-подключение между СУСВ и хостами будет требовать аутентификацию только по SSH-ключу или паролю, а во всех остальных случаях будут требоваться оба типа аутентификации одновременно.
- Перезапустите сервис sshd:
systemctl restart sshd
Подключение к SSH-серверу с настроенной двухфакторной аутентификацией
Для подключения к SSH-серверу с настроенной двухфакторной аутентификацией используется стандартный SSH-клиент для операционных систем GNU/Linux:
$ ssh -I /usr/lib64/librtpkcs11ecp.so root@rosa-virt01.example.com
Enter PIN for 'Rutoken': <PIN-код пользователя>
root@rosa-virt01.example.com's password: <Пароль пользователя root>
Двухфакторная аутентификация для веб-портала ROSA Virtualization 3.1
Двухфакторная аутентификация на веб-портале ROSA Virtualization основана на USB-токене с приватным ключом и клиентским сертификатом, на имени пользователя и его пароле. Для этого потребуется полная замена корневого сертификата системы управления средой виртуализации (СУСВ).
Примечание — Для замены корневого сертификата необходимо наличие двух и более хостов виртуализации, чтобы была возможность миграции виртуальных машин для последующей переустановки всех подключенных хостов. Процедура замены корневого сертификата может быть не безопасна, поэтому рекомендуется проводить её на ранней стадии настройки системы виртуализации. Крайне не рекомендуется перезагружать хосты до полного завершения процедуры замены сертификатов.
В данном примере продемонстрирован способ замены корневого сертификата ROSA Virtualization и всех сертификатов, подписанных им:
- Новый корневой сертификат и приватный ключ будет взят из файла /root/cacert.p12, который создаётся в процессе установки IPA-сервера. Файл защищён паролем, о чём свидетельствует скриншот, полученный в процессе установки IPA (рисунок 175):

Рисунок 175 ‒ Сообщение о защите файла паролем
- Чтобы извлечь сертификат и приватный ключ из файла cacert.p12, необходимо в консоли IPA сервера перейти в директорию /root и выполнить команды:
openssl pkcs12 -in cacert.p12 -nodes -nokeys | sed -n '/subject=.*CN.*=.*Certificate Authority/,/^-----END CERTIFICATE-----/p' | sed -n '/^-----BEGIN CERTIFICATE-----/,/^-----END CERTIFICATE-----/p' > ipa-ca.pem
Enter Import Password: <пароль Directory Manager, указанный при установки IPA сервера>
openssl pkcs12 -in cacert.p12 -nodes -nocerts | sed -n '/friendlyName: caSigningCert cert-pki-ca/,/^-----END PRIVATE KEY-----/p' | sed -n '/^-----BEGIN PRIVATE KEY-----/,/^-----END PRIVATE KEY-----/p' > ipa-ca.key
Enter Import Password: <пароль Directory Manager, указанный при установки IPA сервера>
Эти команды извлекают сертификат "subject=O = EXAMPLE.COM, CN = Certificate Authority" и приватный ключ "friendlyName: caSigningCert cert-pki-ca" из файла cacert.p12 и сохраняют их в файлы ipa-ca.pem и ipa-ca.key соответственно.
- Далее необходимо скопировать файл сертификата ipa-ca.pem на виртуальную машину СУСВ в директорию /etc/pki/ovirt-engine, а файл приватного ключа ipa-ca.key ‒ в директорию /etc/pki/ovirt-engine/private. Замена корневого сертификата выполняется с помощью скрипта ovirt-pki-enroll. Для его работы требуется создать файл ovirt_hosts в той директории, из которой предполагается запускать скрипт, например, в директории /root. В этом файле должны быть прописаны все хосты, подключенные к системе управления средой виртуализации. В качестве имени хоста может быть использовано короткое доменное имя (rosa-virt01), полное доменное имя (rosa-virt01.example.com) или же IP-адрес (192.168.1.162), в зависимости от того, что было прописано в поле "Имя хоста/IP" при добавлении хоста в систему виртуализации (рисунок 176).

Рисунок 176 ‒ Параметр "Имя хоста" при добавлении хоста в систему
- Согласно этим данным заполнить файл ovirt_hosts. В конце файла после всех введённых данных добавить пустую строку. Формат файла ovirt_hosts поддерживает различные комбинации написания имени хоста:
[ovirt_hosts]
rosa-virt01.example.com
192.168.1.172
rosa-virt03
- На любом из активных хостов системы виртуализации, который был настроен для запуска и миграции виртуализированного ЦУ, включить режим глобального обслуживания выполнив команду в консоли хоста:
hosted-engine --set-maintenance --mode=global
- Для замены сертификата выполнить команду в консоли виртуальной машины СУСВ:
ovirt-pki-enroll --name=ipa-ca --new-key
Если скрипт завершил свою работу из-за того, что не удалось определить домен, для которого были созданы предыдущие сертификаты, можно указать его принудительно, используя соответствующий ключ --domain:
ovirt-pki-enroll --domain=example.com --name=ipa-ca --new-key
где:
--name‒ это общая часть в именах новых файлов корневого сертификата и ключа (в нашем случае "ipa-ca" от файлов ipa-ca.pem и ipa-ca.key).--new-key‒ указывает на необходимость пересоздать приватные ключи для сертификатов.--domain‒ домен локальной сети в котором находятся подключенные хосты.
- Перезапустить сервисы:
systemctl restart ovirt-engine
systemctl restart ovirt-websocket-proxy
systemctl restart ovirt-provider-ovn
systemctl restart ovirt-imageio
systemctl restart httpd
- После пересоздания приватных ключей нарушится работа компонента ovirt-provider-ovn. Чтобы это исправить, необходимо зайти на портал администрирования ROSA Virtualization в раздел "Администрирование → Поставщики", выбрать строку ovirt-provider-ovn и нажать кнопку Изменить.
- В открывшемся окне (рисунок 177) ввести пароль для пользователя admin@internal (учётная запись администратора во внутреннем домене СУСВ). Нажать кнопку "Тест" и согласиться импортировать сертификат. После удачного завершения теста нажать кнопку ОК.

Рисунок 177 ‒ Окно "Параметры поставщика"
- Так как многие сервисы продолжают работать на старом корневом сертификате, то для восстановления функции миграции виртуальных машин необходимо перезапустить сервис libvirtd на каждом хосте, выполнив команду:
systemctl restart libvirtd
- Для полного завершения процедуры замены сертификатов на подключенных хостах требуется выполнить переустановку всех хостов. Это делается в разделе "Ресурсы → Хосты". Если на хостах есть виртуальные машины, которые не имеют возможности миграции на другой хост, то следует заранее позаботиться об их выключении:
- Перевести хост в режим обслуживания, нажав "Управление → Обслуживание".
- Запустить переустановку хоста, нажав "Установка → Переустановить".
Хост с виртуальной машиной HostedEngine переустанавливается в последнюю очередь.
- На данном этапе процесс замены корневого сертификата СУСВ считается завершённым, и можно отключить режим глобального обслуживания, выполнив в консоли хоста, с которого он был включен, команду:
hosted-engine --set-maintenance --mode=none
Для создания приватного ключа и клиентского сертификата выполните следующие действия:
- В качестве центра сертификации будет использоваться IPA-сервер. Первоначально требуется создать приватный ключ и запрос для сертификата пользователя admin внутреннего домена СУСВ. Так как на IPA-сервере такой пользователь уже существует, и нет возможности стандартными средствами создать для него сертификат, то необходимо добавить нового пользователя, например ovirtadmin. Для этого в консоли IPA сервера выполнить команды:
kinit admin
ipa user-add ovirtadmin --first=ovirtadmin \
--last=ovirtadmin
- Создать приватный ключ и запрос для сертификата пользователя ovirtadmin:
openssl req -new -sha256 -nodes -newkey rsa:2048 \
-keyout ovirtadmin.key -out ovirtadmin.csr \
-subj '/CN=ovirtadmin/O=EXAMPLE.COM'
- Создать сертификат и сохранить его в файл ovirtadmin.pem:
ipa cert-request ovirtadmin.csr --principal=ovirtadmin \
--certificate-out=ovirtadmin.pem
Сертификаты для других пользователей, которые будут иметь доступ к веб-порталу ROSA Virtualization, создаются аналогичным способом.
- Если импорт приватного ключа и сертификата пользователя на USB-токен планируется выполнять под ОС Windows, то необходимо создать файл ovirtadmin.p12, содержащий в себе приватный ключ и сертификат:
openssl pkcs12 -export -out ovirtadmin.p12 -inkey ovirtadmin.key \
-in ovirtadmin.pem
На данном этапе процесс создания приватного ключа и клиентского сертификата считается завершённым.
Для импорта приватного ключа и сертификата пользователя в качестве аппаратного хранилища приватного ключа и сертификата в данном примере будет использован USB "Рутокен ЭЦП" 2.0:
- Если для подготовки токена используется ROSA Desktop Cobalt, то необходимо убедиться, что следующие пакеты установлены, а если они отсутствуют, то установить opensc, pcsc-lite, pcsc-lite-ccid и перезагрузить компьютер.
- Установить соответствующую версию библиотеки PKCS#11
https://www.rutoken.ru/support/download/pkcs/и утилиту для администрирования токенаhttps://dev.rutoken.ru/pages/viewpage.action?pageId=7995615. После установки пакета PKCS#11 необходимая для работы с токеном библиотека будет находиться в директории/usr/lib64/librtpkcs11ecp.so. - Для корректной работы утилиты rtadmin в ROSA Linux может потребоваться однократно выполнить команды для создания симлинка:
cd /usr/lib64/
ln -s libdl.so.2 libdl.so
- Подключить Рутокен к USB-порту компьютера и выполнить его форматирование:
$ ./rtadmin -f -q -z /usr/lib64/librtpkcs11ecp.so \
-a <PIN-код администратора> -u <PIN-код пользователя>
- Импортировать приватный ключ и сертификат пользователя на USB-токен, предварительно сконвертировав их в формат DER, используя следующие команды:
$ openssl rsa -in ovirtadmin.key -out ovirtadmin_key.der \
-outform DER
$ openssl x509 -in ovirtadmin.pem -out ovirtadmin_cert.der \
-outform DER
$ pkcs11-tool --module /usr/lib64/librtpkcs11ecp.so -l -y privkey \
-w ovirtadmin_key.der --id 10 --label login_ovirtadmin
Please enter User PIN: <PIN-код пользователя>
$ pkcs11-tool --module /usr/lib64/librtpkcs11ecp.so -l -y cert \
-w ovirtadmin_cert.der --id 10 --label login_ovirtadmin
Please enter User PIN: <PIN-код пользователя>
- Если для подготовки токена используется операционная система Windows, необходимо установить соответствующую версию библиотеки PKCS#11, которая распространяется в составе драйверов Рутокен
https://www.rutoken.ru/support/download/pkcs/и утилиту для администрированияhttps://dev.rutoken.ru/pages/viewpage.action?pageId=7995615. После установки драйверов библиотека PKCS#11, необходимая для работы с токеном, будет находиться по путиC:\Windows\System32\rtPKCS11ECP.dll. Подключить Рутокен к USB-порту компьютера и выполнить его форматирование:
rtadmin.exe -f -q -z C:\Windows\System32\rtPKCS11ECP.dll -a <PIN-код администратора> -u <PIN-код пользователя>
- Открыть панель управления Рутокен, перейти на вкладку "Сертификаты", выбрать токен и нажать на кнопку Импорт (рисунок 178).

Рисунок 178 ‒ Контрольная панель Рутокен – вкладка "Сертификаты"
- Указать путь к ранее подготовленному файлу ovirtadmin.p12, ввести пароль который был задан при его создании и нажать на кнопку Импорт (рисунок 179).

Рисунок 179 ‒ Ввод пароля для файла
- Ввести ПИН- код пользователя для подключенного токена. В результате приватный ключ и сертификат пользователя из файла ovirtadmin.p12 будут импортированы на устройство Рутокен (рисунок 180).

Рисунок 180 ‒ Ввод ПИН-кода для "Рутокен ЭЦП"
Для включения двухфакторной аутентификации на web-портале ROSA Virtualization необходимо:
- создать конфигурационный файл /etc/httpd/conf.d/x509-cert-verify.conf:
SSLProtocol -all +TLSv1.2
RequestHeader set X-Cert-User "%{SSL_CLIENT_S_DN_CN}s"
<LocationMatch ^/ovirt-engine/sso/(interactive-login-negotiate|oauth/token-http-auth)>
SSLVerifyClient require
SSLVerifyDepth 10
</LocationMatch>
- Отредактировать файл /etc/ovirt-engine/engine.conf.d/60-ovirt-2fa.conf, установив для переменной TWO_FACTOR_AUTHENTICATION значение true:
TWO_FACTOR_AUTHENTICATION=true
- Для переменной OVIRT_ADMIN_LOGIN установить значение ovirtadmin (логин учётной записи на IPA-сервере, сертификат от которой будет сопоставлен с внутренней учётной записью admin системы управления средой виртуализации):
OVIRT_ADMIN_LOGIN=ovirtadmin
- Перезапустить сервис httpd:
systemctl restart httpd
При необходимости контроля отозванных сертификатов требуется дополнительная настройка httpd-сервера. Контроль может осуществляться с помощью сервиса OCSP, предоставляемого IPA сервером, либо с помощью CRL:
- Вариант с использованием OCSP более прост в реализации, и для его настройки достаточно отредактировать ранее созданный файл /etc/httpd/conf.d/x509-cert-verify.conf:
SSLOCSPEnable on
SSLOCSPOverrideResponder on
SSLOCSPDefaultResponder "http://ipa-ca.example.com/ca/ocsp"
SSLProtocol -all +TLSv1.2
RequestHeader set X-Cert-User "%{SSL_CLIENT_S_DN_CN}s"
<LocationMatch ^/ovirt-engine/sso/(interactive-login-negotiate|oauth/token-http-auth)>
SSLVerifyClient require
SSLVerifyDepth 10
</LocationMatch>
В переменной SSLOCSPDefaultResponder прописывается адрес IPA-сервера, который в данном примере выступает в роли центра сертификации и будет отвечать на OCSP запросы.
- Вариант контроля отозванных сертификатов на основе CRL более сложен в реализации и требует больше настроек. В первую очередь необходимо подготовить список отозванных сертификатов. Он автоматически формируется на IPA-сервере и доступен по адресу.
- Скачать файл с последующей конвертацией в PEM-формат для совместимости с httpd-сервером:
curl -L http://ipa-ca.example.com/ipa/crl/MasterCRL.bin | \
openssl crl -inform DER -outform PEM \
-out /etc/pki/ovirt-engine/apache-ca.crl
- Далее отредактировать ранее созданный файл
/etc/httpd/conf.d/x509-cert-verify.conf:
SSLCARevocationCheck chain
SSLCARevocationFile /etc/pki/ovirt-engine/apache-ca.crl
SSLProtocol -all +TLSv1.2
RequestHeader set X-Cert-User "%{SSL_CLIENT_S_DN_CN}s"
<LocationMatch ^/ovirt-engine/sso/(interactive-login-negotiate|oauth/token-http-auth)>
SSLVerifyClient require
SSLVerifyDepth 10
</LocationMatch>
Вне зависимости от того какой вариант контроля отозванных сертификатов был выбрал, после всех настроек требуется перезапустить сервис httpd:
systemctl restart httpd
Примечание — CRL-файл имеет дату/время начала действия и дату/время окончания действия и быстро устаревает (через несколько часов после генерации на IPA-сервере). Это надо учитывать и позаботиться об автоматическом обновлении списка отозванных сертификатов для httpd-сервера (можно реализовать через планировщик заданий cron).
Пример настройки браузера Firefox для работы с USB "Рутокен ЭЦП 2.0":
- В адресной строке браузера ввести "about:preferences#privacy" или перейти по вкладкам меню "Tools → Settings → Privacy & Security" (рисунок 181).

Рисунок 181 ‒ Настройки браузера Firefox
- Нажать кнопку Security Devices, в окне "Device Manager" нажать Load и заполнить все поля, указав расположение ранее установленной библиотеки PKCS#11 (librtpkcs11ecp.so ‒ для операционных систем Linux или rtPKCS11ECP.dll ‒ для операционных систем Windows) (рисунок 182).

Рисунок 182 ‒ Настройки браузера с библиотеками библиотекой PKCS#11
Двухфакторная аутентификация в локальной консоли с использованием "Рутокен ЭЦП"
Все действия по настройки двухфакторной аутентификации для локальной консоли выполняются на хосте с гипервизором под управлением ROSA Virtualization 3.1:
- Необходимо убедиться, что на хосте установлены следующие пакеты, и если они отсутствуют, то установить: opensc, pcsc-lite, pcsc-lite-ccid, pam_pkcs11, nss-tools. Установить библиотеку PKCS#11 для операционных систем GNU/Linux x64.
- После установки пакета библиотека PKCS#11, необходимая для работы с токеном, будет находиться по пути /usr/lib64/librtpkcs11ecp.so. В качестве токена для аутентификации используется ранее подготовленный USB "Рутокен ЭЦП 2.0" для двухфакторной аутентификации на веб-портале ROSA Virtualization 3.1 для пользователя ovirtadmin.
- С процедурой подготовки токена можно ознакомиться в соответствующем разделе документации. Подключить токен к USB-порту хоста и с помощью консольной команды проверить его работоспособность:
pkcs11-tool --module /usr/lib64/librtpkcs11ecp.so -T
Available slots:
Slot 0 (0x0): Aktiv Rutoken ECP 00 00
token label : Rutoken
token manufacturer : Aktiv Co.
token model : Rutoken ECP
token flags : login required, rng, token initialized, PIN initialized
hardware version : 20.5
firmware version : 23.2
serial num : 3ac65c5d
pin min/max : 6/32
- Для просмотра объектов, хранящихся на токене, можно воспользоваться командой:
pkcs11-tool --module /usr/lib64/librtpkcs11ecp.so -O -l
Using slot 0 with a present token (0x0)
Logging in to "Rutoken".
Please enter User PIN: <PIN-код пользователя>
Private Key Object; RSA
label: login_ovirtadmin
ID: 10
Usage: decrypt, sign
Access: sensitive
Certificate Object; type = X.509 cert
label: login_ovirtadmin
subject: DN: O=EXAMPLE.COM, CN=ovirtadmin
ID: 10
- Для настройки модуля pam_pkcs11:
- Создать структуру каталогов и установить необходимые права доступа:
mkdir /etc/pam_pkcs11/{nssdb,cacerts,crls}
chmod 0644 /etc/pam_pkcs11/{nssdb,cacerts,crls}
- Скачать корневой сертификат с IPA-сервера:
curl -o /etc/pam_pkcs11/cacerts/ipa-ca.crt --insecure -L https://ipa-ca.example.com/ipa/config/ca.crt
- Создать пустую базу данных для сертификатов и импортировать в неё корневой сертификат, полученный с IPA-сервера:
certutil -N -d /etc/pam_pkcs11/nssdb --empty-password
certutil -A -i /etc/pam_pkcs11/cacerts/ipa-ca.crt -n ipa-ca -t "CT,CT,CT" -d /etc/pam_pkcs11/nssdb
- Присутствие корневого сертификата в базе данных можно проверить командой:
certutil -L -d /etc/pam_pkcs11/nssdb
Certificate Nickname Trust Attributes
SSL,S/MIME,JAR/XPI
ipa-ca CT,C,C
- Сделать резервную копию существующего файла /etc/pam_pkcs11/pam_pkcs11.conf:
mv /etc/pam_pkcs11/pam_pkcs11.conf \
/etc/pam_pkcs11/pam_pkcs11.conf.default
- Создать новый файл /etc/pam_pkcs11/pam_pkcs11.conf со следующим содержимым:
pam_pkcs11 {
debug = false;
nullok = false;
card_only = false;
use_first_pass = false;
try_first_pass = false;
use_authtok = false;
wait_for_card = false;
use_pkcs11_module = rutokenecp;
pkcs11_module rutokenecp {
module = /usr/lib64/librtpkcs11ecp.so;
description = "Rutoken PKCS#11";
slot_num = 0;
nss_dir = /etc/pam_pkcs11/nssdb;
ca_dir = /etc/pam_pkcs11/cacerts;
crl_dir = /etc/pam_pkcs11/crls;
cert_policy = ca,signature;
}
use_mappers = subject;
mapper_search_path = /usr/lib64/pam_pkcs11;
mapper subject {
debug = false;
module = internal;
ignorecase = false;
mapfile = file:///etc/pam_pkcs11/subject_mapping;
}
}
- Для сопоставления сертификата, хранящегося на токене, и учётной записи пользователя root, под которой будет осуществляться локальный вход в систему, необходимо создать файл /etc/pam_pkcs11/subject_mapping, примерно следующего содержания:
Mapping file for Certificate Subject
format: Certificate Subject -> login
#
CN=ovirtadmin,O=EXAMPLE.COM -> root
- Получить строку "CN=ovirtadmin,O=EXAMPLE.COM" для добавления в файл можно с помощью утилиты pkcs11_inspect, предварительно подключив токен к USB-порту и выполнив команду:
pkcs11_inspect
PIN for token: <PIN-код пользователя>
Printing data for mapper subject:
CN=ovirtadmin,O=EXAMPLE.COM
Вход в систему через локальную консоль будет возможен только под той учётной записью, для которой сопоставлен сертификат в файле /etc/pam_pkcs11/subject_mapping.
- Включение двухфакторной аутентификации для локальной консоли:
Внести соответствующие изменения в систему PAM, отредактировав файл
/etc/pam.d/system-auth, как показано на рисунке 183.

Рисунок 183 ‒ Редактирование файла /etc/pam.d/system-auth
- В файле необходимо заменить одну строку:
auth sufficient pam_unix.so try_first_pass nullok
на две новые строки:
auth required pam_unix.so try_first_pass nullok
auth [success=done ignore=ignore default=die] pam_pkcs11.so nodebug wait_for_card
В результате после всех сделанных настроек система PAM будет требовать ввода login/password и запрашивать ПИН-код к подключенному USB-токену (рисунок 184).

Рисунок 184 ‒ Ввод ПИН-кода для "Рутокен ЭЦП"
В случае отсутствия USB-токена аутентификация будет прервана (рисунок 185).

Рисунок 185 -Сбой аутентификации "Рутокен ЭЦП"
В консоль будет выведено сообщение:
Smartcard authentication cancelled