Czym SSH różni się od Telnetu?

Zarówno SSH, jak i TELNET umożliwiają łączenie się ze zdalnymi komputerami w sieci i korzystanie z nich tak, jakbyś siedział przed nimi. Jaka jest więc różnica między tymi dwoma czcigodnymi protokołami i czy naprawdę zawsze istnieje korzyść z używania SSH przez TELNET?

TELNET i SSH: historia pochodzenia

Potrzeba jest matka wynalazku. Administratorzy systemu potrzebowali sposobu na dostęp do komputerów, które fizycznie znajdowały się gdzie indziej, i zarządzanie nimi. Jeśli zajmowanie stanowiska przed komputerem było dla administratora niepraktyczne lub niewygodne, potrzebny był sposób uzyskania dostępu do komputera zdalnego, który umożliwiłby mu wydawanie poleceń tak, jakby wpisywał je na tym komputerze.

TELNET, skrót od tel etype over net work protocol, został opracowany w 1969 roku jako odpowiedź na ten problem. Dopóki zdalny komputer był dostępny w sieci, pozwalał administratorowi lub innej upoważnionej osobie łączyć się z nim i używać go tak, jakby fizycznie naciskał klawisze zdalnej klawiatury.

SSH powstał znacznie później – w 1995 roku – jako bezpośrednia odpowiedź na Telnet i inne podobne rozwiązania. Tym razem koniecznością było bezpieczeństwo. TELNET, rlogin, FTP i inne protokoły tamtej epoki zostały zaprojektowane bez uwzględnienia bezpieczeństwa lub jego potrzeby.

SSH oznacza bezpieczną powłokę , więc widać, że bezpieczeństwo było naczelną zasadą od samego początku. Obecnie SSH prawie całkowicie zastąpił TELNET.

TELNET to koszmar bezpieczeństwa w postaci zwykłego tekstu

Duży problem z TELNET polega na tym, że używa zwykłego tekstu. Nie szyfruje żadnego ruchu, w tym nazw użytkowników i haseł. Wszystko, co transmituje w sieci, może zostać przechwycone przez wąchanie pakietów i odczytane z największą łatwością. Jest to zagrożenie bezpieczeństwa nawet w sieci lokalnej, chyba że jesteś jedynym użytkownikiem. Każdy użytkownik może przechwycić ruch TELNET i uzyskać dane logowania, do których nie ma uprawnień.

Jeśli zdalny komputer znajduje się poza siedzibą firmy i wymaga nawiązania połączenia przez Internet, aby do niego dotrzeć, problem jest niepomiernie powiększony. TELNET był produktem swoich czasów i szczerze mówiąc, autorzy prawie na pewno nie spodziewali się, że ludzie będą go używać ponad pięćdziesiąt lat później, w dzisiejszym, bardzo odmiennym krajobrazie IT.

Chociaż TELNET zasługuje na swoje miejsce na liście ważnych programów, które wspólnie pomogły nam dotrzeć do miejsca, w którym jesteśmy dzisiaj, nie jest to coś, z czego powinniśmy nadal korzystać w dzisiejszym świecie.

Czym różni się SSH od TELNET?

Na pierwszy rzut oka TELNET i SSH to dwie odpowiedzi na ten sam problem. Oba umożliwiają dostęp do okna terminala na komputerze zdalnym i wydawanie mu poleceń. Ale ponieważ SSH został opracowany znacznie później niż TELNET, problem został dokładniej zrozumiany, a odpowiedź została lepiej zaprojektowana.

TELNET został zaprojektowany z myślą o sieciach prywatnych , ale SSH został zaprojektowany, aby radzić sobie z sieciami publicznymi oraz potrzebą zachowania prywatności i bezpieczeństwa podczas przesyłania danych i nawiązywania połączeń zdalnych.

TELNET używa portu 23 i nie można zmienić tego numeru portu. Domyślnie SSH używa portu 22, ale można go skonfigurować i zmienić. Skonfigurowanie SSH do używania nieoczywistego numeru portu utrudnia atakującym zidentyfikowanie portu SSH. Jeśli można zidentyfikować port SSH, przeprowadzenie ataku typu brute-force, w którym tysiące haseł zebranych w wyniku naruszeń danych jest kolejno wypróbowywanych przez zautomatyzowane oprogramowanie, jest trywialną sprawą.

Co więcej, SSH może całkowicie zrezygnować z haseł. Może używać szyfrowania klucza publicznego do uwierzytelniania na komputerach zdalnych. Hasła w ogóle nie są przesyłane, ponieważ nie ma potrzeby wysyłania ich do komputera zdalnego. Szyfrowanie danych i uwierzytelnianie za pomocą klucza SSH oznaczają, że SSH jest w stanie zapewnić bezpieczne połączenia i komunikację w niezabezpieczonych sieciach, takich jak Internet.

W rzeczywistości SSH może być używany do uwierzytelniania za pomocą różnych usług, nie tylko zdalnych komputerów z uruchomionym serwerem SSH. Na przykład możesz uzyskać dostęp do hostowanych repozytoriów Git GitHub, GitLab i BitBucket za pomocą SSH zamiast haseł.

POWIĄZANE Czy powinieneś używać HTTPS lub SSH dla Git?

Kolejną zaletą korzystania z SSH przez TELNET jest to, że SSH może wykonywać odwrotne tunelowanie SSH. Wymaga to nawiązania przez serwer połączenia z komputerem klienckim. Dopóki lokalny użytkownik nie chce nawiązać połączenia z serwerem, połączenie jest ignorowane.

Gdy klient chce połączyć się z serwerem, użytkownik nawiązuje połączenie SSH z własnym komputerem. SSH wysyła połączenie w dół już nawiązanego połączenia do serwera. Zapewnia to prywatny tunel wewnątrz już zaszyfrowanego połączenia z serwera do klienta.

Jedyną zaletą TELNET jest to, że zużywa mniej pasma. Ale to nie jest rok 1969, kiedy przepustowość była ograniczona, a SSH też nie ogranicza przepustowości.

SSH też miał swoje problemy

Chociaż SSH przewyższa TELNET jeśli chodzi o bezpieczeństwo, musimy pamiętać, że to wciąż oprogramowanie, a oprogramowanie może mieć błędy. Błędy te mogą prowadzić do powstania luk, które mogą zostać wykorzystane przez cyberprzestępców. Ponadto standardy i algorytmy szyfrowania zmieniają się w czasie i są zastępowane. Podobnie jak wszystkie programy oparte na szyfrowaniu, starsze wersje SSH mogą stać się mniej bezpieczne. Dlatego ważne jest, aby upewnić się, że używasz najnowszej wersji SSH.

Wersja SSH używana na większości komputerów z systemem Linux to OpenSSH, implementacja SSH, która opiera się na zestawie narzędzi i bibliotekach OpenSSL. W 2012 roku biblioteka OpenSSL przypadkowo wprowadziła błąd, który umożliwiał atakującemu zażądanie odpowiedzi od serwera SSL i określenie, ile danych ma zawierać odpowiedź.

Mogliby zażądać odpowiedzi (powiedzmy) 64 KB, podczas gdy rzeczywista odpowiedź wymagałaby nie więcej niż 64 bajtów. Pierwsza sekwencja bajtów w tych danych byłaby autentyczną, oczekiwaną odpowiedzią, po której następuje wszystko, co zdarzyło się w pamięci ostatnio używanej przez OpenSSL. To, co było zawarte w tych danych, było przypadkowe, ale mogło zawierać poufne informacje, takie jak sesyjne pliki cookie i hasła, lub inne informacje, które pozwoliły atakującemu na przykład zdobyć klucze prywatne.

Po wykryciu luki w 2014 roku nazwano ją Heartbleed. Zostało to szybko naprawione w oprogramowaniu. Jednak luka nie znika w tym momencie. Luka zostaje całkowicie usunięta dopiero wtedy, gdy na wszystkich komputerach z oprogramowaniem zawierającym lukę jest zainstalowana poprawiona wersja. Innymi słowy, kiedy komputery zostały załatane . Ponieważ wielu administratorów reagowało wolno, wdrażanie poprawionego oprogramowania było powolne.

Niepokojące są również dwa lata między 2012 r., kiedy błąd został wprowadzony, a 2014 r., kiedy został wykryty i rozwiązany. Przez te dwa lata każdy serwer SSH z podatną na ataki wersją OpenSSL był zagrożony.

Szczerze mówiąc, stało się to praktycznie dekadę temu i od tego czasu pojawiło się wiele wydań, ulepszeń, poprawek błędów i recenzji kodu.

POWIĄZANE: Najlepsze sposoby zabezpieczenia serwera SSH

Czy powinieneś używać SSH lub TELNET?

Trudno wymyślić powód, dla którego miałbyś dzisiaj korzystać z TELNET. To nie to samo, co stwierdzenie, czy istnieje jakikolwiek scenariusz, w którym można bezpiecznie używać TELNET. W niezależnej sieci, która nie jest połączona ze światem zewnętrznym i masz pewność, że nikt nie będzie wąchał twojego ruchu, możesz użyć TELNET. Ale nie ma powodu. Kompromisu w zakresie bezpieczeństwa nie da się usprawiedliwić.

SSH jest bezpieczniejszy i bardziej elastyczny — to zaleta korzystania z SSH przez TELNET. Implementacja OpenSSH jest bezpłatna do wszystkich zastosowań, w tym komercyjnych, i jest dostępna dla wszystkich popularnych systemów operacyjnych.

POWIĄZANE: Jak połączyć się z serwerem SSH z systemu Windows, macOS lub Linux