Które zdanie opisuje protokół SSH (Secure Shell)?
A. Protokół do zdalnej pracy na odległym komputerze nie zapewniający kodowania transmisji.
B. Sesje SSH nie pozwalają określić, czy punkty końcowe są autentyczne.
C. Sesje SSH powodują wysyłanie zwykłego tekstu, niezaszyfrowanych danych.
D. Bezpieczny protokół terminalu sieciowego udostępniający usługi szyfrowania połączenia.
Pytanie z egzaminu CKE, styczeń 2014 (arkusz E.13-X-14.01).
SSH, czyli Secure Shell, jest właśnie bezpiecznym protokołem terminalu sieciowego, który pozwala zdalnie pracować na komputerze lub urządzeniu sieciowym przez szyfrowane połączenie. Najczęściej działa na porcie TCP 22 i zastępuje starsze, niebezpieczne rozwiązania typu Telnet, gdzie dane leciały po sieci jawnym tekstem. W praktyce przez SSH administrator loguje się na serwer Linux, konfiguruje router, kopiuje pliki przez SCP/SFTP albo wykonuje polecenia na zdalnej maszynie. Protokół zapewnia poufność transmisji, integralność danych oraz uwierzytelnianie, np. hasłem albo lepiej kluczem publicznym i prywatnym. To jest zgodne z dobrymi praktykami bezpieczeństwa, bo nie wysyłamy loginów, haseł i komend w formie łatwej do podsłuchania. W standardach SSH, opisanych m.in. w rodzinie RFC 4251, ważne są też klucze hosta, dzięki którym klient może sprawdzić, czy łączy się z właściwym serwerem. Moim zdaniem SSH to jedno z tych narzędzi, które każdy technik informatyk powinien znać praktycznie, nie tylko z definicji, bo w administracji systemami i sieciami używa się go ciągle.
W tym pytaniu łatwo pomylić SSH z dawnymi protokołami zdalnego terminala, szczególnie z Telnetem. Telnet faktycznie umożliwia zdalną pracę na komputerze, ale nie szyfruje transmisji, więc login, hasło i wykonywane polecenia mogą zostać przechwycone przez kogoś podsłuchującego ruch w sieci. SSH powstał między innymi po to, żeby ten problem rozwiązać. Dlatego stwierdzenie, że zdalna praca odbywa się bez kodowania transmisji, nie pasuje do SSH, tylko raczej do przestarzałych i niezalecanych rozwiązań.
Nie jest też prawdą, że sesje SSH wysyłają zwykły tekst jako niezaszyfrowane dane. Użytkownik może widzieć w terminalu normalny tekst poleceń, na przykład ls, cd albo ip address, ale w sieci te informacje są chronione mechanizmami kryptograficznymi. To częsty błąd myślowy: skoro w oknie terminala widać tekst, to ktoś zakłada, że taki sam tekst idzie po kablu. W rzeczywistości klient i serwer negocjują algorytmy szyfrowania, sprawdzania integralności oraz wymiany kluczy.
Niepoprawne jest również twierdzenie, że SSH nie pozwala ocenić autentyczności punktów końcowych. SSH używa kluczy hosta, dzięki czemu klient może wykryć, że serwer wygląda inaczej niż wcześniej, na przykład po ataku man-in-the-middle albo po reinstalacji systemu. Oczywiście użytkownik musi zachować rozsądek i nie klikać bezmyślnie akceptacji nowego odcisku klucza. Z mojego doświadczenia to jest bardzo praktyczna rzecz: komunikat o zmienionym kluczu hosta bywa irytujący, ale często chroni przed naprawdę poważnym problemem bezpieczeństwa.
Nie jest też prawdą, że sesje SSH wysyłają zwykły tekst jako niezaszyfrowane dane. Użytkownik może widzieć w terminalu normalny tekst poleceń, na przykład ls, cd albo ip address, ale w sieci te informacje są chronione mechanizmami kryptograficznymi. To częsty błąd myślowy: skoro w oknie terminala widać tekst, to ktoś zakłada, że taki sam tekst idzie po kablu. W rzeczywistości klient i serwer negocjują algorytmy szyfrowania, sprawdzania integralności oraz wymiany kluczy.
Niepoprawne jest również twierdzenie, że SSH nie pozwala ocenić autentyczności punktów końcowych. SSH używa kluczy hosta, dzięki czemu klient może wykryć, że serwer wygląda inaczej niż wcześniej, na przykład po ataku man-in-the-middle albo po reinstalacji systemu. Oczywiście użytkownik musi zachować rozsądek i nie klikać bezmyślnie akceptacji nowego odcisku klucza. Z mojego doświadczenia to jest bardzo praktyczna rzecz: komunikat o zmienionym kluczu hosta bywa irytujący, ale często chroni przed naprawdę poważnym problemem bezpieczeństwa.