Secure Shell (SSH) (dosł. bezpieczna powłoka) to mechanizm zapewniający bezpieczną komunikację w sieci w sposób z założenia względnie prosty i tani w implementacji. Funkcjonalność pierwszej wersji - SSH1 - skupiała się na zapewnieniu bezpieczeństwa zdalnego logowania, realizowanego dotąd przez TELNET (i inne mniej popularne aplikacje) bez gwarancji bezpieczeństwa. SSH oferuje jednak bardziej ogólne mechanizmy na potrzeby komunikacji klient-serwer, przydatne chociażby na potrzeby poczty elektronicznej i transferu plików. Nowsza wersja - SSH2 - w której poprawiono wiele błędów i niedociągnięć pierwowzoru, opisana jest (jako standard internetowy) w dokumentach RFC o numerach od 4250 do 4256.

Aplikacje klienckie i serwerowe SSH dostępne są w wielu systemach operacyjnych i stanowią metodę „z wyboru" dla zdalnego logowania i tunelowania protokołu X11 (X tunneling), zdobywają sobie także coraz większą popularność w zastosowaniach kryptografii (poza systemami wbudowanymi).

SSH zorganizowany jest w formę trzech następujących protokołów, funkcjonujących zazwyczaj na bazie TCP (rysunek 1 u dołu ⇓):

1. Protokół warstwy transportowej (Transport Layer Protocol) odpowiedzialny jest za uwierzytelnianie serwera, poufność danych i ich integralność, z zapewnieniem tzw. poufności przekazywanej (forward secrecy), czyli gwarancją, że ewentualne skompromitowanie aktualnie używanego klucza sesji nie będzie stanowić zagrożenia dla poufności sesji wcześniej przeprowadzonych.
2. Protokół uwierzytelniania użytkownika (User Authentication Protocol) służy do uwierzytelniania użytkownika wobec serwera.
3. Protokół połączenia ( Connection Protocol) dokonuje multipleksowania wielu logicznych kanałów komunikacyjnych w jedno połączenie SSH.

Protokół warstwy transportowej

KLUCZE GŁÓWNE

Uwierzytelnianie serwera odbywa się w warstwie transportowej w oparciu o parę kluczy "publiczny - prywatny" tegoż serwera. Serwer może posiadać wiele takich par na użytek różnych algorytmów szyfrowania symetrycznego. Ponieważ główny klucz serwera (host key) wykorzystywany jest (podczas wymiany klucza sesji) do uwierzytelniania serwera przed użytkownikiem, musi być a priori znany użytkownikowi. W dokumencie RFC 4251 opisane są dwa sposoby spełnienia tego wymagania:

1. Klient dysponuje lokalną bazą danych wiążącą nazwy serwerów z ich kluczami głównymi. Metoda ta nie wymaga udziału podmiotu trzeciego ani centralnie administrowanej infrastruktury, utrzymywanie wspomnianej bazy może być jednak uciążliwe.



Protokół uwierzytelniania użytkownika SSH. Uwierzytelnia użytkownika po stronie klienckiej wobec serwera.	Protokół połączenia SSH. Realizuje multipleksowanie wielu kanałów logicznych w pojedynczym, szyfrowanym tunelu.
Protokół warstwy transportowej SSH Zapewnia uwierzytelnianie serwera, poufność i integralność danych oraz (opcjonalnie) kompresję danych.
TCP Zapewnia niezawodną transmisję w ramach połączenia.
IP Realizuje dostarczanie datagramów na przestrzeni wielu sieci.



Rysunek 1. Stos protokołów SSH.


2. Powiązanie nazwy serwera z jego kluczem głównym może być poświadczone zaufanym certyfikatem. Zawartość wspomnianej bazy klienta redukuje się wówczas do kilku (w idealnym przypadku - do jednej) pozycji wiążących urzędy certyfikacji (CA) z ich kluczami głównymi. Wspomniany certyfikat stanowi jednak warunek sine qua non przeprowadzenia autoryzacji w ogóle - klient nie dysponujący kluczem niecertyfikowanego serwera nie będzie mógł zweryfikować jego tożsamości.

WYMIANA PAKIETÓW

Na rysunku 2. przedstawiony jest ciąg zdarzeń protokołu warstwy transportowej. Cały scenariusz rozpoczyna się od nawiązania przez klienta połączenia TCP z serwerem - dokonuje się to jednak w ramach protokołu TCP i nie jest częścią SSH. Po nawiązaniu połączenia klient i serwer wymieniają między sobą dane w formie pakietów, traktowanych jako dane w przesyłanych segmentach TCP. Każdy z tych pakietów ma format przedstawiony na rysunku 3., obejmujący następujące pola:

• Rozmiar pakietu - wyrażony w bajtach, nie obejmuje niniejszego pola ani kodu MAC.
• Długość dopełnienia - wyrażona w bajtach długość pola dopełniającego.
• Treść - użyteczna zawartość pakietu. Przed wynegocjowaniem algorytmu kompresji pole to nie jest kompresowane; po zakończeniu negocjowania algorytmu kompresji pole to jest kompresowane we wszystkich następnych pakietach.

• Losowe dopełnienie- pole to występuje tylko wówczas, gdy wynegocjowany został algorytm szyfrowania. Zawiera ono ciąg losowych bajtów, a jego zadaniem jest wyrównanie rozmiaru bloku (bez kodu MAC) do wielokrotności długości bloku (w przypadku szyfru blokowego) lub wielokrotności 8 bajtów (w przypadku szyfru strumieniowego).
• Kod uwierzytelnienia komunikatu (MAC) - po wynegocjowaniu uwierzytelniania komunikatu pole to zawiera kod MAC. Kod ten obliczany jest w odniesieniu do całej pozostałej części pakietu, łącznie z numerem sekwencyjnym. Numer sekwencyjny jest niejawnym 32-bitowym numerem pakietu, resetowanym do zera dla pierwszego pakietu i zwiększanym o 1 dla każdego następnego. Numer sekwencyjny nie jest jednak obecny w pakiecie przesyłanym w ramach połączenia TCP.

Gdy wynegocjowany został algorytm szyfrowania, cały pakiet z wyjątkiem kodu MAC zostaje zaszyfrowany (kod MAC obliczony zostaje przed szyfrowaniem).

Wymiana pakietów w ramach protokołu warstwy transportowej (rysunek 3.) rozpoczyna się od wymiany ciągów identyfikacyjnych,; ciąg taki wysyłany jest przez klienta, a następnie (w odpowiedzi) przez serwer.

Nr sekw. - numer sekwencyjny
pkt1 - rozmiar pakietu.
pd1 - długość dopełnienia.

Polish language edition published by HELION S.A. Copyright© 2012.
Copyright© 2012 Wydawnictwo HELION S.A
WWW: http:pl/helion.pl (księgarnia internetowa, katalog książek)