Ubuntu.pl 🇺🇦️Większość użytkowników Linuksa korzysta lub kiedyś będzie korzystać z protokołu SSH, a jeśli nie to przynajmniej o nim słyszała. Ale niewiele osób zna jego historię, zdaje sobie sprawę z jego wszystkich możliwości czy też z bezpieczeństwa jakie oferuje. Ten artykuł jest pierwszym z cyklu poruszającym te i inne zagadnienia dotyczące protokołu SSH.
Historia
Od początku istnienia Internetu, a nawet jeszcze wcześniej, do pracy zdalnej wykorzystywany był Telnet. Miał on jednak jedną wadę, która wraz z popularyzacją sieci stawała się coraz większa – dane, a więc także hasła, były przesyłane pomiędzy komputerami w postaci jawnej. Częściowo problem rozwiązywały niektóre implementacje narzędzia Rsh, które przesyłały, niestety, wyłącznie hasła w postaci zaszyfrowanej.
W 1995 roku Tatu Ylönen z Uniwersytetu Technologii w Helsinkach stworzył nowy protokół pracy zdalnej, który szyfruje całą komunikację między komputerami. Jest nim SSH (z ang. Secure SHell – Bezpieczna powłoka) na licencji Open Source. Na przełomie 1995 i 1996 roku Ylönen powołał do życia SSH Communications Security, której zadaniem jest rozwijanie SSH. Licencję protokołu zamknięto. W roku 1996 wydano drugą implementację (SSH-2).
W 1999 roku Björn Grönvall na podstawie SSH w ostatniej wolnej wersji stworzył nową, otwartą implementację – OSSH. Niestety do dziś nie doczekała się wersji zgodnej z SSH-2.
Deweloperzy OpenBSD dostrzegli pracę Grönvalla i zdecydowali, idąc jego śladem, na stworzenie nowej implementacji protokołu SSH o nazwie OpenSSH. Usunięto wiele wad oryginalnego SSH, a także dodano wiele nowych funkcji. Na dzień dzisiejszy protokół OpenSSH jest najpopularniejszą implementacją SSH wykorzystywaną nie tylko na systemach uniksowych.
W większości wypadków zamiennie używa się nazw SSH oraz OpenSSH.
Zasada działania
Protokół SSH złożony jest z dwóch elementów: klienta oraz demona (serwera – usługi).
Podczas instalacji tego drugiego na serwerze generowane są dwie pary kluczy (parę tworzą klucz prywatny oraz klucz publiczny):
Domyślnie w konfiguracji demona protokół używa silniejszego algorytmu RSA – a co za tym idzie także kluczy RSA. Oczywiście nic nie stoi na przeszkodzie by to zmienić.
Przy próbie połączenia z serwerem SSH w pierwszej kolejności sprawdzane jest czy na danym porcie (domyślnie na porcie 22) pracuje demon SSH. Jeśli tak nie jest, to połączenie zostaje zerwane. Następnie weryfikowany jest klucz publiczny serwera. Przy pierwszym połączeniu z danym hostem jego klucz publiczny jest zapisywany na kliencie w pliku ~/.ssh/known_hosts. Przy kolejnych połączeniach sprawdzane jest czy oba klucze publiczne są identyczne. Jakakolwiek różnica między nimi spowoduje natychmiastowe zamknięcie sesji SSH. W takim przypadku należy skontaktować się z administratorem serwera. Weryfikacja kluczy jest zabezpieczeniem, które ochrania przed atakiem Man in the middle.
Następnym krokiem jest wygenerowanie przez komputer lokalny klucza sesji, którego zadaniem będzie szyfrowanie całego ruchu w sesji SSH. Klucz ten jest szyfrowany kluczem publicznym serwera i wysyłany do niego. Komputer zdalny odszyfrowuje go swoim kluczem prywatnym. Od tego momentu wszystkie dane są szyfrowane algorytmem synchronicznym (czyli takim, który do szyfrowania i deszyfrowania używa jednego klucza – klucza sesji).
W następnej części cyklu opiszę zastosowania protokołu OpenSSH.
Autorzy: Dorota Dawczyk i Mateusz Chynowski
Na podstawie: Protokoły SSH i OpenSSH i ataki na nie
Szykuje się bardzo fajny cykl, no i interesujący przede wszystkim:)
Raczej „man in the middle”, nie „men”. 😉 [po weryfikacji komentarz można rm]
@pyk oczywiście 🙂 dzięki za cynk
Prosimy o kolejne części 🙂
„Przy pierwszym połączeniu z danym hostem jego klucz publiczny jest zapisywany na kliencie w pliku ~/.ssh/known_hosts. Przy kolejnych połączeniach sprawdzane jest czy oba klucze publiczne są identyczne. Jakakolwiek różnica między nimi spowoduje natychmiastowe zamknięcie sesji SSH. W takim przypadku należy skontaktować się z administratorem serwera. ”
A co ma wspólnego administrator systemu z plikami w katalogu domowym użytkownika – w takim przypadku generowany jest komunikat o niezgodności odcisku ze wzorcem oraz podawana jest linia w pliku ~/.ssh/known_hosts , gdzie występuje owa nieścisłość. Możemy to zignorować- nie dojdzie do zestawienia sesji, lub wykasować ową linię- przy ponownej próbie połączenia proces weryfikacji połączenia będzie taki, jak za pierwszym razem( z pytaniem o akceptację lub odrzucenie).
@leon1313 administrator serwera z naszymi plikami w domowym komputerze nie ma NIC wspólnego, ale to zabezpieczenie po coś jest. Jak później napisałem mechanizm zabezpiecza przed atakiem Man in the Middle. Jaką masz gwarancję, że nowo autoryzowany odcisk jest odciskiem danego komputera?
@thalcave – widocznie twórcy protokołu SSH uznali, że użytkownik lepiej wie z kim się łączy niż administrator. Dlatego też plik ~/.ssh/known_hosts może być edytowany poprzez użytkownika inicjującego połączenie, a nie tylko administratora.
Można tu przytaczać szereg argumentów za i przeciw: jednak niezbity dowód w postaci właściciela pliku i praw do niego pozostaje.
@leon1313
Tu chodzi o to, że jeśli przy kolejnym połączeniu odcisk serwera jest inny niż zapisany na naszym komputerze to znaczy, że albo ktoś próbuje przechwycić naszą komunikację, albo administrator coś zmieniał w ustawieniach serwera. Po to jest potrzebny z nim kontakt żeby się tego dowiedzieć. A nie po to żeby nam wykasował problematyczną linijkę w known_hosts. Jeśli administrator nic nie zmieniał, a ktoś sobie usunie ten wpis, to w tym momencie już nie mamy bezpiecznego ssh, tylko stary, poczciwy telnet 🙂
[quote comment=”37088″]@leon1313
a ktoś sobie usunie ten wpis, to w tym momencie już nie mamy bezpiecznego ssh, tylko stary, poczciwy telnet :)[/quote]
nadal mamy SSH i jego szyfrowanie. Ale cała weryfikacją serwera wtedy siada. Połączenie w takim wypadku nadal jest szyfrowane – osoby trzecie nie podsłuchają komunikacji, ale nasze komendy, hasła będą szły do nieuprawnionej osoby.
@thalcave – mój błąd ( nie doczytałem , że chodzi o admina serwera a nie klienta !).
Jak najbardziej masz rację.
Pingback: OpenSSH – Część 2: zastosowania protokołu :: Czytelnia Ubuntu
Namieszane w tym „artykule” jak tylko można. Wybór między DSA a RSA jest w SSH2 zaimplementowanym w OpenSSH obok SSH1. Tymczasem szyfrowanie klucza sesji kluczem publicznym serwera jest właściwe dla SSH1. Ponadto klucz sesji jest szyfrowany podwójnie.
W SSH2 wykorzystywany jest algorytm Diffie-Hellmana. Dzięki niemu serwer i klient tworzą klucz sesji wspólnie.
Pingback: Instalacja i konfiguracja serwerów SSH i SFTP | Dydaktyka Władysław Czaja