o sshd słów kilka
W poprzednim artykule o ssh pisałem o opcji logowania się za pomocą kluczy. Ponieważ z różnych ważnych powodów musiał zostać podniesiony poziom zabezpieczeń (ot choćby żeby pokazać, jak to sie człowiek stara 
), zaimplementowałem w końcu ten przemiły sposób logowania. Polega on w skrócie na tym, iż potrzebna jest para kluczy - klucz publiczny, umieszczany na serwerze, oraz klucz prywatny, znajdujące się w posiadaniu użytkownika. Literatura mówi, iż klucz prywatny jest nieodtwarzalny z klucza publicznego, ale klucz publiczny z prywatnego już tak. Ponadto rzeczy zakodowane kluczem publicznym odczytywane są tylko za pomoca komplementarnego klucza prywatnego i vice versa, rzeczy zakodowane przy pomocy klucza prywatnego odczytywane są tylko przy pomocy klucza publicznego. To pierwsze przydaje się do szyfrowania, to drugie do autentykacji. Tyle teorii, przejdźmy do rzeczy.
Przede wszystkim musiałem ustawić ssh - /etc/sshd_config przeszło następujące zmiany:
- PasswordAuthentication no - w połaczeniu z ChallengeResponseAuthentication no pozwoliło na zablokowanie logowania za pomocą haseł. Samo wyłączenie autetykacji za pomocą haseł nie chce działać. Literatura sieciowa sugeruje jeszcze wyłączenie PAM, ale mimo wszystko nie wydaje mi sie to konieczne, a nawet wręcz przeciwnie.
- AuthorizedKeysFile %h/.ssh/authorized_keys włączyło (domyślne) położenie pliku zawierajacego klucze publiczne,
- W moim szczególnym przypadku użyłem opcji AllowUsers i DenyUsers żeby wyspecyfikować grupy użytkowników mogące się logować oraz tych, którzy w żaden sposób niepowinni. Działają tu tylko nazwy użytkowników, nie ich id, można używać znaków * oraz ?.
Po tej przymiarce, ZANIM zrestartujemy sshd, musimy wygenerować nasz klucz (żeby w razie zerwania sesji móc się wbić ponownie na serwer. Ogólnie to ten krok warto zrobić najpierw :-)…
Generowanie zestawu kluczy jest dość banalne - albo użyjemy ssh-keygen -t rsa a on interaktywnie przeprowadzi nas przez tworzenie klucza albo skorzystamy z pakieciku putty i jego składowego programiku keygen. Którejkolwiek opcji byśmy nie używali warto wpisać hasło (passphrase) którym zabezpiecznym klucz. Zdecydowanie podnosi to bezpieczeństwo wg paradygmatu: coś co się zna (login, hasło) oraz coś co się ma (klucz). Bez klucza nikt się nie zaloguje, przechwytując klucz prywatny, bez hasła też nie (chociaż tu wracamy do ataku typu bruteforce).
Wygenerowany klucz prywatny (domyślnie id_rsa) zapisujemy w bezpiecznym miejscu zaś klucz publiczny przenosimy na serwer do pliku wyszczególnionego w zmiennej konfiguracyjnej AuthorizedKeysFile - zazwyczaj ~/.ssh/authorized_keys.
Sprawa jest już prawie zakończona - jednak jak się logować? W wypadku korzystania do połączeń z putty, można dodać klucz do pageanta, albo w konfiguracji połaczenia wskazać na plik zawierający klucz. W wypadku łaczenia się z pod linuxa, do komendy ssh oprócz standardowych parametrów, takich jak chociażby ?C (kompresja) należy dodać ?i nazwa_pliku_zawierającego_klucz prywatny. Co do używania pageanta, to warto pamiętać o tym, co piszą o nim sami autorzy odpowiadając an pytanie czemu pageant nie działa jako serwis systemowy. W trakcie działania programu klucz jest przechowywany na maszynie w pamięci niezabezpieczony - łatwo (teoretycznie) go stamtąd wyjąć i używać nie korzystając z hasła którym ten klucz zabezpieczyliśmy.
Bezpiecznego logowania!