ProHoster > Blog > Pentadbiran > Perkongsian rangkaian token kriptografi antara pengguna berasaskan usbip

Perkongsian rangkaian token kriptografi antara pengguna berasaskan usbip

Sehubungan dengan perubahan dalam perundangan mengenai perkhidmatan amanah ("Mengenai perkhidmatan amanah elektronik" Ukraine), perusahaan memerlukan beberapa jabatan untuk bekerja dengan kunci yang terletak pada token (pada masa ini, persoalan bilangan kunci perkakasan masih terbuka ).

Sebagai alat dengan kos paling rendah (percuma), pilihan segera jatuh usbip. Pelayan di Ubintu 18.04 mula berfungsi terima kasih kepada penerbitan Menjinakkan USB/IP dan berjaya diuji pada beberapa pemacu kilat (kerana kekurangan token pada masa itu). Tiada masalah khas selain pemilikan monopoli (tempahan untuk pengguna) dikenal pasti pada masa itu. Adalah jelas bahawa untuk mengatur akses untuk beberapa pengguna (sekurang-kurangnya dua, sebagai permulaan), adalah perlu untuk membahagikan akses mereka dalam masa dan memaksa mereka untuk bekerja secara bergilir-gilir.

Persoalannya ialah: Bagaimana saya boleh melakukannya dengan jumlah tarian yang paling sedikit supaya semuanya berfungsi untuk semua orang...

Bahagian itu kekok

Perkongsian rangkaian token kriptografi antara pengguna berasaskan usbip
Pilihan 1. Beberapa pintasan ke fail kelawar, iaitu
a) Menyambung kekunci akses.
b) Sengaja memutuskan sambungan.

Perenggan "Π±Β» kontroversi, jadi ia telah memutuskan untuk memberikan jumlah masa untuk bekerja dengan kunci pada 3 minit.

Keistimewaan klien usbip ialah selepas ia dilancarkan, ia tetap tergantung di konsol tanpa mengganggu sesi konsol, anda boleh menutup sambungan "secara kasar" dari sisi klien dan juga dari sisi pelayan.

Inilah perkara yang berkesan untuk kami:

pertama: sambungan on.bat 

usbip -a 172.16.12.26 4-1
msg * "Подпись/Ρ‚ΠΎΠΊΠ΅Π½ нСдоступны ΠΈΠ»ΠΈ заняты "

kedua: penutupan off.bat

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

Tanpa bergantung pada kesedaran pengguna, skrip digabungkan menjadi token.bat

on.bat | off.bat

Apa yang berlaku: semua fail berada dalam folder yang sama, dilancarkan oleh fail token.bat, jika sambungan ditutup pengguna serta-merta menerima mesej tentang kunci tidak tersedia, dalam kes lain, hanya selepas 180 ping. Baris kod di atas boleh dilengkapi dengan "@ECHO OFF" dan arah konsol ke "> nul" supaya tidak terlalu mengejutkan pengguna, tetapi tidak perlu menjalankan ujian. "Larian" awal pada pemacu USB menunjukkan bahawa segala-galanya boleh diramal, boleh dipercayai dan jelas. Selain itu, tiada manipulasi diperlukan dari sisi pelayan.

Perkongsian rangkaian token kriptografi antara pengguna berasaskan usbip

Sememangnya, apabila bekerja secara langsung dengan token, semuanya tidak berjalan seperti yang diharapkan: dengan sambungan fizikal dalam pengurus peranti, token didaftarkan sebagai 2 peranti (WUDF dan kad pintar), dan dengan sambungan rangkaian hanya sebagai WUDF (walaupun ini sudah cukup untuk meminta kod PIN).

Perkongsian rangkaian token kriptografi antara pengguna berasaskan usbip

Ia juga ternyata bahawa "taskkill" yang kejam tidak begitu teruk, dan menutup sambungan pada pelanggan adalah bermasalah dan walaupun ia berjaya, ia tidak menjamin menutupnya untuknya di pelayan.

Setelah mengorbankan semua konsol pada klien, skrip kedua mengambil bentuk:

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

walaupun keberkesanannya kurang daripada 50%, kerana pelayan berdegil terus menganggap sambungan terbuka.

Masalah dengan sambungan membawa kepada pemikiran tentang menaik taraf bahagian pelayan.

Bahagian pelayan

Apa yang anda perlukan:

  1. Putuskan sambungan pengguna yang tidak aktif daripada perkhidmatan.
  2. Lihat siapa yang sedang menggunakan (atau masih meminjam) token tersebut.
  3. Lihat jika token disambungkan ke komputer itu sendiri.

Masalah ini telah diselesaikan menggunakan perkhidmatan crontab dan apache. Sifat diskret untuk menulis semula keadaan keputusan pemantauan mata 2 dan 3 yang menarik minat kami menunjukkan bahawa sistem fail boleh ditempatkan pada ramdrive. Menambahkan baris pada /etc/fstab 

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

Folder skrip dengan skrip telah dibuat dalam akar: unmounting-mounting 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

mendapatkan senarai peranti aktif 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

mendapatkan senarai IP aktif (dengan pengubahsuaian seterusnya untuk memaparkan ID pengguna) usbip_client_ip.sh

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

crontab itu sendiri kelihatan seperti ini:

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

Jadi kami mempunyai: setiap 5 minit pengguna baharu boleh berhubung, tidak kira siapa yang bekerja dengan token. Folder /ramdrive disambungkan ke pelayan http menggunakan symlink, di mana 2 fail teks disimpan, menunjukkan status pelayan usbip.

Bahagian seterusnya: "Hodoh dalam pembungkus"

Pilihan II. Untuk menggembirakan pengguna sedikit dengan sekurang-kurangnya antara muka yang kurang menakutkan. Hairan dengan fakta bahawa pengguna mempunyai versi Windows yang berbeza dengan rangka kerja yang berbeza, hak yang berbeza, pendekatan yang kurang bermasalah daripada Lazarus Saya tidak menjumpainya (saya sudah tentu untuk C#, tetapi tidak dalam kes ini). Anda boleh melancarkan fail kelawar dari antara muka di latar belakang, diminimumkan, tetapi tanpa ujian yang betul, saya secara peribadi berpendapat: anda perlu menggambarkannya untuk mengumpul ketidakpuasan hati pengguna.

Perkongsian rangkaian token kriptografi antara pengguna berasaskan usbip

Tugas berikut telah diselesaikan oleh antara muka dan perisian:

  1. Memaparkan sama ada token sedang sibuk.
  2. Pada pelancaran pertama, persediaan awal melibatkan penjanaan fail kelawar "betul" yang melaksanakan pelancaran dan gangguan sesi dengan pelayan token. Pada permulaan berikutnya, pelaksanaan mod "perkhidmatan" menggunakan kata laluan.
  3. Menyemak kehadiran sambungan dengan pelayan, akibatnya ia meninjau sama ada ia sibuk atau memaparkan mesej tentang masalah. Apabila komunikasi disambung semula, program secara automatik mula berfungsi dalam mod biasa.

Bekerja dengan pelayan WEB dilaksanakan menggunakan snap-in fphttpclient tambahan.


di sini akan menjadi pautan ke versi semasa pelanggan

terdapat juga pertimbangan lanjut mengenai subjek artikel, serta semangat awal separa untuk produk VirtualHere dengan ciri-cirinya...

Sumber: www.habr.com

Tambah komen