Logowanie za pomocą pary kluczy - publicznego i prywatnego (RSA/DSA)

• *BSD
• bezpieczeństwo

1. Wstęp
Chciałbym przedstawić w poniższym artykule (właściwie artykuliku :> ) bardzo przydatną funkcję SSH, jaką jest autentykacja za pomocą pary kluczy (publicznego i prywatnego). Dlaczego jest to tak bardzo przydatne? Dlatego, że w zależności od konfiguracji naszego serwera, poprawiamy jego bezpieczeństwo (dostęp do naszej maszyny mogą mieć osoby, które przysłały swój klucz publiczny - i został on zaakceptowany przez administratora :) ), lub też ułatwiamy sobie zdalną pracę, ponieważ nie trzeba podawać za każdym razem hasła. Z tym ostatnim ostrożnie, "puste" klucze są o tyle fajne, co kłopotliwe - zwłaszcza w razie jakiegoś włamu na serwer, gdzie przechowujemy klucz prywatny... Ale zająć się mieliśmy kluczami, więc do dzieła.

2. Opis konfiguracji.
Żeby zobaczyć efekty swojej pracy musisz mieć oczywiście dostęp do dwóch (lub więcej) maszyn z odpalonym OpenSSH. Załóżmy, że maszyna A to nasz super hiper P233 MMX w domu ;) a maszyna B to np. serwer na uczelni lub w pracy, albo chociażby u kolegi. Logujemy się na A, i wydajemy komendę:

opcja -t dsa to wybór metody szyfrowania klucza (UWAGA! DSA działa tylko z ssh w wersji 2); można także wybrać RSA (RSA w wersji 2) oraz RSA1, niemniej jednak SSH2 został uznany za bezpieczniejszy i każdy serwer powinien go przyjąć, zatem zostaniemy przy DSA i SSH2.

Wynikiem będzie:

oraz chwilowa "zaduma" systemu - w zależności od wydajności maszyny należy poczekać od 1 do 5 minut (no chyba, że to jakiś ultra zabytek ;) ).

Następnie wpisujemy ścieżkę do zapisania klucza prywatnego (proponuję zostawić bez zmian - czyli klepiemy ENTER).

Możemy wpisać PASSPHRASE (nie wpisujemy swojego hasła! W końcu chodzi nam o dodatkowe zabezpieczenie, a nie o wydłużenie procesu logowania!). Można ją także pominąć (ENTER), wtedy logowanie do wybranych serwerów przebiegnie bez pytania o cokolwiek. Dla zwiększenia efektu tego artykułu zostaw pustą PASSPHRASE ;) [btw. to się jakoś po ludzku tłumaczy na polski? - ja bym napisał "przepustka" (Bruno)].

Tutaj znowu ENTER, albo powtórka poprzedniego wpisu....

Po tym wszystkim otrzymamy kilka informacji o tym, co i gdzie się nam zapisało - oraz naszą upragnioną parę kluczy ;)

Jesteśmy w połowie drogi :)

Przechodzimy do katalogu ./ssh w naszym $HOME i cóż widzimy?

klucz prywatny klucz publiczny
Klucz prywatny to nasze największe sacrum w tym przypadku i chronimy go jak tylko się da, czyli chmod 600 będzie dobrym rozwiązaniem. Nie zaszkodzi też, aby klucz publiczny miał prawa 600. Następnie robimy z id_dsa.pub plik authorized_keys, ponieważ w tym pliku na drugim hoście będą przechowywane nasze klucze (może być ich więcej - z różnych maszyn), zatem aby czegoś nie spartolić, dopisujemy do authorized_keys zawartość id_dsa.pub

Tak spreparowany pliczek wrzucamy do identycznego katalogu na drugim hoście, względnie wysyłamy adminowi i prosimy o umieszczenie go tam. W zależności od naszego stopnia paranoii (lub przezorności - nazywaj jak chcesz) możemy go wysłać normalnie mailem lub FTP, ale oczywiście lepiej zastosować jakiś szyfrowany przekaż np. sftp lub mailem przez SSL. Pamiętaj, że struktura pliku authorized_keys powinna być jednolita, tzn. wpis klucza musi być w jednej baaaaardzo długiej linijce - inaczej klucz nie zadziała. Tak więc wysłanie jako plain text, a potem COPY-PASTE nie jest zbyt dobrym rozwiązaniem.

Jeśli mamy już na maszynie B w $HOME/.ssh/ nasz plik authorized_keys, możemy wreszcie przejść do testu. Z maszyny A łączymy się na maszynę B i dodatkowo używamy opcji -v w razie Niemca, jakby coś nam nie zadziałało.

Chwila czekania... i jeśli wszystko jest OK, to po chwili powinniśmy znaleźć się na naszym hoście B bez pytania o hasło. Pamiętać należy, że w przypadku tego typu połączenia w ogóle nie są brane pod uwagę login oraz hasło. Dlatego jeśli hasło do poczty masz takie jak login, to warto używać logowania do powłoki za pomocą klucza publicznego/prywatnego.

3. Zakończenie.
Na zakończenie dodam tylko, że PASSPHRASE powinna być równie unikatowa i trudna, jak mozolnie wymyślane hasło do ssh ;) Nie jest to hasło do powłoki, ale traktuj je jako hasło. To, że klucz prywatny powinien być trzymany tylko na bezpiecznej (subiektywnie) maszynie - nie wymaga, mam nadzieję, wyjaśnienia. Miłej zabawy z kluczami. W razie pytań - mail.

Oczywiście nie biorę odpowiedzialności, jeśli coś ktoś sobie tymi kluczami zrobi niepożądanego :) Ciężkie jak klucz francuski nie są, ale mogą czasem przyprawić o ból głowy ;).

Wszystko czynności opisane w artyklu popełnione zostały na NetBSD 1.6.1 (host A) i NetBSD 1.6 (host B), ale z innymi BSD nie powinno być żadnego problemu (chyba :> )

cancer[na]bsdguru.org

quex, sob., 01/03/2008 - 00:53