Due to changes in the legislation regarding trust services (“On electronic trust services” Ukraine), the company has a need for 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 costs (free of charge), the choice immediately fell on usbip. The server on Ubuntu 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 other than exclusive ownership (reservation per user) were identified at that point in time. It is clear that in order to organize access for several users (at least two, for a start), it is necessary to divide them in time and make them work in turn.

The question became: How to make everything work for everyone with the smallest dances ...

Part clumsy

I option. Several shortcuts to bat files, namely
a) Access key connection.
b) Deliberately turning off.

Paragraph "б” is controversial, so it was decided to give the amount of time to work with the key in 3 minutes.

The peculiarity of the usbip client is that after it is launched, it remains hanging in the console, without interrupting the console session, you can close the connection “roughly” from the client side and also from the server side.

Here's what worked for us:

first: connection 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

not relying on the user's consciousness, the scripts were combined into token.bat

on.bat | off.bat

What happens: all files are in the same folder, launch by the token.bat file, if the connection is closed, the user immediately has a message about the unavailability of the key, otherwise, only after 180 pings. The above lines of code can be equipped with “@ECHO OFF” and console direction to “> nul” so as not to shock the user too much, but it is not necessary to run for testing. The initial "run" on the USB drive showed that everything is predictable-reliable-clear. And from the server side, no manipulations are needed.

Naturally, when working directly with the token, everything did not go 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 cruel "taskkill" is not so severe, and closing the connection on the client is problematic and even if it succeeded, it does not guarantee closing it for him on the server.

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 performance is less than 50%, as the server stubbornly continued to consider the connection open.

Connection problems led to thoughts of an upgrade in the back end.

Server part

What you need:

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

These tasks were solved using the crontab and apache services. The discreteness of rewriting the state of the monitoring results of points 2 and 3 of interest to us suggests that the file system can be located on a ramdrive. Added line to /etc/fstab

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

A script folder with scripts is created at the root: unmount-mount 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

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

getting a list of active IPs (with subsequent refinement to display user IDs) 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. The /ramdrive folder is connected to the http server using a symlink, in which 2 text files are saved showing the status of the usbip server.

Part next: "Ugly in a wrapper"

II option. To please the user a little with at least some less intimidating interface. Confused by the fact that users have different versions of Windows with different frameworks, different rights, a less problematic approach than Lazarus I didn't find it (of course I'm for C#, but not in this case). You can run bat files from the interface in the background, minimized, but without proper testing, I personally am of the opinion: you need to visualize to collect user dissatisfaction.

The following tasks were solved by the interface and the software part:

1. Displays whether the token is currently busy.
2. At the first start, the initial setup with the generation of the “correct” bat files that implement the launch and interruption of the session with the token server. At subsequent launches, the implementation of the "service" mode by password.
3. Checking the connection with the server, as a result of which it is polled about the busyness or messages about problems are displayed. When the connection is resumed, the program automatically starts working in the normal mode.

Working with the WEB server is implemented by means of the fphttpclient additional equipment.

here 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 ...

Source: habr.com