# [howto] Gentoo na pen-kluczyk

## manwe_

Howto na prośbę ludzi z forum. 

Wersja 0.1.

Ostatni update: 29.11.2006

Jest to moje pierwsze howto, więc proszę nie oczekiwać zbyt wiele  :Wink: 

Gentoo na pen-kluczyk

Cel?

Chcemy, żeby nasze Gentoo było mocno przywiązane do jakiegoś pendrive'a [lub innego nośnika który można łatwo zabrać ze sobą, a przy okazji generuje zdarzenie udev'a (dyskietka z tego powodu odpada), w moim przypadku jest to karta microSD - dlatego będę pisał w odniesieniu do niej]. Przychodzimy do komputera, wkładamy kartę i nie potrzebne jest już wpisywanie większości haseł, ekran zostaje odblokowany, etc. Odchodzimy - zabieramy kluczyki logowania ze sobą, ekran zostaje zablokowany, ... lista możliwości jest bardzo duża.

Co potrzebujemy?

1. udev - obsługa akcji plug/unplug

2. xscreensaver - blokowanie ekranu

3. pam_usb - logowanie i su bez haseł

4. Xdialog - upiększacz

udev po raz pierwszy

Ogólnie o obsłudze można poczytać na stronie http://www.gentoo.org/doc/pl/udev-guide.xml i http://www.reactivated.net/writing_udev_rules.html . Ja skupię się tylko na niezbędnym minimum. Tworzymy swój plik, gdzie będą nowe regułki w katalogu /etc/udev/rules.d/, najlepiej z niskim numerem, wtedy będą one wywołane jako pierwsze. 

```
$ cat /etc/udev/rules.d/00-manwe.rules 

#ca, own

ACTION=="add", DRIVERS=="mmcblk", ATTRS{serial}=="0x00d80029", RUN+="/usr/bin/sudo -u manwe /bin/mount /mnt/ca"

ACTION=="add", DRIVERS=="mmcblk", ATTRS{serial}=="0x00625787", RUN+="/usr/bin/sudo -u manwe /bin/mount /mnt/ca"

ACTION=="mount", DRIVERS=="mmcblk", ATTRS{serial}=="0x00d80029", RUN+="/root/scripts/screen-locker-add"

ACTION=="mount", DRIVERS=="mmcblk", ATTRS{serial}=="0x00625787", RUN+="/root/scripts/screen-locker-add"

ACTION=="umount", KERNEL=="mmcblk0p1", RUN+="/root/scripts/screen-locker-remove"

ACTION=="remove", KERNEL=="mmcblk0", RUN+="/bin/umount -l /mnt/ca"

```

To w zasadzie wszystko  :Wink:  Co my tu mamy? 

```
ACTION=="add", DRIVERS=="mmcblk", ATTRS{serial}=="0x00d80029", RUN+="/usr/bin/sudo -u manwe /bin/mount /mnt/ca"
```

Czytamy po kolei: jeżeli otrzymaliśmy akcję dodania urządzenia [ == to if ], użytym sterownikiem do obsługi urządzenia jest mmcblk [czytnik kart SD, w przypadku pendrive'a będzie to usb-storage], oraz numer seryjny karty to 0x00...., uruchom polecenie w RUN+="". Tutaj po prostu zrobiliśmy automount karty. Ktoś zapyta po co robię to przez sudo? Nie chciało mi się pisać całego mount z opcjami, a user manwe ma pozwolenie na montowanie do /mnt/ca. Poza tym przy zmianie wpisów w fstab, nie będę musiał modyfikować tej linijki. 

Teraz jeszcze pobranie numeru seryjnego karty [akurat automount można zrobić dla każdej i pominąć ATTRS, ale ja tego nie chciałem]. Najpierw uruchamiamy 

```
udevinfo -q path -n /dev/mmcblk0
```

 Polecenie to odpytuje udev o ścieżkę [w /sys] dla urządzenia /dev/mmcblk0 [dla pendrive będzie to prawdopodobnie /dev/sda]. Otrzymujemy /block/mmcblk0 [dla pendrive coś koło /block/sda]. Teraz pytamy o właściwości urządzenia 

```
udevinfo -a -p /block/mmcblk0
```

 Spośród tego co dostaliśmy wygrzebujemy ATTRS{serial}=="0x....". Jak widać, właściwości jest sporo, pewnie można by warunkować regułki jeszcze na podstawie innych, ale serial jest dobry. 

udev once again

No dobra, to mamy automount. Teraz kolejna akcja 

```
ACTION=="mount", DRIVERS=="mmcblk", ATTRS{serial}=="0x00d80029", RUN+="/root/scripts/screen-locker-add"
```

 Zmieniło się porównanie ACTION i wywołanie RUN. To zdarzenie wywołane zostanie zaraz po poprawnym zamontowaniu partycji urządzenia [zaskakujące, co nie?  :Wink: ]. Co robi skrypt?

```

#!/bin/bash

        killall -9 Xdialog &

        killall xscreensaver morph3d

        sleep 1

        killall -9 xscreensaver morph3d

```

Niewiele. Zabija wszystkie Xdialog'i [o tym później] oraz grzecznie prosi wygaszacz ekanu żeby sobie poszedł w cholerę. Po sleep 1 ubija go na dobre [gdyby nam się uchował]. Czyli tak. Wkładamy kartę, jest montowana, odpowiednie symlinki są już poprawne [o tym również później], a ekran odblokowany. Tutaj oczywiście możesz dopisać sobie jeszcze stos akcji, jak na przykład odegranie jakiegoś wave "whazzzup".

udev po raz ostatni

I na koniec, odejście od komputera 

```
ACTION=="umount", KERNEL=="mmcblk0p1", RUN+="/root/scripts/screen-locker-remove"

ACTION=="remove", KERNEL=="mmcblk0", RUN+="/bin/umount -l /mnt/ca"
```

. Pierwsze co się rzuca w oczy to brak sprawdzania serial, niestety udev już nie serwuje nam informacji o urządzeniu kiedy zostanie wyjęte [a szkoda  :Wink: ]. Przy ACTION=="remove" robimy odmontowanie [o opcji -l więcej w man]. W tym miejscu dobrze mieć na uwadze, że akcja umount zostaje wywołana po wyjęciu karty, więc jeżeli coś na niej mieszaliśmy, warto wywołać wcześniej sync, żeby dane zostały zsynchronizowane. 

I jeszcze skrypt, który zostaje uruchomiony po umount. 

```
#!/bin/bash

        if [ `ps aux | grep xscreensaver | grep -v grep | wc -l` -gt 0 ]; then exit; fi

        if [ $# -eq 0 ]; then 

                /root/scripts/screen-locker-remove x & 

                disown %1

                exit

        fi

        for ((a=0;a<=100;a++)); do echo $a; sleep 0.049; done | DISPLAY=:0.0 Xdialog --title "Screen locker" --gauge "Close window to avoid locking screen" 6 40; if [ $? -eq 255 ]; then exit; fi

        sudo -u manwe /usr/bin/xscreensaver -display :0.0 -no-splash &

        sleep 1

        /usr/bin/xscreensaver-command -lock

```

Najpierw upewniamy się że screensaver nie działa, bo i po co wtedy uruchamiać. Potem fork w tło [udev wstrzymuje swoje działanie dopóki skrypt nie skończy, w tym przypadku to jest zbyt długo]. Dalej prosty Xdialog który wisi nam na ekranie z progressbar'em przez ~5 sekund. Jeżeli go zamkniemy [ zmienna $? dostanie wartość 255 ] skrypt wyjdzie i nie zablokuje ekranu, w przeciwnym wypadku uruchomi demona xscreensaver, a zaraz potem zablokuje ekran. Tutaj widać po co było zabijanie Xdialog przy ACTION=="mount" - dla wygody, kiedy szybko wyciągniemy i włożymy kartę, dialog zostanie ubity nie zablokuje ekranu.

I tyle. Gdyby skończyć howto w tym miejscu mamy (od)blokowanie ekranu komputera. Ale przecież chcemy więcej  :Wink: 

pam_usb

Nie będę tutaj się rozpisywał jak tworzyć klucze pam_usb i uzupełniać regułki pam, od tego są inne howto, jak na przykład http://www.pamusb.org/quickstart.html . Wszystko sprowadza się do katalogów ~/.auth i klucza publicznego w środku, dla użytkowników do których chcemy logować się bez hasła [nie dotyczy do oczywiście ssh] oraz .auth i kluczy prywatnych na karcie. Mała uwaga, klucze muszą mieć niskie prawa [0400, bo i po co nam więcej] oraz muszą należeć do użytkownika, którego obsługują. Czyli co? To znaczy, że każdy musi mieć swój, na dobrą sprawę może być i ten sam. 

Na koniec małe modyfikacje w /etc/pam.d/login: 

```

auth       required     pam_securetty.so

auth       sufficient   pam_usb.so fs=ext3 check_if_mounted !check_device force_device=/dev/mmcblk0p1 log_file=/var/log/pam_usb.log

auth       include      system-auth

....

```

oraz /etc/pam.d/su: 

```

auth       required     pam_wheel.so use_uid

auth       sufficient   pam_usb.so fs=ext3 check_if_mounted !check_device force_device=/dev/mmcblk0p1 log_file=/var/log/pam_usb.log

auth       include              system-auth

```

Krótkie wytłumaczenie jak to działa [więcej w help dla usb_pam], spełnienie warunku pam_usb uznajemy za wystarczające do zalogowania/su [równie dobrze możemy dać required, wtedy do zalogowania się będzie potrzebne zarówno hasło jak i klucz - bardzo dobrze zabezpieczenie]. (Nie)stety pam_usb chce domyślnie montować urządzenie na chwilę sprawdzania kluczy, a nasze już jest zamontowane, stąd takie, a nie inne opcje. 

I tyle, tak działa, a raczej powinno  :Smile: 

kluczyk ssh

Ostatnia rzeczą jaką uznałem za niezbedną do zabezpieczenia jest mój klucz prywatny ssh. Pozwala on na zalogowanie się na około 20 innych komputerów, więc nie mogę pozwolić sobie na utratę. Tutaj sprawa jest banalna, przenosimy ~/.ssh/id_dsa na kartę, a na dysku tworzymy symlink. Openssh na szczęście nie krzyczy kiedy nie może odczytać pliku wskazywanego przez symlink, więc nawet bez karty, będziemy mogli spokojnie się wszędzie logować, ale z hasłem. 

ctrl+shift+backspace || ctrl+c

Przy okazji całego tego zabezpieczania [nie używam xdm'a] wyszedł problem obejścia xscreensaver'a. Wystarczy przejść na konsolę gdzie jestem zalogowany [ctrl+alt+F1], nacisnąć ctrl+c, X'y zostają zamknięte i ktoś ma darmowy dostęp do mojego konta. Na szczęście rozwiązanie przyszło dość szybko, dodajemy do .bashrc:

```
alias x="/usr/bin/startx; exit"
```

Proste, łatwe i przyjemne. W momencie kiedy X'y skończą pracę [lub zostaną przerwane] następuje natychmiastowe wylogowanie, a przy okazji oszczędzamy pisania pięciu liter  :Wink: 

koniec?

W zasadzie to tyle. Tak jak pisałem u góry, to moje pierwsze howto, więc pewnie nie jest zbyt ładne i składne. Na pewno wszystko da się zrobić ładniej/lepiej/efektywniej, no ale były prośby o, to spisałem co zrobiłem w jeden nudny wieczór  :Smile: 

Jeżeli będą chętni, to następne co mogę napisać, jak zrobić samorestartującą-samorekonfigurującą się alsę w momencie wpięcia/wypięcia głośników usb - czyli jak hotplug może być przydatny.

----------

## Yatmai

Bardzo fajny art  :Smile:  Kiedyś się bawiłem w coś takeigo, że vman automatycznie montuje pendrive'a, na którym są klucze pam, czyli w konsewkencji bez pen'a nie zalogujesz sie na kompa (nie testowałem na X'ach  :Very Happy: ) ale z pewnością wzbogacę swoją metodę o tutejsze rozwiązania  :Smile: 

A propos hotplug, to nie mam głośników na usb i nie planuje, ale chętnie poczytam o możliwościach tego hotplug'a w ujęciu praktycznym  :Smile: 

----------

## v7n

gdyby ktoś jeszcze nie wiedział, ew. by mu nieodpowiadał tip podany w ostatnim akapicie, to powiem, że alt+ctrl+backspace i alt_ctrl+fx można zablokować w xorg.conf.

----------

## akroplas

!Bardzo! dobrze napisane, a może poprostu ja takie lubie  :Wink: 

Jedno pytanie:

Czy '/root/scripts/screen-locker-remove' jest wywoływane po odmountowaniu jakiejkolwiek karty? A jezeli nie, to gdzie jest sprawdzany ten warunek ?

Jeszcze raz dzięki za dobre howto

----------

## manwe_

Jest uruchamiane dla każdej karty, nie wpadłem na szybkie rozwiązanie skoro urządzenia już nie ma w kompie. Trzeba by tworzyć jakiś plik w momencie wpakowania karty o odpowiednim ID, czy cuś. Ale akurat nie przeszkadza mi to, operuję na 3 kartach, przy czym w trakcie zmiany akcja włożenia którejś z głównych zabija ten opóźniający Xdialog, więc problemu prawie nie ma - ekran się nie blokuje.

----------

## pancurski

Mam takie pytanko, czy mozna jakoś połączyc pen-kluczyk z partycja hdd zaszyfrowana np. dm-cryptem?

Chodzi o to ze odczyt i zapis na taką partycje byłby możliwy tylko w przypadku podłączonego pen-kluczyka.

----------

## Gabrys

 *frondziak wrote:*   

> Mam takie pytanko, czy mozna jakoś połączyc pen-kluczyk z partycja hdd zaszyfrowana np. dm-cryptem?
> 
> Chodzi o to ze odczyt i zapis na taką partycje byłby możliwy tylko w przypadku podłączonego pen-kluczyka.

 

Można można, tylko trzeba pamiętać, że jak na takie poważne rozwiązanie, to pen-drive jest zbyt zawodny. Po około 1M użyciu możemy liczyć się z utratą klucza  :Sad: .

----------

## pancurski

a jest jakies alternatywne rozwiązanie? coś innego niż pen

----------

## Gabrys

Oczywiście, szyfrowanie partycji z kluczem "na hasło", to znaczy:

1. generowanie losowego klucza. Klucz => "xyz".

2. szyfrowanie za pomocą "xyz" partycji.

3. zaszyfrowanie za pomocą jakiegoś algorytmu klucza "xyz" z hasłem takie jak masz w systemie ("abc"). I takie zaszyfrowane hasło ląduje na dysk to pliku "abc.key".

I teraz jak się logujesz, to z pomocą pam_mount sprawa wygląda tak:

1. wpisujesz hasło "abc".

2. PAM cię autoryzuje i przekazuje hasło "abc" do programu "X".

3. program "X" bierze Twoje hasło "abc", odkodowuje nim hasło z pliku "abc.key". W ten sposób dostaje klucz "xyz".

4. z kluczem "xyz" montuje zaszyfrowaną partycję (np. /home/twój_user).

Wszystko dzieje się pod maską logowania, więc jest bardzo przyjemne. Link: https://forums.gentoo.org/viewtopic-t-274651.html Trochę stare i są już inne wersje, ale na nowych wszystko chodzi.

----------

## Mr Adam

a nie lepiej wpakować kernela na pen'a?  :Wink: 

----------

## Gabrys

Zależy jaki poziom bezpieczeństwa chcemy osiągnąć. W konfiguracji dysk-na-hasło-loginowe (jak opisałem powyżej). Nawet mając fizyczny dostęp do komputera i będąc super mega wypaśnym informatykiem nic nie zrobisz z danymi, bo są zaszyfrowane  :Wink: .

----------

## Johnny_Bit

a jest może taki myk coby na serwer w lanie dało się zalogować tylko jak w serwer wpięty jest pen?

----------

## quosek

nie wystarczy, ze wlozenie pena = start sshd, wyjecie = wylaczenie sshd ? na podstawie tego howto szybko sie to zrobi

----------

## Gabrys

Wszystko się da (a może nawet i więcej).

Pytanie tylko, czy to jest komuś naprawdę potrzebne, jak bardzo potrzebne i czy ma czas, by to napisać  :Razz: .

----------

## SlashBeast

Fajna sprawa, zaraz zrobie sobie po wsadzeniu pewna montowanie /home po truecrypcie i linkowanie shadow z pendrive, bez pena ani na roota nie wskocze, ani nic. Jakby ktoś ukradł komputer to ani do plików osobistych się nie dostanie, ani johnem nie wykrakuje hasła bo nie ma shadow.  :Smile: 

PS. Przepraszam, za odkopanie tematu.

----------

## BeteNoire

@manwe, chciałem zrobić sobie coś podobnego, ale utknąłem w czwartej linijce:

```
KERNEL=="sda", DRIVERS=="usb", ATTRS{serial}=="000010004666BA000087", NAME="sit"

KERNEL=="sda1", DRIVERS=="usb", ATTRS{serial}=="000010004666BA000087", NAME="sit1"

ACTION=="add", DRIVERS=="usb", ATTRS{serial}=="000010004666BA000087", RUN+="/usr/bin/sudo -u bete /bin/mount /mnt/sit"

ACTION=="mount", DRIVERS=="usb", ATTRS{serial}=="000010004666BA000087", RUN+="/bin/touch /tmp/test"
```

Czemu ona nie jest wykonywana?

----------

## matiit

A czy da się zrobić żeby rozpoznawało mi jakoś bluetootha na usb?

Bo nie wiem co dać.

```
ACTION=="add", RUN+="/moj/skrypt"
```

Ale musi udev wiedzieć, że chodzi o tego dongla... jak się do tego odwołać?

----------

