Što je SSH i kako funkcionira?

Secure Shell (SSH) je zajednički implementirani sigurnosni protokol s nizom različitih namjena. Njegova najpoznatija aplikacija omogućuje korisnicima da siguran pristup udaljenim računalima i poslužiteljima, ali može se koristiti i za tuneliranje, prosljeđivanje porta, siguran prijenos datoteka i još mnogo toga.

U ovom ćemo vodiču opisati što je SSH, za što se koristi, povijest protokola, njegovi tehnički detalji, kao i sigurnosni problemi koje je potrebno uzeti u obzir.

SSH čine tri odvojena protokola: transportni sloj, sloj provjere autentičnosti i sloj veze. Zajedno, oni služe autentifikaciji druge strane u vezi, pružaju povjerljivost šifriranjem i provjeravaju integritet podataka. SSH se sada najčešće provodi kao vlasnički SSH-2, ili kao iteracija otvorenog koda, OpenSSH.

Primjene SSH

SSH je svestran protokol. Njegova struktura i sigurnosne značajke omogućuju mu upotrebu na brojne načine, kao što su daljinski pristup, prosljeđivanje porta, tuneliranje i siguran prijenos datoteka.

Udaljeni pristup

Udaljeni pristup korisnicima omogućuje način prijavite se na drugo računalo ili poslužitelj sa svog vlastitog stroja. Koristi se za pristup lokalnim datotekama ciljnog stroja ili obavljanje usluga na njemu, a sve bez fizičkog boravka.

Programi poput Telneta i rlogina također imaju tu funkciju, ali im nedostaju sigurnosne značajke SSH-a. Mjere šifriranja i provjere autentičnosti uključene u SSH omogućuju korisnicima da se zaštite na drugi poslužitelj ili računalo na zaštićeni način, čak i preko potencijalno opasne posredničke mreže.

Udaljeni pristup sa SSH obično se provodi tako da zaposlenici mogu raditi na daljinu ili omogućiti IT odjelu da izvršava zadatke, a da ne moraju fizički ići do stroja. Može se koristiti za daljinsku administraciju, upravljanje mrežnom infrastrukturom, za postavljanje automatizacije, stvaranje sigurnosnih kopija i još mnogo toga.

Prosljeđivanje luka

Prosljeđivanje porta koristi se za prijenos zahtjeva s jedne adrese i broja porta na drugi skup. Primjenjuje prijevod mrežne adrese (NAT) na preusmjeravanje portova između lokalne mreže i udaljenog računala, omogućujući vam pristup uređaju izvan mreže.

Prosljeđivanje porta može se provesti na tri različita načina:

• lokalne prosljeđivanje luka – Preusmjeravanje lokalnih porta omogućava vam povezivanje lokalnog klijenta i vanjske mreže. To može biti učinkovito za postupke poput pristupa web lokacijama koje su lokalno blokirane ili za povezivanje s bazom podataka koja se nalazi iza vatrozida.
• Daljinsko prosljeđivanje priključaka – Ova vrsta prosljeđivanja omogućuje aplikacijama na strani poslužitelja pristup uslugama na strani klijenta. Daljinsko prosljeđivanje portala SSH omogućava korisnicima da se sigurno povezuju s udaljenim poslužiteljima putem lokalnog računala preusmjeravanjem lokalnog ulaza na udaljeni SSH poslužitelj.
• Dinamičan prosljeđivanje luka – Na ovaj način omogućuje korisnicima slanje svojih podataka kroz određeni port na udaljeno računalo ili poslužitelj pomoću nekoliko SSH poslužitelja koji djeluju kao posrednici.

tuneliranje

Protokoli tuneliranja koriste enkapsulaciju za premještanje podataka između mreža. Tuneli se mogu rasporediti kako bi se omogućilo da se netični protokoli kreću kroz mreže koje ih obično ne podržavaju. Još jedna uobičajena upotreba je za pružanje sigurnosti preko nesigurne mreže.

Protokoli tuneliranja kritične pakete omotavaju unutar korisnog opterećenja drugog paketa. SSH tuneliranje omogućava korisnicima da zaobiđu mrežnu sigurnost, povežu uređaje koji koriste protokol ne-matične mreže i osiguraju podatke koji se prenose. Često se koriste za siguran način povezivanja udaljenih korisnika s mrežnim resursima njihove organizacije.

SFTP

SSH protokol za prijenos datoteka (FTP), ponekad poznat i kao protokol sigurnog prijenosa datoteka, pruža siguran način pristupa, prijenosa i upravljanja datotekama. To je sigurna alternativa FTP-u i koristi SSH protokol kako bi sigurno slao, primao i upravljao datotekama.

SCP

Protokol sigurne kopije (SCP) sličan je SFTP-u, ali je ograničen u svom području. Omogućuje samo siguran prijenos datoteka, a ne čitav niz značajki koje omogućuju SFTP-u da djeluje kao protokol udaljenog datotečnog sustava.

platforme & aplikacije koje koriste SSH

Vlasnički SSH ili OpenSSH mogu se koristiti na svim glavnim operativnim sustavima. Dostupan je na Unix platformama poput OpenBSD, macOS, Linux i Solaris, dok Windows korisnici mogu koristiti SSH putem PowerShell-a.

Povijest SSH

SSH razvio je na Tehničkom sveučilištu u Helsinkiju 1995. godine Tatu Ylönen kao odgovor na napad njuškanja lozinke na sveučilišnu mrežu. Cilj mu je bio alternativa protokolima poput FTP, TELNET, rsh i rlogin, koji nisu osigurali povjerljivost ili provjerili autentičnost korisnika na siguran način.

SSH je pušten u javnost 1995. godine i bio je dobro prihvaćen. Usred brzog usvajanja, Ylönen je krajem iste godine osnovao SSH Communications Security kako bi nastavio razvoj i komercijalizirao SSH.

Ylönen je 1995. također objavio Nacrt internetske skupine za inženjering (IETF) koji je napisao dokumentirao SSH-1 protokol. Ograničenja su uskoro pronađena u protokolu i njih se nije moglo riješiti bez utjecaja na kompatibilnost s unazad. Rješenje je bila nova verzija protokola, a SSH-2 Ylönenova je kompanija pokrenula 1996. godine.

SSH-2 predstavio je nove algoritme, što je potaknulo IETF da osnuje radnu skupinu koja je željela standardizirati protokol. Grupa je dobila nadimak SECSH, za secure Shell, a svoj prvi internetski nacrt za SSH-2 objavio je 1997. godine.

Softver za SSH-2 objavljen je 1998. godine, ali nije odmah usvojen na široko rasprostranjen način zbog restriktivnijeg licenciranja. 2006. godine je izmijenjena verzija protokola postala standard od strane IETF-a. Ovo je bilo sigurnije, pomoću provjere autentičnosti poruka za provjeru integriteta i razmjene ključeva Diffie-Hellman za provjeru autentičnosti.

Godine 1999. projekt OpenBSD objavio je OpenSSH. OpenSSH je besplatna verzija protokola koja se temelji na modifikacijama koje je Björn Grönvall napravio u SSH 1.1.12. Programeri su se vratili na ovu stariju verziju i znatno je izmijenili jer je posljednja verzija SSH-a bila potpuno otvoreni izvorni kod. OpenSSH je sada najrasprostranjenija opcija i od tada se provodi u nizu operativnih sustava, kao što su Windows, macOS, Linux, Solaris i drugi.

SSH-1 vs SSH-2 vs OpenSSH

Kao što je gore spomenuto, SSH-1 je prva verzija protokola, koja je izvorno objavljena u licenca otvorenog koda. Smatra se nesigurnim i ne bi ga trebalo provoditi. Vlastita verzija, SSH-2, i slobodno dostupna verzija, OpenSSH, ostaju kao održive alternative.

SSH-2 i OpenSSH su u osnovi isti kada je riječ o njihovoj arhitekturi i načinu rada. Glavna je razlika što vlasnička inačica dolazi s nizom mogućnosti podrške, dok se one koje koriste OpenSSH moraju osloniti na resurse koje stvori zajednica.

SSH: Tehnički detalji

SSH-1 funkcionirao je kao jedinstveni protokol, ali ovdje nećemo ulaziti jer je zastario. Umjesto toga, usredotočit ćemo se na SSH-2 i OpenSSH, koji se sastoje od tri odvojena protokola:

• Protokol prijevoza – Time se uspostavlja veza i pruža osnovna sigurnost.
• Protokol provjere autentičnosti – Ovaj se sloj koristi za provjeru autentičnosti klijenta.
• Protokol veze – Ovaj protokol obrađuje kanale preko kojih se podaci prenose.

Svaki od ovih protokola služi jedinstvenu ulogu koja djeluje na uspostavljanju i osiguranju veze, autentifikaciji druge strane i prenosu podataka. Zadani priključak TCP veze je 22, a veze su postavljene između SSH klijenta i SSH poslužitelja duž model klijent-poslužitelj.

Proces daljinske prijave na SSH odvija se prema sljedećoj osnovnoj strukturi (s varijacijama ovisno o konfiguraciji), koje ćemo detaljnije obraditi u nastavku:

• Klijent kontaktira SSH poslužitelj kako bi započeo vezu.
• Zatim poslužitelj šalje svoj javni ključ klijentu radi provjere njegova identiteta.
• Dvije strane dogovaraju parametre za vezu, a zatim uspostavljaju siguran kanal duž tih linija.
• Tada se korisnik prijavljuje u operativni sustav poslužitelja i sada može daljinski upravljati svojim zadacima.

Transportni protokol

Transportni sloj protokol je niske razine koji vodi računa o sljedećim zadacima.

• Autentifikacija glavnog računala poslužitelja
• Razmjena ključeva
• Šifriranje za povjerljivost podataka
• Provjera integriteta radi provjere jesu li podaci izmijenjeni
• Uspostavljanje ID-a sesije koji se može koristiti u ostalim protokolima

transportni protokol potvrđuje samo poslužitelj, a ne klijenta (autentifikacija klijenta vrši se u protokolu autentifikacije ako je potrebna).

U transportnom sloju klijent započinje vezu, a dvije se strane dogovaraju kako će se ključevi razmjenjivati, koji će se algoritam javnog ključa koristiti, koji šifrirani ključ simetričnog ključa šifrirat će podatke, koji će se algoritam provjere identiteta poruke koristiti za provjeru podataka i koja metoda kompresije (ako ih ima) će se implementirati.

Jednom kada veza krene, i poslužitelj i klijent moraju je poslati putem identifikacijskog niza, koji uključuje verziju protokola (2.0).

Pregovaranje o algoritmu

Da biste postavili parametre veze, obje strane šalju kroz paket koji sadrži popis sa sljedećim opcijama:

bajt SSH_MSG_KEXINIT

byte [16] kolačić (slučajni bajtovi)
list-imena kex_algorithms
popis imena imena server_host_key_algorithms
imenik lista encryption_algorithms_client_to_server
name-list encryption_algorithms_server_to_client
lista s imenima mac_algorithms_client_to_server
imenik mac_algorithms_server_to_client
list-imena compression_algorithms_client_to_server
imenik compression_algorithms_server_to_client
popis imena imena_client_to_server
popis imena imena_server_to_client
boole first_kex_packet_follow
uint32 0 (rezervirano za buduće proširenje)

Svaka strana navodi parametre koje su spremni prihvatiti u vezi, odvojene zarezima. Preferirani algoritam treba prvo navesti.

Za razmjena ključeva (kex_algorithms), prvi algoritam koji obje strane podržavaju bit će odabran za vezu (mogu biti i drugi faktori koje je potrebno ispuniti, ovisno o tome koji je algoritam odabran). Ako dvije strane ne mogu pronaći međusobno podržani algoritam koji udovoljava tim zahtjevima, tada veza ne uspijeva.

Algoritmi za ključ glavnog računala poslužitelja podržani su algoritmi za ključ glavnog računala. Poslužitelj postavlja algoritme za koje ima ključeve računala, a klijent specificira algoritme koje je spreman prihvatiti. Odabir će ovisiti o tome zahtijeva li metoda razmjene ključeva koja zahtijeva ključ domaćina koji omogućuje šifriranje ili digitalni potpis

Obje strane nabrajaju algoritmi simetričnih ključeva da su spremni prihvatiti, s poželjnim metodama na vrhu. Mora se upotrijebiti prva opcija koja se pojavljuje na popisu klijenta, a koja se također nalazi na popisu poslužitelja. Ako se ne može postići dogovor, veza ne uspijeva.

I jedno i drugo MAC algoritam i the algoritam kompresije pregovaraju se na isti način.

Razmjena ključeva

Odgovorna je razmjena ključeva autentifikacija poslužitelja, i to postavlja tipke koje će se koristiti za osiguranje veze u sljedećim koracima. Obično započinje sa strankama koje međusobno šalju popise podržanih algoritama. Alternativno, svaka strana može pogoditi željeni algoritam druge strane i na početku poslati paket koji odgovara parametrima tog algoritma..

Ako je pretpostavka jedne strane tačna, taj se paket koristi kao prvi paket za razmjenu ključeva. Ako nijedno pretpostavljanje nije ispravno, svaka strana mora koraknuti unatrag i poslati svoje popise preferiranih algoritama. Ako poruka o razmjeni ključeva sadrži digitalni potpis poslužitelja kao dokaz njegove legitimnosti, smatra se eksplicitna autentifikacija poslužitelja. Ako umjesto toga koristi zajedničku tajnu, naziva se implicitna autentifikacija poslužitelja.

Razmjena ključeva odgovorna je i za utvrđivanje zajedničke tajne i hash-a. Vrijednost hash-a iz inicijalne razmjene ključeva postaje jedinstveni identifikator sesije, a koristi se i kao dio digitalnih potpisa koji dokazuju da je stranka pravi vlasnik svog privatnog ključa.

Upotreba hash funkcije ovisit će o metodi razmjene ključeva koja se odluči u pregovorima. Kad je razmjena ključeva dovršena, sve buduće komunikacije upotrebljavat će novi skup ključeva i algoritama.

Prema Nacrtu internetske skupine Internet inženjeringa (IETF), sljedeće se ključne metode razmjene smatraju sigurnim:

• curve25519-SHA256
• curve448-SHA512
• Diffie-Hellman grupu izmjenjivanje-SHA256
• Diffie-Hellman-group14-SHA256
• Diffie-Hellman-group15-SHA512
• Diffie-Hellman-group16-SHA512
• Diffie-Hellman-group17-SHA512
• Diffie-Hellman-group18-SHA512
• ecdh-SHA-2-nistp256
• ecdh-SHA-2-nistp384
• GSS-group14-SHA256
• GSS-group15-SHA512
• GSS-group16-SHA512
• GSS-group17-SHA512
• GSS-group18-SHA512
• GSS-nistp256-SHA256
• GSS-nistp384-SHA384
• GSS-nistp521-SHA512
• GSS-curve25519-SHA256
• GSS-curve448-SHA512
• rsa2048-SHA256

Algoritam ključa glavnog računala poslužitelja

Ovi algoritmi javnih ključeva koriste se za autentifikacija poslužitelja kao i sigurno utvrđivanje ID-a zajedničke sesije. Mogu se prema potrebi koristiti i za provjeru autentičnosti domaćina. SSH je dizajniran za rad s nizom algoritama javnih ključeva, vrsta kodiranja i formata:

• Koristi algoritme javnih ključeva za šifriranje i / ili digitalni potpis.
• Može se implementirati niz metoda kodiranja, omogućujući konfiguraciju s različitim formatima podataka, padom i redoslijedom bajtova.
• Različiti formati tipki omogućuju kodiranje tipki na različite načine, kao i raspon prikaza certifikata.

Zadani algoritmi uključuju sljedeće, no postoje i neke druge varijacije koje se također mogu primijeniti:

• ssh-RSA
• ssh-RSA-SHA256
• ssh-dss
• ssh-dss-SHA256
• x509v3-znak-DSS
• x509v3-znak-DSS-SHA256
• x509v3-znak-RSA
• x509v3-znak-RSA-SHA256

Algoritmi za šifriranje

Algoritmi simetričnih ključeva koriste se za šifriraju podatke i pružaju povjerljivost. Parametri i zajednički ključ koji se koriste u postupku šifriranja utvrđuju se u ranijim fazama veze. Odabrani algoritam kriptira korisni teret, dužinu paketa, duljinu obloga i polja za oblaganje.

Niz različitih algoritama za šifriranje prihvaćen je u SSH-u, ali u sigurnosne svrhe najbolje je držati se AES-a. Ključevi trebaju biti najmanje 128-bitni, ali preferiraju se veći tipki.

MAC algoritmi

Protokol prijevoza provjerava integritet podataka dodavanjem paketa za provjeru autentičnosti poruke (MAC) u paket. Taj MAC zasnovan je na zajedničkoj tajni (koja je uspostavljena u razmjeni ključeva), rednom broju paketa i sadržaju paketa. Izračunava se prije enkripcije.

Provedbe moraju ponuditi neovisni algoritam koji se pokreće u svakom smjeru, iako je idealno ako se isti koristi na obje strane. Može se implementirati veliki broj algoritama provjere autentičnosti poruka, no SHA-256 i novije verzije trebaju se koristiti u većini situacija da bi se osigurala visoka razina sigurnosti.

Kompresija

Kompresija nije SSH protokol i nije neophodna, a njezine implementacije moraju omogućiti povezivanju bez kompresije. Kompresija se može implementirati samo kao opcija, koristeći sheme poput zlib. Ako se koristi kompresija, to utječe samo na korisni teret. MAC i polje duljine paketa izračunavaju se na temelju komprimiranog korisnog opterećenja.

Paket protokola za transport

Paket protokola za transport oblikovan je tako da uključuje sljedeće informacije (kao i neke manje bitne detalje koji su izostavljeni):

• Duljina paketa
• Duljina obloge
• Korisni teret
• punjenje
• Kôd za potvrdu poruke (MAC)

Protokol provjere autentičnosti

Ovaj protokol poslužitelj koristi za ovjeriti klijenta. To mogu učiniti s različitim mehanizmima, od kojih se mnogi oslanjaju na ID sesije utvrđen u protokolu prijevoza. Neki koriste provjere šifriranja i integriteta iz transportnog protokola zajedno sa ID-om sesije, dok drugi koriste ove algoritme sami.

Poslužitelj koristi svoje lokalno pravilo da odluči koje će metode provjere autentičnosti prihvatiti od pojedinog korisnika. Budući da je poslužitelj već provjeren u protokolu prijevoza, nema potrebe ponovno provjeravati poslužitelj.

Sigurnost protokola provjere autentičnosti ovisi o prometnom protokolu koji se pokreće preko vrha. Ako transportni protokol ne može jamčiti povjerljivost ili provjeriti integritet podataka, to ograničava način na koji se protokol autentičnosti može sigurno koristiti.

Primjerice, ako prometni protokol ne primjenjuje zaštitu integriteta, onda zahtjevi poput promjena lozinke ne bi trebali biti dopušteni, jer bi to ostavilo mogućnosti za napadače da diraju u podatke bez da se primijete.

Protokol provjere autentičnosti koristi provjeru javnih ključeva pod pretpostavkom da ni privatni ključ glavnog računala, ni ključ klijentskog računala nisu ugroženi.. Ako je poslužitelj ugrožen, to može dovesti do puštanja korisničkog imena i lozinke za napadača.

Da bi provjera autentičnosti utemeljene na domaćinu bila sigurna, klijent ne smije biti ugrožen. Ako postoji mogućnost, treba dodati druge metode autentifikacije. Važno je to napomenuti postupak provjere autentičnosti jak je koliko i najslabija metoda razmjene koju poslužitelj prihvaća.

Proces provjere autentifikacije

Protokol provjere autentičnosti započinje kada poslužitelj klijentu pošalje popis njegovih prihvaćenih metoda provjere autentičnosti. Klijent tada može birati između tih metoda bilo kojim redoslijedom. Ovaj postupak daje kontrolu poslužitelju, ali također omogućava dovoljno fleksibilnosti da se klijent može dogovoriti o korištenju najpovoljnije metode.

Najčešći načini provjere autentičnosti klijenta uključuju:

• Javni ključ – Ova metoda koristi algoritme poput RSA, DSA i ECDSA za provjeru autentičnosti klijenta putem kriptografije s javnim ključem. Neke implementacije također koriste x.509 certifikate. Poslužitelj provjerava klijentov digitalni potpis na njihovom javnom ključu kako bi provjerio identitet klijenta.
• Zaporka – Lozinke se mogu koristiti i za autentifikaciju klijenta. Klijent šalje svoju lozinku (koja bi se trebala kriptirati transportnim protokolom). Ako se lozinka podudara s pohranjenom vrijednošću poslužitelja, prihvaća se i provjera autentičnosti.
• GSSAPI – Prema ovoj metodi, za jednokratnu prijavu mogu se koristiti vanjski programi poput Kerberosa.
• Tipkovnica interaktivna – Ova tehnika omogućuje jednokratnu provjeru lozinke tako da poslužitelj zatraži od klijenta informacije.

Protokol povezivanja

Predstavlja protokol veze kako će se više kanala podataka kombinirati preko sigurnog transportnog sloja. Također se bavi parametrima koji se koriste za pristup sigurnim podsustavima na host poslužitelju, kao i prosljeđivanje proxy-a i pristup školjkama..

Protokol povezivanja nalazi se na vrhu transportnog sloja i protokola provjere autentičnosti. Omogućuje daljinsko izvršavanje naredbi, kao i proslijeđene X11 i TCP / IP veze. Ako je poslužitelj ili klijent ugrožen, protokol veze nije siguran.

kanali

Kanali su osnovni putevi komunikacije, a može ih otvoriti bilo koja strana. Kanali mogu uključivati ​​terminalne sesije, prosljeđene veze i druge oblike komunikacije. Kada postoji više kanala, oni se kombiniraju u jednu vezu.

Otvaranje kanala

Svaki je kanal označen na oba kraja, mada se brojevi mogu razlikovati na obje strane. Kad jedna strana zatraži otvaranje kanala, šalje njegov broj kanala kao dio poruke, kao i informacije o početna veličina prozora i the maksimalna veličina paketa.

Početna veličina prozora označava koliko podataka može primiti stranka koja otvara kanal. Ako treba poslati više podataka, prozor se prvo mora prilagoditi. Isto tako, maksimalna veličina paketa određuje koliko veliki paket može biti primljen.

Kad jedna strana zahtijeva da se kanal otvori, druga strana će otvoriti kanal ako se u njega može smjestiti. U suprotnom, poslat će poruku o neuspjehu. Kanali se ne mogu otvoriti iz sljedećih razloga:

• Zabranjena od strane uprave
• Veza nije uspjela
• Nepoznata vrsta kanala
• Manjak resursa

Ako bilo koja strana veze želi poslati više podataka nego što prozor trenutno dopušta, mogu poslati poruku sa zahtjevom za dodavanje više bajtova.

Zatvaranje kanala

Nakon što jedna strana veze završi prijenos podataka, trebala bi poslati poruku koja pokazuje da je završila s korištenjem kanala. Unatoč tome, kanal je otvoren, a podatke i dalje može slati druga strana. Ako stranka želi potpuno prekinuti kanal, to čini sa zasebnom porukom o raskidu.

SSH sigurnost

Različite verzije SSH-a imale su svaka svoja sigurnosna pitanja, iako postojeće konfiguracije SSH-2 i OpenSSH smatraju se daleko sigurnijima od SSH-1.

SSH-1

SSH-1 se općenito smatra nedostatnim, s nizom različitih ranjivosti. Oni uključuju pogrešku u SSH 1.5 koji je omogućio neovlaštenim korisnicima da umetnu sadržaj u SSH protok podataka. Ovaj napad iskoristio je minimalnu zaštitu integriteta podataka algoritma CRC-32.

Ovaj napad ublažen je SSH kompenzacijskim napadačem koji je integriran u većinu novijih implementacija. Ovaj je popravak doveo do nove ranjivosti koja je imala moć izvršavanja proizvoljnog koda s korijenskim povlasticama.

Postoji i ranjivost koja omogućava protivnicima da mijenjaju posljednji blok u sesiji koji koristi IDEA-enkripciju, kao i onaj koji kompromitiranom poslužitelju omogućuje prosljeđivanje postupka autentifikacije klijenta na drugi poslužitelj.

Zbog ovih sigurnosnih problema trebalo bi umjesto njega koristiti SSH-2. Da biste osigurali sigurnost implementacije, trebali biste i vi onemogućiti ponovno pregovaranje na SSH-1, jer napadi mogu to iskoristiti za pristup podacima putem slabije razine zaštite SSH-1.

SSH-2

SSH-2 ranjiv je na teorijski napad protiv zadanog načina šifriranja, CBC. Omogućuje napadaču da oporavi do 32 bita otvorenog teksta iz šifriranog bloka. To se može ublažiti korištenjem načina rada brojača (CTR) i pretvaranja blok šifre u šifru toka.

Der Spiegel je krajem 2014. objavio dokumente NSA koji su nagovještavali da NSA ponekad može razbiti SSH. Ovaj pušteni NSA PowerPoint kaže da NSA može “Potencijalno oporavite korisnička imena i lozinke“, Iako više nisu navedeni. Nije poznato kojim je metodama to agencija koristila, no čini se malo vjerojatnim da će svoje sposobnosti polagati u svojoj internoj dokumentaciji.

U [year]. godini je došlo do curenja Vault 7, i to je otkriveno CIA je imala dva alata koja su se mogla koristiti za presretanje i krađu SSH prijava i lozinki. BothanSpy je ciljao Windows Xshell klijente, dok se Gyrfalcon koristio protiv OpenSSH klijenta na više različitih distribucija Linuxa.

Ovi alati mogu ukrasti vjerodajnice i potom ih vratiti na CIA server. Nijedan od ovih napada ne može prekršiti sam protokol; oni samo koriste druge napade bočnih kanala koji ih mogu zaobići u određenim implementacijama.

Unatoč tim napadima, SSH-2 smatra se sigurnim u većini situacija, pod uvjetom da se provodi na odgovarajući način. Ciljevi visoke vrijednosti ili oni koji koriste zastarjele ili loše implementacije trebali bi razmotriti druge mogućnosti.

OpenSSH

U OpenSSH verziji 2, otkriven je napad koji je iskoristio slabost u SSH binarnom paketu. Napad je omogućio istraživačima sa Londonskog sveučilišta da iz kriptiranog bloka povrate 14 bita otvorenog teksta. To je ublaženo u izdanju 5.2 tako što je protokol pročitao cijelu nevažeću duljinu paketa ili kôd za provjeru autentičnosti poruke, a ne prekinuo vezu..

U verzijama 6.8 i 6.9, Linux bi se mogao koristiti za izvršavanje proizvoljnih naredbi na terminalima drugih korisnika. To je postignuto ranjivošću eskalacije privilegija koja je omogućila napadačima da ubrizgavaju znakove pomoću TIOCSTI kontrole ulaza / izlaza.

Je li SSH siguran?

Iako se može činiti da SSH ima puno sigurnosnih problema, to je relativnoy normalno da se u različitim implementacijama protokola može naći nekoliko ranjivosti. To ne znači da SSH protokol nije siguran. Umjesto toga, to samo znači treba ga pravilno provoditi.

Sve dok upotrebljavate bilo jedno SSH-2 ili OpenSSH i konfiguriran je na način koji je prikladan za vašu upotrebu, trebali biste se osjećati sigurni u zaštitu koju SSH pruža vašoj vezi. Zato je i dalje takav protokol koji se često koristi, posebno za potrebe udaljenog pristupa i tuneliranja.

Vidi također: Objašnjene uobičajene vrste šifriranja

Pozadina tehnologije cyber mreže autor: TheDigitalArtist pod licencom pod CC0