В этом посте я покажу как обойти подводные камни при настройке терминала, который мог бы одинаково хорошо работать, как с Рутокеном ЭЦП так и с Рутокеном S.

Все дело в том что на некоторых дистрибутивах linux имеются проблемы совместной работы libccid и openct с демоном pcscd.

И тот и другой "драйвер" поддерживают Рутокен ЭЦП, однако при одновременной работе они могут блокировать друг друга.

Выглядеть это может вот так:

Вывод pcsc_scan:

Вывод pcscd -afddddd:

А фактически это будет выражаться тем, что Рутокен ЭЦП не будет виден в прикладных программах.

Решить это можно разными способами, но наиболее простой это отключение поддержки Рутокена ЭЦП в openct.

В файле /usr/lib/pcsc/drivers/openct-ifd.bundle/Contents/Info.plist нужно убрать следующие строки:

после сохранения изменений следует перезапустить openct, например так:

# service openct restart

после чего pcscd увидит Рутокен ЭЦП

тонкий терминал linux должен отвечать следующим требованиям

1) наличие libpcsclite, pcscd
2) наличие libopenct, openct для Рутокена S (скомпилированные с поддержкой openct-ifd.bundle)
3) наличие libccid для Рутокена ЭЦП

4) наличие rdesktop, скомпилированного с поддержкой смарт-карт

Теперь чуть более подробно:

Программное обеспечение pcsc-lite является де-факто стандартным смарткарточным middleware в мире *nix.
Оно представляет собой аналог Windows ресурс-менеджера winscard.dll

Демон pcscd работает со смарткартами через своего рода "драйвера", которые обычно находятся в системном каталоге

/usr/lib/pcsc/drivers

Для Рутокена ЭЦП драйвером является стандартная библиотека libccid, которая поддерживает почти все известные ccid-устройства.

Для Рутокена S драйвером будет являться скомпилированный особым образом OpenCT.
Когда OpenCT компилируется с флагом

--with-bundle

в папке

/usr/lib/pcsc/drivers

появляется openct-ifd.bundle.

Это и есть pcsc-драйвер для Рутокена S.

Итак, для работы c Рутокеном S потребуются libpcsclite, pcscd и libopenct, openct (по особому сконфигурированные)

Однако, не во всех Linux дистрибутивах OpenCT скомпилирован правильно.
Например, в Ubuntu был баг, который благополучно пофикшен.  https://bugs.launchpad.net/ubuntu/+sour … bug/436545
Зато теперь по крайней мере в Ubuntu начиная с версии 10.04 (lucid) проблем нет.

Для работы с Рутокеном ЭЦП потребуются libpcsclite, pcscd и libccid.

Бывает так что версия libccid слишком стара для поддержки Рутокена ЭЦП.
Узнать это можно здесь http://forum.rutoken.ru/topic/1644/

Ну и самое главное: rdesktop

rdesktop должен быть скомпилирован с поддержкой смарт-карт, это включается опцией --enable-smartcard

Не во всех linux дистрибутивах rdesktop распространяется с такой опцией, но пакет rdesktop-smartcard достаточно часто встречается в сторонних репозиториях и найти его для нужного дистрибутива обычно не представляет проблем.

Для того, чтобы rdesktop попытался увидеть Рутокен ему нужно указать опцию:

-r scard

Пытаюсь понять, возможно ли сделать аутентификацию на WebDav-сервере (apache2) с помощью x.509 сертификата и ruToken.
Сертификат и ключ помещены в ruToken с помощью rtCert. Про подключении токена сертификат помещается в "Личные".
При аутентификации через IE все в порядке - выдается windows-окно запроса выбора сертификата и потом запрос PIN от ruToken CSP.

Проблема при попытке подключения сайта в качестве web-folder (webdav) - "Подключить сетевой диск" - "Подключение к сайту ..."
Запрос на выбор сертификата в этом случае тоже выдается, обращения к токену какое-то видимо идет, т.к. светодиод после выбора сертификата несколько раз мигает, однако запроса PIN нет, а Windows выдает запрос имени пользователя-пароля, хотя естественно, там никаких паролей нет.
В журнале системы ошибка с evenid 36887, источник - Schannel о неустранимой ошибке 40.
Естественно, с с этим же сертификатом и ключом размещенным в реестре, а не в ruToken-е, все замечательно подключается.

Для примера приведу один из сайтов построенныз на аутентификации eToken ключа..

На компьютер клиента устанавливается необходимые драйвера и_токен а также в браузер устанавливается персональный сертификат разработчика. Когда пользователь открывает сайт, сначала посылается предъявляется сертификат, затем это вэб оболочка каким-то образом иницирует действие, при котором открывается окно стандартного приложения и_токен, где запрашивается ПИН пользователя для и_токена (естевственго что ключ уже находтся в USB порту на клиента), пользователь вводин свой пин,и если он НЕ верный то страница дает ошибку. Не могу понять каким образом данное вэб приложение инициирует запрос ПИН-а у пользователя для и_токен-а.

1) Возможна ли такая же схема с ру_токеном? (если да то пожалуйста объясните схему)
2) Возможно ли схема при которой сам сертификат для предъявления серверу будет хранится в самом ключе, и при вводе ПИН-а пользователя будет предъявляеть его серверу?

p.s. Как я понимаю при вводе ПИН-а на сервер отпарвляется public key и private key который затем сверяется на сервере.

Работаб программистом и хочу сделать такой тип аутэнтификации в своих вэб приложениях

Заранее вам благодарен.