En raison des changements législatifs concernant les services de confiance (« Sur les services de confiance électroniques » en Ukraine), l'entreprise a dû permettre à plusieurs départements de travailler avec des clés situées sur des jetons (à ce jour, la question du nombre de clés matérielles est encore en suspens).

Comme outil à moindre coût (gracieusement), le choix s'est immédiatement porté sur usbip. Le serveur sous Ubintu 18.04 a fonctionné grâce à la publication Maîtrisons l'USB/IP et a été testé avec succès sur plusieurs clés USB (en l'absence d'un jeton à ce moment-là). Aucun problème particulier, à part la possession monopolisée (réservation pour un utilisateur), n'a été identifié à ce moment-là. Il est évident que pour organiser l'accès pour plusieurs utilisateurs (au moins deux, pour commencer), il est nécessaire de diviser leur accès dans le temps et de les faire travailler à tour de rôle.

La question s'est posée : Comment, avec le moins de tracas possibles, faire en sorte que tout fonctionne pour tout le monde…

Une approche rudimentaire

Première variante. Plusieurs raccourcis vers des fichiers bat, à savoir
a) Connexion de la clé d'accès.
b) Désactivation intentionnelle.

Le point «b» est discutable, il a donc été décidé de donner un temps de travail avec la clé de 3 minutes.

La particularité du client usbip est qu'après son lancement, il reste actif dans la console. Sans interrompre la session console, la connexion peut être fermée « brutalement » côté client et également côté serveur.

Voici ce qui a bien fonctionné pour nous :

premier : connexion on.bat

usbip -a 172.16.12.26 4-1
msg * "La signature/le jeton n'est pas disponible ou occupé "

deuxième : déconnexion off.bat

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

ne comptant pas sur le bon sens de l'utilisateur, les scripts ont été combinés dans token.bat

on.bat | off.bat

Ce qui se passe : tous les fichiers se trouvent dans un même dossier, le lancement se fait avec le fichier token.bat, si la connexion est fermée par l'utilisateur, un message immédiat indique que la clé est indisponible, dans l'autre cas, seulement après 180 pings. Les lignes de code fournies peuvent être équipées de « @ECHO OFF » et avec la direction de la console vers « > nul » afin de ne pas trop choquer l'utilisateur, mais pour le lancement dans les tests, ce n'est pas obligatoire. Le premier « essai » sur la clé USB a montré que tout est prévisible, fiable et précis. De plus, il n'est pas nécessaire d'effectuer de manipulations du côté serveur.

Évidemment, lors de l'utilisation directe avec le token, tout ne s'est pas déroulé comme prévu : lors d'une connexion physique dans le gestionnaire de périphériques, le token est enregistré comme 2 appareils (WUDF et carte à puce), mais lors de la connexion réseau, seulement comme WUDF (bien que cela suffise pour demander le code PIN).

Il s'est également avéré que la terrible commande «taskkill» n'est pas si sévère et que la fermeture de la connexion côté client pose problème, et même si cela réussit, cela ne garantit pas la fermeture pour celui-ci sur le serveur.

En sacrifiant tous les consoles côté client, le second script a pris la forme :

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

bien que son efficacité soit inférieure à 50 %, car le serveur continuait obstinément à considérer la connexion comme non fermée.

Les problèmes de connexion ont conduit à réfléchir à une mise à niveau côté serveur.

Partie serveur

Ce dont vous avez besoin :

1. Déconnecter les utilisateurs inactifs du service.
2. Voir qui utilise actuellement (ou occupe encore) le token.
3. Vérifier si le token est connecté à l'ordinateur lui-même.

Ces tâches ont été résolues à l'aide des services crontab et apache. La discrétion de la réécriture de l'état des résultats de surveillance des points 2 et 3 montre que le système de fichiers peut être placé sur un ramdrive. La ligne suivante a été ajoutée à /etc/fstab :

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

Un dossier racine nommé script a été créé avec des scripts : démontage-montage du 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

obtention de la liste des appareils actifs 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

obtention de la liste des IP actives (avec des modifications ultérieures pour afficher les identifiants utilisateurs) usbip_client_ip.sh

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

le crontab lui-même ressemble à cela :

*/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/null)

Donc, nous avons : tous les 5 minutes, un nouvel utilisateur peut se connecter, peu importe qui a travaillé avec le token. Un dossier /ramdrive, connecté au serveur http via un lien symbolique, contient 2 fichiers texte, montrant l'état du serveur usbip.

Partie suivante : « Le laid dans l'emballage »

II option. Un peu de satisfaction pour l'utilisateur avec une interface moins intimidante. En tenant compte du fait que les utilisateurs ont différentes versions de Windows avec différents frameworks et droits, il n'y a pas d'approche moins problématique que Lazarus je n'en ai pas trouvé (je suis bien sûr pour C#, mais pas dans ce cas). Il est possible d'exécuter des fichiers bat depuis l'interface, même en arrière-plan, minimisés, mais sans essai adéquat, personnellement je pense qu'il est nécessaire de visualiser pour récolter les mécontentements des utilisateurs.

Les problèmes suivants ont été résolus par l'interface et la partie logicielle :

1. Affichage de l'occupation du token à ce moment.
2. Lors de la première exécution, une configuration initiale avec la génération de fichiers bat "corrects" réalisant le démarrage et l'arrêt de la session de travail avec le serveur du token est mise en œuvre. Lors des lancements suivants, mise en œuvre du mode "service" par mot de passe.
3. Vérification de la connexion au serveur, dont le résultat entraîne son interrogation sur l'occupation ou l'affichage d'un message sur les problèmes. Lors de la reprise de la connexion, le programme reprend automatiquement son fonctionnement normal.

Le travail avec le serveur WEB est réalisé par les moyens d'un module complémentaire fphttpclient.

il y a également une suite de réflexions sur le sujet de l'article, ainsi qu'un enthousiasme initial partiel pour le produit VirtualHere avec ses particularités…

Source : habr.com