OpenSSH - OpenSSH

Nie mylić z OpenSSL .

Bezpieczna powłoka OpenSSH lub OpenBSD
„Zachowywanie tajemnicy Twoich komunikatów”
„Zachowywanie tajemnicy Twoich komunikatów”
Deweloper(zy) OpenBSD projektu
Pierwsze wydanie 1 grudnia 1999 r .; 21 lat temu ( 1999-12-01 )
Wersja stabilna
8,8/26 września 2021 ; 15 dni temu ( 2021-09-26 )
Magazyn github .com /openssh /openssh-portable
Napisane w C
System operacyjny Wieloplatformowy
Standard (y) RFC 4250, RFC 4251, RFC 4252, RFC 4253, RFC 4254, RFC 4255, RFC 4256, RFC 4335, RFC 4344, RFC 4345, RFC 4419, RFC 4462, RFC 5656, RFC 6594, RFC 6668, RFC 7479
Rodzaj Dostęp zdalny
Licencja BSD , ISC , domena publiczna
Strona internetowa www .openssh .com

OpenSSH (znany również jako OpenBSD Secure Shell ) to zestaw bezpiecznych narzędzi sieciowych opartych na protokole Secure Shell (SSH), który zapewnia bezpieczny kanał w niezabezpieczonej sieci w architekturze klient-serwer .

OpenSSH rozpoczął jako widelec z bezpłatnym programem opracowanym przez SSH Tatu Ylönen; późniejsze wersje SSH Ylönena były zastrzeżonym oprogramowaniem oferowanym przez SSH Communications Security . OpenSSH został po raz pierwszy wydany w 1999 roku i jest obecnie rozwijany jako część systemu operacyjnego OpenBSD .

OpenSSH nie jest pojedynczym programem komputerowym, ale raczej zestawem programów, które służą jako alternatywa dla nieszyfrowanych protokołów, takich jak Telnet i FTP . OpenSSH jest zintegrowany z kilkoma systemami operacyjnymi, a mianowicie Microsoft Windows , macOS i większością systemów operacyjnych Linux , podczas gdy wersja przenośna jest dostępna jako pakiet w innych systemach.

Historia

OpenBSD Secure Shell został stworzony przez programistów OpenBSD jako alternatywa dla oryginalnego oprogramowania SSH autorstwa Tatu Ylönena, które obecnie jest oprogramowaniem własnościowym . Chociaż kod źródłowy jest dostępny dla oryginalnego SSH, na jego użycie i dystrybucję nałożone są różne ograniczenia. OpenSSH został stworzony jako rozwidlenie OSSH Björna Grönvalla, które samo było rozwidleniem oryginalnego darmowego wydania SSH 1.2.12 Tatu Ylönena, które było ostatnim posiadającym licencję odpowiednią do forkingu. Twórcy OpenSSH twierdzą, że ich stosowanie jest bardziej bezpieczne niż w oryginale, z uwagi na ich politykę produkcji czystej i zbadane kod i ponieważ jest wydany na licencji BSD , licencji open-source do których słowo otwarty w nazwie odnosi.

OpenSSH pojawił się po raz pierwszy w OpenBSD 2.6. Pierwszy przenośny uwolnienie powstał w październiku 1999. Rozwój odtąd obejmowały dodanie szyfrów (np chacha20 - poly1305 w 6,5 stycznia 2014 roku), cięcie zależność od OpenSSL (6,7, październik 2014) i przedłużenie w celu ułatwienia publiczno- wykrywanie i rotacja kluczy dla zaufanych hostów (dla przejścia z DSA na publiczne klucze hosta Ed25519 , wersja 6.8 z marca 2015 r.).

19 października 2015 r. firma Microsoft ogłosiła, że ​​OpenSSH będzie natywnie obsługiwany w systemie Microsoft Windows i dostępny za pośrednictwem programu PowerShell , udostępniając wczesną implementację i publicznie udostępniając kod. Programy klienckie i serwerowe oparte na OpenSSH zostały uwzględnione w systemie Windows 10 od wersji 1803. Klient SSH i agent klucza są domyślnie włączone i dostępne, a serwer SSH jest opcjonalną funkcją na żądanie.

W październiku 2019 r. w OpenSSH 8.1 dodano ochronę kluczy prywatnych przechowywanych w pamięci RAM przed spekulacjami i atakami typu side-channel .

Rozwój

OpenSSH zdalnie steruje serwerem przez powłokę uniksową

OpenSSH jest rozwijany jako część systemu operacyjnego OpenBSD . Zamiast w tym zmiany dla innych systemów operacyjnych bezpośrednio do OpenSSH, oddzielna przenośność infrastruktura jest utrzymywana przez OpenSSH Mobilność Team i „przenośne” wersje są okresowo. Ta infrastruktura jest istotna, częściowo dlatego, że OpenSSH jest wymagane do przeprowadzania uwierzytelniania , możliwości, która ma wiele różnych implementacji. Ten model jest również używany w innych projektach OpenBSD, takich jak OpenNTPD .

Pakiet OpenSSH zawiera następujące narzędzia i demony wiersza poleceń :

  • scp , zamiennik dla rcp .
  • sftp , zamiennik ftp do kopiowania plików między komputerami.
  • ssh , zamiennik rlogin , rsh i telnet , aby umożliwić dostęp powłoki do zdalnego komputera.
  • ssh-add i ssh-agent , narzędzia ułatwiające uwierzytelnianie poprzez trzymanie kluczy w gotowości i unikanie konieczności wprowadzania haseł za każdym razem, gdy są używane.
  • ssh-keygen , narzędzie do sprawdzania i generowaniakluczy RSA , DSA i krzywych eliptycznych , które są używane do uwierzytelniania użytkowników i hostów.
  • ssh-keyscan , który skanuje listę hostów i zbiera ich klucze publiczne.
  • sshd , demon serwera SSH.

Serwer OpenSSH może uwierzytelniać użytkowników przy użyciu standardowych metod obsługiwanych przez protokół ssh : za pomocą hasła; uwierzytelnianie za pomocą klucza publicznego przy użyciu kluczy użytkownika; uwierzytelnianie oparte na hoście, które jest bezpieczną wersją relacji zaufania hosta rlogin przy użyciu kluczy publicznych; interaktywny z klawiaturą, ogólny mechanizm wyzwania i odpowiedzi , który jest często używany do prostego uwierzytelniania hasła, ale który może również wykorzystywać silniejsze elementy uwierzytelniające, takie jak tokeny ; i Kerberos / GSSAPI . Serwer korzysta z metod uwierzytelniania natywnych dla systemu operacyjnego hosta; może to obejmować użycie systemu uwierzytelniania BSD lub modułów uwierzytelniania typu Pluggable (PAM), aby umożliwić dodatkowe uwierzytelnianie za pomocą metod takich jak hasła jednorazowe . Jednak czasami ma to skutki uboczne: gdy używasz PAM z OpenSSH, należy go uruchomić jako root , ponieważ uprawnienia roota są zazwyczaj wymagane do obsługi PAM. Wersje OpenSSH po 3.7 (16 września 2003) umożliwiają wyłączenie PAM w czasie wykonywania, dzięki czemu zwykli użytkownicy mogą uruchamiać instancje sshd.

W OpenBSD OpenSSH korzysta z dedykowanego sshd użytkownikowi domyślnie upuścić przywileje i wykonać separację uprawnień zgodnie z zasadą najmniejszych przywilejów , stosowanej w systemie operacyjnym tym Xenocara X serwera .

Cechy

OpenSSH obejmuje możliwość ustawienia zabezpieczonego kanału, przez który dane wysyłane do lokalnych gniazd domeny Unix po stronie klienta lub lokalnych portów TCP po stronie klienta mogą być „ przekazywane ” (przesyłane przez zabezpieczony kanał) w celu routingu po stronie serwera; gdy to przekazywanie jest skonfigurowane, serwer otrzymuje polecenie wysłania przekazanych danych do jakiegoś gniazda lub hosta/portu TCP (hostem może być sam serwer, „localhost”; lub hostem może być inny komputer, aby na drugim komputerze pojawia się informacja, że ​​serwer jest twórcą danych). Przekazywanie danych jest dwukierunkowe, co oznacza, że ​​każda komunikacja zwrotna jest sama przekazywana z powrotem po stronie klienta w ten sam sposób; jest to znane jako „ tunel SSH ” i może być używane do multipleksowania dodatkowych połączeń TCP przez pojedyncze połączenie SSH od 2004 r., do ukrywania połączeń, szyfrowania protokołów, które w inny sposób nie są zabezpieczone, oraz do obchodzenia zapór sieciowych poprzez wysyłanie/odbieranie w dowolny sposób danych przez jeden port dozwolony przez zaporę. Na przykład tunel X Window System może być tworzony automatycznie podczas używania OpenSSH do łączenia się ze zdalnym hostem, a inne protokoły, takie jak HTTP i VNC , mogą być łatwo przekazywane.

Tunelowanie ładunku z enkapsulacją TCP (takiego jak PPP ) przez połączenie oparte na TCP (takie jak przekierowanie portów SSH ) jest znane jako „TCP-over-TCP” i może wywołać dramatyczny spadek wydajności transmisji (problem znany jako „topienie TCP”), dlatego oprogramowanie wirtualnej sieci prywatnej może zamiast tego używać do połączenia tunelowego protokołu prostszego niż TCP. Jednak często nie stanowi to problemu podczas korzystania z przekierowania portów w OpenSSH, ponieważ wiele przypadków użycia nie pociąga za sobą tunelowania TCP przez TCP; można uniknąć stopienia, ponieważ klient OpenSSH przetwarza lokalne połączenie TCP po stronie klienta w celu uzyskania rzeczywistego wysyłanego ładunku, a następnie wysyła ten ładunek bezpośrednio przez własne połączenie TCP tunelu do strony serwera, gdzie OpenSSH serwer podobnie „rozpakowuje” ładunek, aby „zapakować” go ponownie i skierować do miejsca docelowego.

Ponadto niektóre oprogramowanie innych firm obsługuje tunelowanie przez SSH. Należą do nich DistCC , CVS , rsync i Fetchmail . W niektórych systemach operacyjnych zdalne systemy plików można montować przez SSH za pomocą narzędzi takich jak sshfs (za pomocą FUSE ).

Ad hoc SOCKS serwera proxy mogą być tworzone za pomocą OpenSSH. Pozwala to na bardziej elastyczne proxy niż jest to możliwe przy zwykłym przekierowaniu portów.

Począwszy od wersji 4.3, OpenSSH implementuje sieć VPN opartą na technologii OSI w warstwie 2/3 opartą na tun . Jest to najbardziej elastyczna z możliwości tunelowania OpenSSH, pozwalająca aplikacjom na przejrzysty dostęp do zdalnych zasobów sieciowych bez modyfikacji w celu wykorzystania SOCKS.

Obsługiwane typy kluczy publicznych

OpenSSH obsługuje następujące typy kluczy publicznych:  ·

  • ecdsa -sha2-nistp256 (od OpenSSH 5.7 wydanego w 2011)
  • ecdsa -sha2-nistp384 (od OpenSSH 5.7)
  • ecdsa -sha2-nistp521 (od OpenSSH 5.7)
  • ecdsa -sk (od OpenSSH 8.2 wydanego w 2020 r.)
  • ed25519 -sk (od OpenSSH 8.2)
  • ssh- ed25519 (od 6,5 OpenSSH wydany w 2014 roku)
  • ssh- dss (wyłączone w czasie wykonywania od wydania OpenSSH 7.0 w 2015 r.)
  • ssh- RSA (wyłączona w czasie wykonywania od OpenSSH 8.8 wydany w 2021 roku)
  • rsa -sha2-256 (od OpenSSH 7.2 wydanego w 2016)
  • rsa -sha2-512 (od OpenSSH 7.2)

Luki

Przed wersją 5.2 openssh możliwe było odzyskanie przez atakującego do 14 bitów tekstu jawnego z prawdopodobieństwem powodzenia 2-14 . Luka dotyczyła trybu szyfrowania CBC. Tryb AES CTR i szyfry arcfour nie są podatne na ten atak.

W OpenSSH 6.8 do 6.9 ( CVE - 2015-6565 ) istniała luka w zabezpieczeniach lokalnej eskalacji uprawnień, spowodowana możliwością zapisu na całym świecie (622) urządzeń TTY, które uważano za lukę typu odmowa usługi . Korzystając z ioctl TIOCSTI, uwierzytelnieni użytkownicy mogli wstrzykiwać znaki do terminali innych użytkowników i wykonywać dowolne polecenia w systemie Linux.

Złośliwe lub skompromitowane serwery OpenSSH mogą odczytywać poufne informacje na kliencie, takie jak prywatne klucze logowania do innych systemów, wykorzystując lukę, która opiera się na nieudokumentowanej funkcji wznawiania połączenia klienta OpenSSH, zwanej roamingiem, włączonej domyślnie na kliencie, ale nie jest obsługiwane na serwerze OpenSSH. Dotyczy to wersji 5.4 (wydanej 8 marca 2010 r.) do 7.1 klienta OpenSSH i zostało naprawione w OpenSSH 7.1p2 wydanym 14 stycznia 2016 r. Numery CVE związane z tą usterką to CVE - 2016-0777 (wyciek informacji) i CVE - 2016-0778 (przepełnienie bufora).

Znak towarowy

W lutym 2001 r. Tatu Ylönen, prezes i CTO SSH Communications Security poinformował listę dyskusyjną rozwoju OpenSSH, że firma zamierza potwierdzić swoją własność znaków towarowych „SSH” i „Secure Shell” i stara się zmienić odniesienia do protokołu na „ SecSH” lub „secsh”, aby zachować kontrolę nad nazwą „SSH”. Zaproponował, aby OpenSSH zmienił nazwę, aby uniknąć procesu sądowego, co jest sugestią, której deweloperzy się sprzeciwiali. Deweloper OpenSSH, Damien Miller, odpowiedział, wzywając Ylönen do ponownego rozważenia, argumentując, że „SSH” od dawna jest znakiem towarowym generycznym .

W tym czasie „SSH”, „Secure Shell” i „ssh” pojawiały się w dokumentach proponujących protokół jako otwarty standard. Nie oznaczając ich we wniosku jako zarejestrowane znaki towarowe, Ylönen zaryzykowała zrzeczenie się wszystkich wyłącznych praw do nazwy jako sposobu opisu protokołu. Niewłaściwe użycie znaku towarowego lub umożliwienie innym niewłaściwego używania znaku towarowego powoduje, że znak towarowy staje się terminem rodzajowym, takim jak Kleenex lub Aspirin , co otwiera znak do używania przez innych. Po przestudiowaniu bazy danych znaków towarowych USPTO , wielu ekspertów internetowych wyraziło opinię, że termin „ssh” nie jest znakiem towarowym, a jedynie logo z małymi literami „ssh”. Ponadto sześć lat, jakie upłynęły od powstania firmy do czasu, gdy zaczęła ona bronić swojego znaku towarowego i że tylko OpenSSH otrzymywał groźby reperkusji prawnych, przeważyło ważność znaku.

Zarówno deweloperzy OpenSSH, jak i sam Ylönen byli członkami grupy roboczej IETF opracowującej nowy standard; po kilku spotkaniach grupa ta odrzuciła prośbę Ylönen o zmianę nazwy protokołu, powołując się na obawy, że stworzy to zły precedens dla innych roszczeń dotyczących znaków towarowych przeciwko IETF. Uczestnicy argumentowali, że zarówno „Secure Shell”, jak i „SSH” są terminami ogólnymi i nie mogą być znakami towarowymi.

Zobacz też

Uwagi

Bibliografia

Zewnętrzne linki