PEŁNA FORMA SSH: BEZPIECZNA POWŁOKA

SSH: Bezpieczna powłoka

SSH oznacza Secure Shell. Jest również znany jako Secure Socket Shell. Kryptograficzny protokół sieciowy o nazwie Secure Shell (SSH) służy do bezpiecznego świadczenia usług sieciowych w niezabezpieczonych sieciach. Architektura serwera klienta jest podstawą aplikacji SSH, które łączą instancję klienta SSH z serwerem SSH.

Jako następca protokołu Telnet i niebezpiecznych zdalnych protokołów powłoki Uniksa, takich jak Berkeley Remote Shell (rsh) i powiązanych z nim protokołów rlogin i rexec, protokół SSH został stworzony dla systemów operacyjnych typu Unix, które wykorzystują niezabezpieczoną komunikację za pomocą tokenów uwierzytelniających w postaci zwykłego tekstu.

Definicja

Możemy zastosować SSH na kilka różnych sposobów. Najprostsza implementacja szyfruje dane za pomocą automatycznie generowanych par kluczy publiczno-prywatnych na obu końcach kanału komunikacyjnego i połączenia sieciowego. Następnie uwierzytelnia użytkownika za pomocą hasła. Kiedy użytkownik ręcznie generuje parę kluczy publiczny-prywatny, uwierzytelnianie jest praktycznie zakończone po ustanowieniu pary kluczy, co pozwala na natychmiastowe uruchomienie sesji bez pytania o hasło.

obejmują programowanie w języku C

W takim przypadku właściciel zachowuje w tajemnicy odpowiedni klucz prywatny, a klucz publiczny jest instalowany na wszystkich komputerach, które muszą zapewniać właścicielowi dostęp. Chociaż klucz prywatny służy jako podstawa uwierzytelnienia, podczas uwierzytelniania klucz nigdy nie jest wysyłany przez sieć. SSH potwierdza, że dostawca klucza publicznego posiada również odpowiadający mu klucz prywatny.

Połączenie nieznanego klucza publicznego ze znanym kluczem prywatnym we wszystkich wersjach SSH jest kluczowe przed zaakceptowaniem ich jako legalnych kluczy publicznych z identyfikatorami. Zaakceptowanie klucza publicznego od atakującego bez jego sprawdzenia spowoduje zaakceptowanie niezaufanego atakującego jako uprawnionego użytkownika.

kreacja

Tatu Ylönen, informatyk z Finlandii, stworzył SSH po raz pierwszy w 1995 roku. Dalszy rozwój zestawu protokołów miał miejsce w wielu grupach programistów, co doprowadziło do różnych iteracji wdrożeniowych. Dostępne są implementacje dla wszystkich popularnych systemów operacyjnych, w tym systemów wbudowanych. OpenSSH, który twórcy OpenBSD udostępnili jako oprogramowanie open source w 1999 roku, jest najczęściej używanym stosem oprogramowania.

Zarządzanie kluczami OpenSSH do uwierzytelniania

Zatwierdzona lista kluczy publicznych jest zwykle przechowywana w systemach uniksowych w pliku ~/.ssh/authorized klucze w katalogu domowym użytkownika, który ma uprawnienia do zdalnego logowania. SSH szanuje ten plik tylko wtedy, gdy nie może go zmodyfikować nikt inny niż właściciel i root. Hasło nie jest już potrzebne, jeśli obecny jest zarówno klucz publiczny strony zdalnej, jak i klucz prywatny odpowiadający stronie lokalnej. Możemy jednak użyć hasła, aby zablokować klucz prywatny, aby zapewnić znacznie większą ochronę. Możemy także przeszukiwać tajny kod w popularnych lokalizacjach i możemy użyć opcji wiersza poleceń, aby podać jego pełną ścieżkę (opcja -i dla ssh).

SSH zapewnia ponadto automatyczne uwierzytelnianie oparte na generowaniu kluczy i szyfrowanych hasłach. Osoba atakująca w tym scenariuszu może podszyć się pod zaufany serwer, zażądać hasła i je zdobyć (atak typu man-in-the-middle). Po stronie serwera możemy wyłączyć uwierzytelnianie hasłem.

Używać

SSH wykorzystuje paradygmat klient-serwer. Zazwyczaj do logowania używany jest protokół SSH. Może także tunelować porty TCP, przekazywać połączenia X11 i wykonywać polecenia w systemie zdalnym. Zazwyczaj połączenia z demonem SSH umożliwiającym połączenia zdalne są nawiązywane za pomocą aplikacji klienckiej SSH. Obydwa są często spotykane w większości współczesnych systemów operacyjnych, takich jak macOS, dystrybucje Linuksa, OpenBSD, FreeBSD, NetBSD, Solaris i OpenVMS. Niektóre wersje są zastrzeżone, bezpłatne i open source o różnym stopniu złożoności i kompleksowości (takie jak PuTTY i wersja OpenSSH dołączona do Cygwin i OpenSSH). Warto zauważyć, że protokół SSH nie jest domyślnie dołączony do wersji systemu Windows aż do wersji systemu Windows 10 1709.

Podobną funkcjonalność zarządzania plikami (synchronizacja, kopiowanie i zdalne usuwanie) oferuje bezpłatna aplikacja Windows WinSCP o otwartym kodzie źródłowym, która wykorzystuje PuTTY jako zaplecze. Bez konieczności instalacji na komputerze klienckim, WinSCP i PuTTY są dostępne w wersji spakowanej do działania bezpośrednio z dysku USB. Włączenie funkcji w aplikacji ustawień jest często wymagane do skonfigurowania serwera SSH w systemie Windows.

Aby poradzić sobie z problemami związanymi z połączeniem i zapobiec zagrożeniom bezpieczeństwa wynikającym z bezpośredniego udostępnienia maszyny wirtualnej opartej na chmurze w Internecie, protokół SSH ma kluczowe znaczenie w przetwarzaniu w chmurze. Bezpieczne połączenie przez Internet można uzyskać poprzez wirtualny komputer tunelowy SSH i zaporę sieciową. Dla tego protokołu IANA wyznaczyła port TCP 22, port UDP 22 i port SCTP 22.

Już w 2001 roku IANA sklasyfikowała domyślny port TCP 22 dla serwerów SSH jako jeden z dobrze znanych portów. Do uruchamiania protokołu SSH zamiast protokołu TCP można używać zorientowanego połączeniowo protokołu warstwy transportowej SCTP.

Postęp historyczny

Iteracja 1

Atak polegający na wąchaniu haseł w sieci jego instytucji zainspirował Tatu Ylönena, badacza z Politechniki Helsińskiej w Finlandii, który w 1995 roku stworzył pierwszą wersję protokołu (dziś znanego jako SSH-1).

SSH został zaprojektowany tak, aby pełnił rolę wcześniejszych protokołów, w tym rlogin, TELNET, FTP i rsh, którym brakowało solidnych gwarancji uwierzytelnienia i poufności. Ylönen udostępnił swoją aplikację jako darmowe oprogramowanie. W lipcu 1995 roku urządzenie szybko zyskało dużą popularność. Pod koniec 1995 roku było 20 000 użytkowników SSH w 50 różnych krajach.

Aby promować i rozwijać SSH, Ylönen założył SSH Communications Security w grudniu 1995. W pierwszym wydaniu programu SSH wykorzystano różne komponenty wolnego oprogramowania, w tym GNU libgmp, ale późniejsze wersje dostarczone przez SSH Communications Security stały się oprogramowaniem coraz bardziej zastrzeżonym. Według szacunków w roku 2000 było 2 miliony użytkowników.

Iteracja 2

Internet Engineering Task Force (IETF) wyznaczyła w swojej oficjalnej dokumentacji grupę roboczą odpowiedzialną za utworzenie wersji 2 protokołu SSH jako „Secsh”.

różnica symetryczna

SSH-2, ulepszona iteracja protokołu, stał się standardem w 2006 roku. SSH-1 nie jest kompatybilny z tą wersją. SSH-2 oferuje ulepszenia funkcjonalności i bezpieczeństwa w porównaniu z SSH-1. Na przykład wymiana kluczy Diffiego-Hellmana i solidna weryfikacja integralności za pomocą kodów uwierzytelniających wiadomości zapewniają większe bezpieczeństwo. Możliwość obsługi nieograniczonej liczby sesji powłoki na pojedynczym połączeniu SSH to jedna z nowych możliwości SSH-2. Ponieważ SSH-2 jest bardziej zaawansowany i powszechnie stosowany niż SSH-1, niektóre implementacje, takie jak libssh (v0.8.0+), Lsh i Dropbear, obsługują tylko SSH-2.

Iteracja 1.99

RFC 4253 wymagało, aby serwer SSH obsługujący wersję 2.0, a także wersje wcześniejsze, wskazywał wersję protokołu jako 1.99 w styczniu 2006 r., długo po opracowaniu wersji 2.1. Ten numer wersji służy do wskazania kompatybilności wstecznej, a nie do reprezentowania poprzedniej wersji oprogramowania.

OSSH i OpenSSH

Odkąd ostatnia wersja oryginalnego programu SSH, wersja 1.2.12, była rozpowszechniana na licencji open source w 1999 r., programiści pracowali nad bezpłatną wersją oprogramowania. Posłużyło to jako podstawa programu OSSH Björna Grönvalla. Niedługo potem zespół OpenBSD sklonował pracę Grönvalla, aby stworzyć OpenSSH, który został zawarty w OpenBSD Release 2.6. Na podstawie tej wersji utworzyli gałąź „przenośności”, aby przenieść OpenSSH do różnych systemów operacyjnych.

Najpowszechniej stosowaną implementacją SSH od 2005 roku był OpenSSH, wersja domyślna w wielu dystrybucjach systemów operacyjnych. Po usunięciu obsługi SSH-1 z bazy kodu w wersji OpenSSH 7.6, OpenSSH jest nadal aktualizowany i obsługuje protokół SSH-2. Tymczasem OSSH nie jest już aktualny.

Używa

Użytkownik „josh” „SSHed” z lokalnego komputera „foo Fighter” na odległą maszynę „tengwar” w celu uruchomienia xeyes jako przykład tunelowania programu X11 przez SSH. Ludzie korzystają z klienta Windows SSH PuTTY, aby uzyskać dostęp do OpenWrt.

SSH to protokół współpracujący z wieloma systemami, w tym z systemem Microsoft Windows i większością odmian Uniksa (Linux, BSD, w tym macOS firmy Apple i Solaris). Następujące aplikacje mogą wymagać funkcji dostępnych wyłącznie dla określonych klientów lub serwerów SSH lub z nimi zgodnych. Na przykład obecnie możliwe jest wykorzystanie protokołu SSH na serwerze OpenSSH i kliencie do zbudowania sieci VPN.

Aby uzyskać dostęp do powłoki na odległym hoście (zastępując Telnet i rlogin)
Do wykonania pojedynczego polecenia na odległym hoście (zastępując rsh)
Do konfigurowania automatycznego logowania (bez hasła) do odległego serwera (na przykład przy użyciu OpenSSH)
Jako w pełni funkcjonalna szyfrowana sieć VPN należy pamiętać, że tylko klient i serwer OpenSSH obsługują tę funkcję.
Do transmisji X z odległego hosta (możliwe przez wiele hostów pośrednich)
Do korzystania z klientów SSH obsługujących protokół SOCKS w celu przeglądania Internetu za pośrednictwem szyfrowanego połączenia proxy.
Do bezpiecznego montowania katalogu zdalnego serwera jako systemu plików na komputerze lokalnym korzystającym z protokołu SSHFS.
Za pomocą jednej lub więcej technologii wymienionych powyżej do automatycznego zdalnego monitorowania i administrowania serwerem.
Do tworzenia urządzeń mobilnych lub wbudowanych zgodnych z SSH.
Aby chronić mechanizmy przesyłania plików.

Metody przesyłania plików

Kilka systemów przesyłania plików wykorzystuje protokoły Secure Shell, takie jak

W przypadku SSH protokół Secure Copy (SCP) jest opracowywany na podstawie protokołu RCP.
rsync, który ma być bardziej skuteczny niż SCP, często jest obsługiwany przez połączenie SSH.
Bezpieczną alternatywą dla FTP jest protokół przesyłania plików SSH (SFTP) (nie mylić z FTP przez SSH lub FTPS)
FISH, czyli pliki przesyłane za pośrednictwem protokołu powłoki, został wprowadzony w 1998 roku i opracowany na podstawie instrukcji powłoki SSH za pośrednictwem systemu Unix.
Aspera, znana również jako szybki i bezpieczny protokół (FASP), wykorzystuje SSH do przesyłania poleceń i przesyłania danych na portach UDP.

Architektura

Trzy odrębne komponenty tworzą warstwową architekturę protokołu SSH:

Protokół kontroli transmisji (TCP) protokołu TCP/IP jest powszechnie używany w warstwie transportowej (RFC 4253), przy czym port nr 22 jest zarezerwowany jako port nasłuchiwania serwera. Warstwa ta implementuje szyfrowanie, kompresję, sprawdzanie integralności, początkową wymianę kluczy i uwierzytelnianie serwera. Chociaż każda implementacja może pozwolić na więcej, udostępnia wyższej warstwie interfejs do przesyłania i odbierania pakietów zwykłego tekstu o wielkości do 32 768 bajtów każdy. Zwykle po przesłaniu 1 GB danych lub po upływie godziny, w zależności od tego, co nastąpi wcześniej, warstwa transportowa organizuje ponowną wymianę kluczy.
Uwierzytelnianie klienta odbywa się poprzez warstwę uwierzytelniania użytkownika (RFC 4252), która oferuje również kilka technik uwierzytelniania. Uwierzytelnianie oparte na kliencie oznacza, że klient SSH, a nie serwer, może poprosić użytkownika o hasło. Tylko żądania klienta dotyczące uwierzytelnienia otrzymują odpowiedź z serwera. Często stosowane są następujące techniki uwierzytelniania użytkownika:
Zwykle obsługuje co najmniej pary kluczy DSA, ECDSA lub RSA klucz publiczny to technika uwierzytelniania w oparciu o klucz publiczny. Inne implementacje dodatkowo akceptują certyfikaty X.509.
Funkcjonalność pojedynczego logowania do sesji SSH jest dostępna za pośrednictwem GSAPI techniki uwierzytelniania, które oferują rozszerzalny system do obsługi uwierzytelniania SSH przy użyciu mechanizmów zewnętrznych, takich jak Kerberos 5 lub NTLM. Chociaż OpenSSH ma funkcjonalną implementację GSSAPI, komercyjne implementacje SSH często integrują te techniki do użytku w firmach.
Ideę kanałów definiujących oferowane usługi SSH definiuje warstwa połączenia (RFC 4254). Możemy multipleksować wiele połączeń SSH z jednego. Obydwa przesyłają dane w obu kierunkach. Żądania kanałów przesyłają pozapasmowe dane specyficzne dla danego kanału, takie jak kod zakończenia procesu po stronie serwera lub zmiana rozmiaru okna terminala. Dodatkowo, wykorzystując rozmiar okna odbioru, każdy kanał kontroluje swój przepływ. Klient SSH wysyła globalne żądanie przekazania portu po stronie serwera. Typowe typy kanałów obejmują:
- Powłoka dla powłok SFTP, exec i terminali (w tym transfery SCP)
- Direct-TCPIP dla połączeń przekazywanych od klienta do serwera.
- Połączenia przekazywane między serwerem a klientem przy użyciu forwarded-tcpip
- Aby potwierdzić legalność hosta, rekord DNS SSHFP (RFC 4255) zawiera odciski palców publicznego klucza hosta.

Dzięki otwartej konstrukcji SSH możemy wykorzystywać do szerokiego zakresu zadań oprócz zabezpieczania powłok, co zapewnia mu dużą wszechstronność.

przycinanie ciągu Java

Luki

SSH-1

Ze względu na niewystarczającą ochronę integralności danych zapewnianą przez CRC-32 w tej wersji protokołu, w 1998 r. zidentyfikowano lukę w SSH 1.5, która umożliwiła nieautoryzowane wstawienie materiału do zaszyfrowanego strumienia SSH. W większości wdrożeń dodano łatkę znaną jako Detektor ataków kompensacyjnych SSH. Kilka z tych poprawionych implementacji zawierało nową lukę polegającą na przepełnieniu liczb całkowitych, umożliwiającą atakującym uruchomienie dowolnego kodu z uprawnieniami roota lub demona SSH.

W styczniu 2001 roku wykryto lukę umożliwiającą atakującym zmianę ostatniego bloku sesji zaszyfrowanej IDEA. W tym samym miesiącu wykryto kolejną lukę, która umożliwiała fałszywemu serwerowi przekazanie danych logowania klienta do innego serwera.

Ze względu na nieodłączne luki w zabezpieczeniach protokół SSH-1 jest ogólnie uważany za nieaktualny i należy go unikać poprzez wyraźne usunięcie rozwiązania zastępczego SSH-1. Większość obecnych serwerów i klientów obsługuje SSH-2.

Odzyskiwanie zwykłego tekstu dla CBC

Teoretyczna luka w zabezpieczeniach, która umożliwiała odzyskanie do 32 bitów tekstu jawnego z bloku tekstu zaszyfrowanego zaszyfrowanego przy użyciu standardowej metody szyfrowania CBC, została odkryta we wszystkich wersjach protokołu SSH w listopadzie 2008 r. Najprostszym rozwiązaniem jest przejście na CTR, licznik zamiast trybu CBC, który czyni SSH odpornym na atak.

NSA podejrzana o odszyfrowanie

Udostępnienie przez Edwarda Snowdena wrażliwych dokumentów dziennikowi Der Spiegel 28 grudnia 2014 r. oznacza, że Agencja Bezpieczeństwa Narodowego będzie w stanie potencjalnie odszyfrować niektóre komunikaty SSH.

TechCodeview

Jaka jest pełna forma protokołu SSH