Compartir en rede un token criptográfico entre usuarios baseados en usbip

En relación cos cambios na lexislación sobre servizos de confianza ("Sobre os servizos electrónicos de confianza" Ucraína), a empresa necesita que varios departamentos traballen con claves situadas en tokens (de momento, a cuestión do número de claves de hardware aínda está aberta ).

Como ferramenta co menor custo (gratis), a elección caeu inmediatamente usbip. O servidor de Ubintu 18.04 comezou a funcionar grazas á publicación Domar USB/IP e probado con éxito en varias unidades flash (debido á falta dun token nese momento). Non se identificaron problemas especiais que non fosen a propiedade monopolista (reserva para o usuario) nese momento. Está claro que para organizar o acceso de varios usuarios (polo menos dous, para comezar), é necesario dividir o seu acceso no tempo e obrigalos a traballar por quendas.

A pregunta era: como podo facelo coa menor cantidade de baile para que todo funcione para todos...

A parte é torpe

Compartir en rede un token criptográfico entre usuarios baseados en usbip
Opción XNUMX. Varios atallos para ficheiros bat, a saber
a) Conexión da clave de acceso.
b) Desconectar intencionadamente.

Parágrafo "б» polémico, polo que se decidiu dar a cantidade de tempo para traballar coa chave aos 3 minutos.

A peculiaridade do cliente usbip é que despois do lanzamento, permanece colgado na consola; sen interromper a sesión da consola, pódese pechar a conexión "aproximadamente" dende o lado do cliente e tamén desde o lado do servidor.

Aquí está o que funcionou ben para nós:

primeiro: conexión on.bat

usbip -a 172.16.12.26 4-1
msg * "Подпись/токен недоступны или заняты "

segundo: apagado apagado.morcego

ping 127.0.0.1 -n 180
taskkill /IM usbip.exe /F

Sen depender da conciencia do usuario, os guións combináronse ficha.bat

on.bat | off.bat

Que pasa: todos os ficheiros están no mesmo cartafol, lanzado polo ficheiro token.bat, se a conexión está pechada o usuario recibe inmediatamente unha mensaxe sobre a chave que non está dispoñible, noutro caso, só despois de 180 pings. As liñas de código anteriores pódense equipar con "@ECHO OFF" e a dirección da consola a "> nul" para non impactar demasiado ao usuario, pero non é necesario realizar probas. A "execución" inicial nunha unidade USB mostrou que todo era previsible, fiable e claro. Ademais, non se requiren manipulacións desde o lado do servidor.

Compartir en rede un token criptográfico entre usuarios baseados en usbip

Por suposto, ao traballar directamente co token, todo non saíu como se esperaba: cunha conexión física no xestor de dispositivos, o token rexístrase como 2 dispositivos (WUDF e unha tarxeta intelixente) e cunha conexión de rede só como WUDF (aínda que isto é suficiente para solicitar un código PIN).

Compartir en rede un token criptográfico entre usuarios baseados en usbip

Tamén resulta que o brutal "taskkill" non é tan grave, e pechar a conexión no cliente é problemático e aínda que tivese éxito, non garante pechalo no servidor.

Tras sacrificar todas as consolas do cliente, o segundo script tomou a forma:

ping 127.0.0.1 -n 180 > nul
taskkill /IM usbip.exe /F /T  > nul
ping 127.0.0.1 -n 10 > nul
taskkill /IM conhost.exe /F /T  > nul

aínda que a súa efectividade é inferior ao 50%, xa que o servidor seguía teimudamente considerando a conexión aberta.

Os problemas coa conexión levaron a pensar sobre a actualización do lado do servidor.

Parte do servidor

O que necesitas:

  1. Desconecte os usuarios inactivos do servizo.
  2. Vexa quen está usando (ou aínda tomando prestado) o token.
  3. Vexa se o token está conectado ao propio ordenador.

Estes problemas resolvéronse mediante os servizos crontab e apache. A natureza discreta de reescribir o estado dos resultados do seguimento dos puntos 2 e 3 que nos interesan indica que o sistema de ficheiros pódese localizar no ramdrive. Engadida unha liña a /etc/fstab

tmpfs   /ram_drive      tmpfs   defaults,nodev,size=64K         0       0

Creouse un cartafol de scripts con scripts na raíz: unmounting-mounting the token usb_restart.sh

usbip unbind -b 1-2
sleep 2
usbip bind -b 1-2
sleep 2
usbip attach --remote=localhost --busid=1-2
sleep 2
usbip detach --port=00

obtendo unha lista de dispositivos activos usblist_id.sh

usbip list -r 127.0.0.1 | grep ':' |awk -F ":" '{print $1}'| sed s/' '//g | grep -v "^$" > /ram_drive/usb_id.txt

obtención dunha lista de IPs activas (coa modificación posterior para mostrar os ID de usuario) usbip_client_ip.sh

netstat -an | grep :3240 | grep ESTABLISHED|awk '{print $5}'|cut -f1 -d":" > /ram_drive/usb_ip_cli.txt

o propio crontab ten o seguinte aspecto:

*/5 * * * * /!script/usb_restart.sh > /dev/null 2>&1
* * * * * ( sleep 30 ; /!script/usblist_id.sh > /dev/null)
* * * * * (sleep 10 ; /!script/usbip_client_ip.sh > /dev/hull)

Así temos: cada 5 minutos pódese conectar un novo usuario, independentemente de quen traballou co token. O cartafol /ramdrive conéctase ao servidor http mediante unha ligazón simbólica, na que se gardan 2 ficheiros de texto, que mostran o estado do servidor usbip.

Parte seguinte: "Feo nun envoltorio"

Opción II. Para agradar un pouco ao usuario con polo menos algunha interface menos intimidante. Desconcertado polo feito de que os usuarios teñan diferentes versións de Windows con diferentes marcos, dereitos diferentes, un enfoque menos problemático que Lazarus Non o atopei (por suposto son para C#, pero non neste caso). Podes lanzar ficheiros bate desde a interface en segundo plano, minimizados, pero sen as probas adecuadas, eu persoalmente son da opinión: cómpre visualizalos para recoller a insatisfacción dos usuarios.

Compartir en rede un token criptográfico entre usuarios baseados en usbip

A interface e o software resolvéronse as seguintes tarefas:

  1. Mostra se o token está ocupado actualmente.
  2. No primeiro lanzamento, a configuración inicial implica xerar os ficheiros bat "correctos" que implementan o lanzamento e a interrupción dunha sesión co servidor de tokens. Nos inicios posteriores, implementación do modo "servizo" mediante un contrasinal.
  3. Comprobando a presenza dunha conexión co servidor, como resultado da cal consulta se está ocupado ou mostra mensaxes sobre problemas. Cando se retoma a comunicación, o programa comeza a funcionar automaticamente en modo normal.

O traballo co servidor WEB realízase mediante o complemento adicional fphttpclient.


aquí haberá unha ligazón á versión actual do cliente

tamén hai máis consideracións sobre o tema do artigo, así como un entusiasmo inicial parcial polo produto VirtualHere coas súas características...

Fonte: www.habr.com

Engadir un comentario