Due to changes in the legislation regarding trust services (“About electronic trust services” Ukraine), the company needs several departments to work with keys located on tokens (at the moment, the question of the number of hardware keys is still open).

As a tool with the lowest cost (free of charge), the choice immediately fell on usbip . The server on Ubintu 18.04 earned thanks to the publication Taming USB / IP and successfully tested on several flash drives (for lack of a token at that time). No special problems, except for exclusive ownership (reservation per user) at that time, were identified. It is clear that in order to organize access for several users (at least two, for starters), it is necessary to share their access in time and make them work in turn.

The question was: How to make everything work with the smallest dances ...

Clumsy piece

Here's what worked fine for us:

first: connecting on.bat

usbip -a 172.16.12.26 4-1 msg * "/    " 

second: shutdown off.bat

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

without relying on user awareness, the scripts were integrated into token.bat

 on.bat | off.bat 

What happens: all the files are in the same folder, start with the token.bat file, if the connection is closed, the user immediately receives a message about the key inaccessibility, in another case, only after 180 pings. These lines of code can be equipped with "@ECHO OFF" and the direction of the console to "> nul" so as not to shock the user very much, but it is not necessary to start testing. The primary “run” on the USB drive showed that everything is predictable, reliable, clear. Moreover, from the server side, no manipulations are necessary.



Naturally, when working directly with the token, everything went wrong as expected: when physically connected in the device manager, the token is registered as 2 devices (WUDF and smart card), and when connected to the network only as WUDF (although this is enough to request a PIN code).



It also turned out that the brutal “taskkill” is not so severe, and closing the connection on the client is problematic, and even if it succeeds, it does not guarantee closing it on the server for it.

Having sacrificed all consoles on the client, the second script took the form:

 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 

although its effectiveness is less than 50%, as the server stubbornly continued to consider the connection open.

Connection problems led to thoughts about upgrading in the server side.

Server part

What do you need:

1. Disconnect inactive users from the service.
2. See who is currently using (or still taking) a token.
3. See if the token is connected to the computer itself.

It was decided to solve these problems using the crontab and apache services. The discreteness of overwriting the state of the monitoring results of points 2 and 3 of interest to us indicates that the file system can be located on ramdrive. Added line to / etc / fstab

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

A script folder with scripts has been created in the root: unmount-mount the usb_restart.sh token

 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 

getting a list of active devices 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 

obtaining a list of active IPs (with subsequent refinement with displaying user identifiers) usbip_client_ip.sh

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

crontab itself looks like this:

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

So we have: every 5 minutes a new user can connect, regardless of who worked with the token. Using the symlink, the / ramdrive folder is connected to the http server, in which 2 text files are stored, indicating the status of the usbip server.

Part next: "Ugly in a wrapper"

ІІ option. A little to please the user with at least some less intimidating interface. Perplexed by the fact that users have different versions of Windows with different frameworks, different rights, I did not find a less problematic approach than Lazarus (I certainly am in C #, but not in this case). You can run bat files from the interface in the background, minimized, but without proper testing, I personally hold the opinion: you need to visualize to collect user dissatisfaction.



The following tasks were solved by the interface and software:

1. Displays if the token is currently busy.
2. At the first launch, the initial setup with the generation of the “correct” bat files that implement the launch and interruption of the token server session. At subsequent launches, the implementation of the "service" mode by password.
3. Checking the connection with the server, as a result of which it polls for employment or displays messages about problems. When communication resumes, the program automatically starts to work as usual.

Work with the WEB server is implemented by means of the optional fphttpclient snap-in.


there will be a link to the current version of the client

there is also a continuation of considerations on the subject of the article, as well as a partial initial enthusiasm for the VirtualHere product with its features ...