Mi az SSH és hogyan működik?

Secure SHAz ell (SSH) egy általánosan megvalósított biztonsági protokoll, számos különböző felhasználással. A legismertebb alkalmazás lehetővé teszi a felhasználók számára biztonságosan elérheti a távoli számítógépeket és szervereket, de felhasználható alagútoláshoz, port-továbbításhoz, biztonságos fájlátvitelhez és még sok máshoz.

Ebben az útmutatóban bemutatjuk mi az SSH, mire használják, a protokoll története, annak technikai részletei, valamint a biztonsági kérdések ezt figyelembe kell venni.

Az SSH három különálló protokollból áll: a szállítási réteg, a hitelesítési réteg és a csatlakozási réteg. Ezek együttesen a másik fél hitelesítését szolgálják a kapcsolatban, titkosítás révén titkosítást nyújtanak, és ellenőrzik az adatok integritását. Az SSH manapság leggyakrabban vagy védett SSH-2, vagy pedig nyílt forráskódú iterációként, OpenSSH.

Az SSH felhasználásai

Az SSH sokoldalú protokoll. Szerkezete és biztonsági jellemzői lehetővé teszik számos felhasználását, például távoli eléréshez, port-továbbításhoz, alagútoláshoz és biztonságos fájlátvitelhez..

Távoli hozzáférés

A távoli hozzáférés lehetőséget nyújt a felhasználók számára jelentkezzen be egy másik számítógépre vagy szerverre a saját gépről. A célgépek helyi fájljainak eléréséhez vagy szolgáltatások elvégzéséhez használják, anélkül, hogy fizikailag ott lennének.

Az olyan programok, mint a Telnet és az rlogin, szintén rendelkeznek ezzel a funkcióval, ám hiányzik az SSH biztonsági funkciói. Az SSH-ban alkalmazott titkosítási és hitelesítési intézkedések lehetővé teszik a felhasználók számára, hogy védett módon csatlakozzanak egy másik szerverhez vagy számítógéphez, még egy potenciálisan veszélyes közbenső hálózaton keresztül is..

Az SSH távoli elérését általában úgy hajtják végre, hogy az alkalmazottak távolról is dolgozhassanak, vagy lehetővé tegyék az informatikai osztály számára a feladatok elvégzését anélkül, hogy fizikailag kellene a géphez menniük. Használható távoli adminisztrációhoz, hálózati infrastruktúra menedzsmenthez, automatizálás beállításához, biztonsági másolatok létrehozásához és így tovább.

Kikötőszállítás

A porttovábbítás a kérések átvitele az egyik címről és portszámról a másikra. A hálózati címfordítást (NAT) alkalmazza a portok átirányítására a helyi hálózat és a távoli számítógép között, lehetővé téve egy eszközhöz való hozzáférést a hálózaton kívülről.

A kikötő továbbítás három különböző módon végezhető:

• Helyi kikötői továbbítás – A helyi port továbbítása lehetővé teszi a helyi ügyfél és a külső hálózat összekapcsolását. Hatékony lehet például a helyileg blokkolt webhelyek elérésére vagy a tűzfal mögött álló adatbázishoz való kapcsolódásra..
• Távoli port-továbbítás – Az ilyen típusú továbbítás lehetővé teszi a szerveroldali alkalmazások számára az ügyféloldalon elérhető szolgáltatások elérését. Az SSH távoli port-továbbítása lehetővé teszi a felhasználók számára, hogy biztonságosan csatlakozzanak a távoli szerverekhez a helyi PC-n keresztül azáltal, hogy egy helyi portot átirányítanak egy távoli SSH szerverre.
• Dinamikus kikötői továbbítás – Ez lehetővé teszi a felhasználók számára, hogy adatokat küldjenek egy adott porton keresztül egy távoli számítógépre vagy szerverre számos SSH szerver segítségével, amelyek proxykként működnek..

Alagút

Az alagút-protokollok beágyazást használnak az adatok hálózatok közötti mozgatására. Az alagutak kiépíthetők annak érdekében, hogy a nem natív protokollok olyan hálózatokon keresztül futhassanak, amelyek általában nem támogatják őket. Egy másik általános alkalmazás a biztonságot nyújt egy nem biztonságos hálózaton keresztül.

Az alagutazási protokollok a kritikus csomagokat egy másik csomag hasznos teherébe csomagolják. Az SSH-alagút lehetővé teszi a felhasználók számára a hálózati biztonság megkerülését, az eszközök nem natív hálózati protokollal történő összekapcsolását, és az átvitt adatok biztonságát. Gyakran használják a távoli felhasználók biztonságos összekapcsolására a szervezet online erőforrásaival.

SFTP

Az SSH fájlátviteli protokoll (FTP), más néven biztonságos fájlátviteli protokoll, biztonságos módot kínál a fájlok elérésére, átvitelére és kezelésére. Ez az FTP biztonságos alternatívája, és kihasználja az SSH protokollt a fájlok biztonságos küldésére, fogadására és adminisztrálására.

SCP

A Biztonságos Másolás Protokoll (SCP) hasonló az SFTP-hez, de hatóköre korlátozottabb. Ez csak a biztonságos fájlátvitelt teszi lehetővé, ahelyett, hogy az SFTP távoli fájlrendszer-protokollként működne a teljes szolgáltatásban.

állványok & SSH-t használó alkalmazások

A szabadalmaztatott SSH vagy az OpenSSH használható minden nagyobb operációs rendszerben. Unix-alapú platformon érhető el, például OpenBSD, macOS, Linux és Solaris, míg a Windows felhasználók az SSH-t a PowerShell-en keresztül használhatják..

Az SSH története

Az SSH-t Tatu Ylönen 1995-ben fejlesztette ki a Helsinki Mûszaki Egyetemen, válaszul egy jelszó-szimatos támadásra az egyetem hálózatán. Célja volt, hogy alternatívát kínáljon a hasonló protokollokhoz FTP, TELNET, rsh és rlogint, amely nem biztosította a bizalmasságot, és nem biztonságos módon hitelesítette a felhasználókat.

Az SSH-t 1995-ben ingyenesen bocsátották a nagyközönség elé, és jól fogadták. Gyors elfogadása mellett, Ylönen ugyanazon év végére megalapította az SSH Communications Security-t az SSH fejlesztésének és kereskedelmének folytatása érdekében..

1995-ben Ylönen közzétette egy Internet Engineering Task Force (IETF) internetes tervezetét is dokumentálta az SSH-1 protokollt. A protokollban hamarosan találtak korlátozásokat, és ezeket nem lehetett megoldani anélkül, hogy befolyásolta volna a visszamenőleges kompatibilitást. A megoldás a protokoll új verziója volt, és az SSH-2-t az Ylönen cég 1996-ban indította el.

Az SSH-2 új algoritmusokat tartalmazott, amelyek arra késztették az IETF-et, hogy hozzon létre egy munkacsoportot, amelynek célja a protokoll szabványosítása. A csoport SECSH beceneve volt secure SHell, és 1997-ben közzétette az SSH-2 első internetes tervezetét.

Az SSH-2 szoftverét 1998-ban adták ki, ám szigorúbb engedélyezése miatt azt nem hajtották végre azonnal széles körben.. 2006-ban az IETF a protokoll megváltoztatott változatát standardvá tette. Ez sokkal biztonságosabb volt, az üzenet hitelesítési kódokkal ellenőrizve az integritást és a Diffie-Hellman kulcscserét a hitelesítéshez.

1999-ben az OpenBSD projekt kiadta az OpenSSH-t. Az OpenSSH a protokoll ingyenes verziója ez azon módosításokon alapul, amelyeket Björn Grönvall az SSH 1.1.12-hez elvégez. A fejlesztők visszatért erre a régebbi verzióra, és jelentősen megváltoztatta, mert az SSH utolsó verziója volt teljesen nyílt forráskódú. Az OpenSSH most a legszélesebb körben használt lehetőség, és azóta számos operációs rendszerben bevezették, mint például a Windows, a MacOS, a Linux, a Solaris és mások..

SSH-1 vs SSH-2 vs OpenSSH

Mint fentebb megjegyeztük, az SSH-1 a protokoll első verziója, amelyet eredetileg egy nyílt forráskódú licenc. Nem biztonságosnak tekintik, ezért nem szabad végrehajtani. Ez lehetővé teszi a szabadalmaztatott SSH-2 verziót és a szabadon elérhető OpenSSH verziót életképes alternatívákként..

Az SSH-2 és az OpenSSH lényegében azonosak az építészet és a működés szempontjából. A fő különbség az, hogy a szabadalmaztatott változat számos támogatási lehetőséget kínál, míg az OpenSSH-t használóknak a közösség által szabadon létrehozott erőforrásokra kell támaszkodniuk..

SSH: A műszaki részletek

Az SSH-1 egyetlen protokollként működött, de itt nem foglalkozunk vele, mivel elavult. Ehelyett az SSH-2-re és az OpenSSH-ra összpontosítunk, amelyek egyaránt három különálló protokollból állnak:

• A szállítási protokoll – Ez létrehozza a kapcsolatot és biztosítja az alapjául szolgáló biztonságot.
• A hitelesítési protokoll – Ezt a réteget az ügyfél hitelesítésére használják.
• A csatlakozási protokoll – Ez a protokoll kezeli az adatokat továbbító csatornákat.

Ezeknek a protokolloknak egyedülálló szerepe van, amely kapcsolat létesítéséhez és biztosításához, a másik fél hitelesítéséhez és az adatok átviteléhez jár. Az alapértelmezett TCP csatlakozási port 22, és a kapcsolatok az SSH kliens és az SSH szerver között vannak létrehozva kliens-szerver modell.

Az SSH távoli bejelentkezési folyamata az alábbi alapvető struktúra szerint megy végbe (a konfigurációtól függően változó), amelyet később részletesebben ismertetünk:

• Az ügyfél kapcsolatba lép az SSH szerverrel a kapcsolat megkezdéséhez.
• Ezután a szerver megküldi a nyilvános kulcsot az ügyfélnek, hogy hitelesítse személyazonosságát.
• A két fél megtárgyalja a kapcsolat paramétereit, majd létrehoz egy biztonságos csatornát ezen a vonalon.
• Ezután a felhasználó bejelentkezik a kiszolgáló gazdagépének operációs rendszerébe, és távolról felügyelheti feladatait.

Szállítási protokoll

A szállítási réteg alacsony szintű protokoll, amely a következő feladatokat látja el.

• Szerver host hitelesítés
• Kulcscsere
• Titkosítás az adatok bizalmas kezelése érdekében
• Az integritás ellenőrzése annak ellenőrzésére, hogy az adatok nem változtak-e
• A többi protokollban felhasználható munkamenet-azonosító létrehozása

Az A szállítási protokoll csak a szervert hitelesíti, és nem az ügyfelet (az ügyfél hitelesítése a hitelesítési protokollban történik, ha szükséges).

A szállítási rétegben a kapcsolatot az ügyfél kezdeményezi, és a két fél ezután tárgyalja a kulcsok cseréjének módját, mely nyilvános kulcs algoritmust fogja használni, melyik szimmetrikus kulcs rejtjelezi az adatok titkosítását, mely üzenet hitelesítési algoritmust fogja használni az adatok ellenőrzéséhez, és hogy melyik tömörítési módszert (ha van) alkalmazzuk.

A kapcsolat megkezdése után mind a kiszolgálónak, mind az ügyfélnek azonosító karakterláncon keresztül kell elküldenie, amely tartalmazza a protokoll verzióját (2.0).

Algoritmus tárgyalása

A kapcsolat paramétereinek beállításához mindkét fél csomag útján küld egy listát, amely tartalmazza a következő lehetőségeket:

byte SSH_MSG_KEXINIT

byte [16] cookie (véletlen bájt)
névlista kex_algorithms
névlista kiszolgáló_szellem_kulcs_algoritmusok
névlista encryption_algorithms_client_to_server
névlista encryption_algorithms_server_to_client
névlista mac_algorithms_client_to_server
névlista mac_algorithms_server_to_client
névlista tömörítési_algorithms_client_to_server
névlista tömörítési_algorithms_szerver_to_client
névlisták nyelvek_kliens_kiszolgálók
névlista nyelvek_kiszolgáló_személyzet
logikai első_kex_csomag_követések
uint32 0 (fenntartva a későbbi kiterjesztéshez)

Mindkét oldal vesszővel elválasztva sorolja fel azokat a paramétereket, amelyeket hajlandó elfogadni a kapcsolatban. Először fel kell sorolni az előnyben részesített algoritmust.

mert kulcscsere (kex_algorithms), az első algoritmus, amelyet mindkét fél támogat, a kapcsolathoz kerül kiválasztásra (lehetnek más tényezők is, amelyeket teljesíteni kell, attól függően, hogy melyik algoritmust választották). Ha a két fél nem talál kölcsönösen támogatott algoritmust, amely kielégíti ezeket a követelményeket, akkor a kapcsolat meghiúsul.

Szerver gazda kulcs algoritmusok a kiszolgáló host kulcsának támogatott algoritmusai. A szerver meghatározza azokat az algoritmusokat, amelyekhez host kulcsokkal rendelkezik, míg az ügyfél megadja azokat az algoritmusokat, amelyeket készen áll az elfogadásra. A választás attól függ, hogy a kiegyenlített kulcscsere-módszerhez titkosításra képes host kulcsra vagy digitális aláírásra van szükség

Mindkét oldal felsorolja a szimmetrikus kulcsú algoritmusok hogy hajlandóak elfogadni, a tetején az előnyben részesített módszerekkel. Az ügyfél listáján megjelenő első lehetőséget, amely szintén a kiszolgáló listáján található, használni kell. Ha nem lehet megállapodást kötni, a kapcsolat meghiúsul.

Mind a MAC algoritmus és a tömörítési algoritmus azonos módon tárgyalnak.

Kulcscsere

A kulcscsere felel szerver hitelesítés, és az beállítja azokat a kulcsokat, amelyeket a kapcsolat biztosításához fog használni a következő lépésekben. Általában azzal kezdődik, hogy a felek elküldik egymásnak a támogatott algoritmusok listáját. Alternatív megoldásként, mindkét oldal kitalálhatja a másik fél preferált algoritmusát, és elküldhet egy csomagot, amely megfelel az algoritmus paramétereinek az elején.

Ha az egyik fél feltételezése helyes, akkor ezt a csomagot kell használni az első kulcscsere-csomagként. Ha egyik kitalálás sem helyes, akkor mindkét félnek lépést kell hátrálnia és el kell küldenie a preferált algoritmusok listáját. Ha a kulcscsere-üzenet tartalmazza a szerver digitális aláírását a szerver legitimitásának igazolására, akkor ezt figyelembe veszik explicit kiszolgálói hitelesítés. Ha ehelyett a megosztott titkot használja, akkor erre hivatkoznak implicit szerver hitelesítés.

A kulcscsere felelõs egy közös titok és egy kivonat létrehozásáért is. A kezdeti kulcscseréből származó kivonatérték a munkamenet egyedi azonosítójává válik, és a digitális aláírások részeként is felhasználják, amelyek bizonyítják, hogy a fél a magánkulcs valódi tulajdonosa..

Az alkalmazott hash-függvény a tárgyalások során megválasztott kulcscsere-módszertől függ. A kulcscsere befejezésekor minden jövőbeni kommunikáció az új kulcskészletet és algoritmusokat fogja használni.

Az Internet Engineering Task Force (IETF) internetes tervezete szerint a következő kulcscsere-módszerek biztonságosnak tekinthetők:

• curve25519-sha256
• curve448-sha512
• Diffie-Hellman-csoport-csere-sha256
• DiffieHellman–group14-sha256
• DiffieHellman–group15-sha512
• DiffieHellman–group16-sha512
• DiffieHellman–group17-sha512
• DiffieHellman–group18-sha512
• ECDH-SHA2-nistp256
• ECDH-SHA2-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

Szerver gazda kulcs algoritmus

Ezeket a nyilvános kulcsú algoritmusokat használják szerver hitelesítés, valamint a megosztott munkamenet azonosító biztonságos létrehozása. Opcionálisan felhasználhatók a gazdagép hitelesítésére is. Az SSH-t úgy tervezték, hogy számos nyilvános kulcsú algoritmus, kódolási típus és formátum működjön:

• Titkosításhoz és / vagy digitális aláírásokhoz nyilvános kulcsú algoritmusokat használ.
• Számos kódolási módszer valósítható meg, amely lehetővé teszi a konfigurációt különböző adatformátumokkal, kitöltéssel és byte sorrenddel.
• Különböző kulcsformátumok teszik lehetővé a kulcsok különböző módon történő kódolását, valamint a tanúsítvány-ábrázolások széles skáláját.

Az alapértelmezett algoritmusok a következőket foglalják magukban, de van néhány más változat is, amelyek szintén megvalósíthatók:

• ssh-rsa
• ssh-rsa-sha256
• ssh-DSS
• ssh-DSS-sha256
• x509v3-sign-DSS
• x509v3-sign-DSS-sha256
• x509v3-sign-rsa
• x509v3-sign-rsa-sha256

Titkosítási algoritmusok

A szimmetrikus kulcsú algoritmusok hozzászoktak titkosítja az adatokat és bizalmasan kezeli. A titkosítási folyamatban használt paramétereket és megosztott kulcsot a kapcsolat korábbi szakaszaiban állapítják meg. A kiválasztott algoritmus titkosítja a hasznos teher, a csomag hossza, a párnázat hossza és a párna mezőket..

Számos különféle titkosítási algoritmust fogadnak el az SSH-ban, de biztonsági okokból a legjobb az AES-sel ragaszkodni. A kulcsoknak legalább 128 bitesnek kell lenniük, de a nagyobb kulcsok részesülnek előnyben.

MAC algoritmusok

A szállítási protokoll ellenőrzi az adatok integritását azáltal, hogy üzenet-hitelesítő kódot (MAC) ad hozzá a csomaghoz. Ez a MAC a megosztott titkon (amely a kulcscserében jön létre), a csomag sorszámán és a csomag tartalmán alapul. A kiszámítás előtt a titkosítás megtörténik.

A megvalósításoknak független algoritmust kell kínálniuk az egyes irányok futtatásához, bár ideális, ha mindkét oldalon ugyanazt használják. Az üzenetek hitelesítési algoritmusainak széles skálája valósítható meg, azonban az SHA-256-at és az azt meghaladó verziót a legtöbb esetben a magas szintű biztonság biztosítása érdekében kell használni..

összenyomás

A tömörítés nem kötelező az SSH protokollban, és megvalósításának lehetővé kell tennie a kapcsolatok tömörítés nélküli folytatását. A tömörítés csak opcióként valósítható meg, például a sémák használatával zlib. Ha tömörítést használ, ez csak a hasznos teherre hat. A MAC-t és a csomaghossz mezőt ezután kiszámítják a tömörített hasznos teher alapján.

Szállítási protokoll csomag

A szállítási protokoll csomag úgy van formázva, hogy tartalmazza a következő információkat (valamint néhány kevésbé lényeges részletet, amelyeket kihagytak):

• A csomag hossza
• A párnázat hossza
• A hasznos teher
• Párnázás
• Üzenet-hitelesítési kód (MAC)

Hitelesítési protokoll

Ezt a protokollt a szerver használja hitelesítse az ügyfelet. Ezt számos különféle mechanizmussal megteheti, amelyek közül sok a szállítási protokollban létrehozott munkamenet-azonosítón támaszkodik. Egyesek a titkosítási és integritási ellenőrzéseket a szállítási protokollból a munkamenet azonosítóval együtt használják, mások ezeket az algoritmusokat maguk is használják.

A kiszolgáló a helyi házirend alapján határozza meg, hogy mely hitelesítési módszereket fogadja el az egyes felhasználóktól. Mivel a kiszolgálót már hitelesítették a szállítási protokollban, nincs szükség a szerver újbóli hitelesítésére.

A hitelesítési protokoll biztonsága attól a szállítási protokolltól függ, amelyen fut. Ha a szállítási protokoll nem tudja garantálni az adatok bizalmas kezelését vagy ellenőrizni az adatok integritását, akkor ez korlátozza a hitelesítési protokoll biztonságos használatát.

Például, ha az integritásvédelmet a szállítási protokoll nem alkalmazza, akkor a jelszó megváltoztatására irányuló kéréseket nem szabad megengedni, mert ez lehetőséget ad a támadóknak arra, hogy megváltoztassák az adatokat anélkül, hogy észrevennék őket..

A hitelesítési protokoll nyilvános kulcsú hitelesítést alkalmaz azzal a feltételezéssel, hogy sem a kiszolgáló gazdagépének magánkulcsa, sem az ügyfélgazda kulcsa nem került veszélybe. Ha a kiszolgálót veszélyeztette, ez az ügyfél felhasználónevének és jelszavának a támadó számára történő kiadásához vezethet.

A host alapú hitelesítés biztonságának érdekében az ügyfelet nem szabad veszélyeztetni. Ha ez lehetséges, akkor más hitelesítési módszereket kell hozzáadni. Fontos ezt megjegyezni a hitelesítési folyamat csak annyira erős, mint a kiszolgáló által elfogadott leggyengébb csere módszer.

A hitelesítési protokoll folyamata

A hitelesítési protokoll akkor kezdődik, amikor a szerver elküldi az ügyfélnek az elfogadott hitelesítési módszerek listáját. Az ügyfél ezután bármilyen sorrendben választhat ezek közül a módszerek közül. Ez a folyamat irányítást ad a szerver számára, ugyanakkor elegendő rugalmasságot biztosít a kliens számára, hogy a legkényelmesebb módszert használhassa.

A leggyakoribb ügyfél-hitelesítési módszerek a következők:

• Nyilvános kulcs – Ez a módszer olyan algoritmusokat használ, mint például RSA, DSA és ECDSA, hogy az ügyfelet hitelesítse nyilvános kulcsú kriptográfia segítségével. Egyes megvalósítások x.509 tanúsítványokat is használnak. A szerver ellenőrzi az ügyfél digitális aláírását a nyilvános kulcsával szemben, hogy ellenőrizze az ügyfél azonosságát.
• Jelszó – A jelszavak felhasználhatók az ügyfél hitelesítésére is. Az ügyfél elküldi a jelszavát (amelyet a szállítási protokollnak titkosítania kell). Ha a jelszó megegyezik a szerver tárolt értékével, akkor a rendszer elfogadja és a hitelesítés tovább halad.
• GSSAPI – Ezen módszer szerint az olyan külső sémák, mint például a Kerberos, felhasználhatók az egyszeri bejelentkezéshez.
• Interaktív billentyűzet – Ez a technika biztosítja az egyszeri jelszó-hitelesítést azáltal, hogy a kiszolgáló információt kér az ügyféltől.

Csatlakozási protokoll

A csatlakozási protokoll meghatározza hogyan kombinálódnak több adatcsatorna a biztonságos szállítási rétegen keresztül. Ezenkívül foglalkozik a kiszolgáló gazdagépének biztonságos alrendszereinek eléréséhez használt paraméterekkel, valamint a proxy-továbbítással és a hozzáférési héjakkal..

A csatlakozási protokoll a szállítási réteg és a hitelesítési protokollok tetején található. Ez lehetővé teszi a távoli parancsfuttatást, valamint a továbbított X11 és TCP / IP kapcsolatokat. Ha a kiszolgálót vagy az ügyfelet veszélyeztette, akkor a csatlakozási protokoll nem biztonságos.

Csatornák

A csatornák az alapvető kommunikációs útvonalak, és bármelyik fél megnyithatja azokat. A csatornák tartalmazhatnak terminál-munkameneteket, továbbított kapcsolatokat és egyéb kommunikációs formákat. Ha több csatorna létezik, akkor azokat egy csatornába multiplexálják.

Csatornák megnyitása

Minden csatorna mindkét végén van számozva, bár a számok mindkét oldalon potenciálisan eltérhetnek. Amikor az egyik oldal egy csatorna megnyitását kéri, az üzenet részeként elküldi a csatorna számát, valamint a csatornára vonatkozó információkat kezdeti ablakméret és a maximális csomagméret.

A kezdeti ablakméret azt jelzi, hogy a csatornát megnyitó fél mennyi adatot képes fogadni. Ha további adatokat kell küldeni, akkor előbb be kell állítani az ablakot. Hasonlóképpen, a maximális csomagméret határozza meg, hogy mekkora csomag érhető el.

Ha az egyik oldal egy csatorna megnyitását kéri, a másik oldal megnyitja a csatornát, ha képes befogadni. Ha nem, hibaüzenetet küld. A csatornák nem nyithatók meg a következő okok miatt:

• Az adminisztráció tiltja
• Nem sikerült a kapcsolat
• Ismeretlen csatorna típus
• Erőforráshiány

Ha a kapcsolat egyik oldala több adatot akar küldeni, mint amennyit az ablak jelenleg lehetővé tesz, akkor küldhet egy üzenetet, amely további bájt hozzáadását kéri.

Csatornák bezárása

Miután a kapcsolat egyik oldala befejezte az adatátvitelt, üzenetet kell küldenie, jelezve, hogy befejezte a csatorna használatát. Ennek ellenére a csatornát nyitva tartják, és az adatokat a másik fél továbbra is elküldheti. Ha egy fél teljes mértékben meg akarja szakítani a csatornát, akkor ezt külön felmondási üzenettel teszi meg.

SSH biztonság

Az SSH különféle verziói mindegyikének megvan a maga biztonsági kérdése, bár a jelenlegi konfigurációja az Az SSH-2 és az OpenSSH sokkal biztonságosabbnak tekinthetők, mint az SSH-1.

SSH-1

Az SSH-1 általában hibásnak tekinthető, számos különféle sebezhetőséggel rendelkezik. Ide tartozik az SSH 1.5 hibája, amely lehetővé tette a jogosulatlan felhasználók számára, hogy tartalmat illesszenek be az SSH adatfolyamba. Ez a támadás kihasználta a CRC-32 algoritmus minimális adat integritásának védelmét.

Ezt a támadást enyhítették az SSH kompenzációs támadásdetektorral, amelyet a legtöbb újabb megvalósításba integráltak. Ez a javítás új biztonsági rést kapott, amelynek lehetősége volt önkényes kódot root jogosultságokkal végrehajtani.

Van egy olyan biztonsági rés is, amely lehetővé teszi az ellenfeleknek, hogy megváltoztassák az IDEA-titkosítást használó munkamenet utolsó blokkját, valamint egy olyan biztonsági rést, amely lehetővé teszi a sérült kiszolgálónak, hogy továbbítsa az ügyfél hitelesítési folyamatát egy másik kiszolgálóra..

Ezen biztonsági kérdések miatt az SSH-2-et kell használni. A megvalósítás biztonságának megőrzése érdekében azt is meg kell tennie letiltja az SSH-1 újratárgyalását, mivel a támadások kihasználhatják az adatait az SSH-1 gyengébb védettségi szintjén keresztül.

SSH-2

Az SSH-2 érzékeny az alapértelmezett titkosítási módja (CBC) elleni elméleti támadásra. Ez lehetővé teszi a támadó számára, hogy akár 32 bit sima szöveget is visszaállítson egy titkosított blokkból. Ezt enyhítheti a Számláló mód (CTR) használata, és a blokk rejtjelezés helyett patak rejtjelvé alakítása.

2014 végén a Der Spiegel kiadta az NSA dokumentumait, amelyek arra utaltak, hogy az NSA időnként megszakíthatja az SSH-t. Ez a kiszivárgott NSA PowerPoint kijelenti, hogy az NSA képes „Felhasználónevek és jelszavak helyreállítása”, Bár további részleteket nem adunk meg. Nem ismert, hogy az ügynökség milyen módszereket alkalmazott erre, de valószínűtlennek tűnik, hogy a saját belső dokumentációjában hazudik képességeiről..

A [year]-es Vault 7 szivárgásról kiderült a CIA-nak két eszköz volt, amelyek felhasználhatók az SSH bejelentkezések és jelszavak elfogására és ellopására. A BothanSpy a Windows Xshell klienseket célozta meg, míg a Gyrfalconat az OpenSSH kliens ellen számos különféle Linux disztribúcióban alkalmazták..

Ezek az eszközök képesek ellopni a hitelesítő adatokat, majd visszajuttatni azokat a CIA-kiszolgálóra. Ezeknek a támadásoknak egyike sem tudja megtörni magát a protokollt; csak más oldalsó csatornás támadásokat használnak, amelyek bizonyos megvalósításokban megkerülhetik azt.

E támadások ellenére az SSH-2 biztonságosnak tekinthető a legtöbb helyzetben, mindaddig, amíg azt megfelelően végrehajtják. Nagy értékű célok vagy azok számára, akik elavult vagy rossz megvalósítást használnak, fontolóra kell venniük a többi lehetőséget.

OpenSSH

Az OpenSSH 2. verziójában, támadást fedeztek fel, amely kihasználta az SSH bináris csomag gyengeségét. A támadás lehetővé tette a londoni egyetem kutatóinak, hogy egy titkosított blokkból 14 bites sima szöveget nyerjenek. Ezt enyhítették az 5.2 kiadásban azáltal, hogy a protokollt a kapcsolat érvénytelenítésének helyett az érvénytelen csomaghossz vagy az üzenet hitelesítési kódjának teljes leolvasására késztette..

A 6.8 és 6.9 verziókban a Linux felhasználható tetszőleges parancsok végrehajtására más felhasználók terminálján. Ezt olyan kiváltságos eszkalációval járó biztonsági rés révén valósították meg, amely lehetővé tette a támadók számára, hogy karaktereket adjanak be a TIOCSTI bemeneti / kimeneti vezérlővel..

Az SSH biztonságos?

Bár úgy tűnhet, hogy az SSH-nak sok biztonsági kérdése van, ez viszonylagosy normális, ha számos sérülékenységet talál a protokoll különféle megvalósításaiban. Ez nem azt jelenti, hogy az SSH protokoll nem biztonságos. Ehelyett azt csak azt jelenti helyesen kell végrehajtani.

Mindaddig, amíg egyiket sem használja SSH-2 vagy OpenSSH, és a felhasználásnak megfelelő módon van konfigurálva, bíznia kell abban a védelemben, amelyet az SSH biztosítja a kapcsolathoz. Ez az oka annak, hogy továbbra is ilyen gyakran használt protokoll, különösen a távoli elérés és az alagút kialakítása céljából.

Lásd még: Általános titkosítási típusok magyarázata

Kiberhálózati technológiai háttér A TheDigitalArtist licenc alatt áll CC0