TechCodeview

SSH: Secure Shell

Az SSH a Secure Shell rövidítése. Secure Socket Shell néven is ismert. A Secure Shell (SSH) nevű kriptográfiai hálózati protokoll a hálózati szolgáltatások biztonságos működtetésére szolgál a nem biztonságos hálózatokon. Az ügyfélkiszolgáló-architektúra az SSH-alkalmazások alapja, amelyek egy SSH-ügyfélpéldányt kapcsolnak össze egy SSH-kiszolgálóval.

A Telnet és a nem biztonságos távoli Unix shell protokollok, például a Berkeley Remote Shell (rsh) és a kapcsolódó rlogin és rexec protokollok utódjaként az SSH Unix-szerű operációs rendszerekhez készült, amelyek nem biztonságos, egyszerű szöveges hitelesítési token kommunikációt alkalmaznak.

Meghatározás

Az SSH-t többféleképpen alkalmazhatjuk. A legegyszerűbb megvalósítás az adatokat automatikusan generált nyilvános-privát kulcspárok segítségével titkosítja a kommunikációs csatorna és a hálózati kapcsolat mindkét végén. Ezt követően jelszóval hitelesíti a felhasználót. Amikor a felhasználó manuálisan generál egy nyilvános-privát kulcspárt, a hitelesítés gyakorlatilag befejeződik, amikor a kulcspár létrejön, lehetővé téve a munkamenet azonnali elindítását, jelszókérés nélkül.

az online bankolás hátrányai

Ebben az esetben a tulajdonos titokban tartja a megfelelő magánkulcsot, és a nyilvános kulcs minden olyan gépen telepítve van, amelynek hozzáférést kell biztosítania a tulajdonos számára. Bár a titkos kulcs szolgál a hitelesítés alapjául, a kulcsot soha nem küldik el a hálózaton keresztül a hitelesítés során. Az SSH megerősíti, hogy a nyilvános kulcs szolgáltatója is rendelkezik a megfelelő magánkulccsal.

Az ismeretlen nyilvános kulcs összekapcsolása egy ismert privát kulccsal az SSH összes verziójában kulcsfontosságú, mielőtt elfogadná azokat legitim, azonosítókkal rendelkező nyilvános kulcsokként. Ha egy támadótól elfogad egy nyilvános kulcsot annak érvényesítése nélkül, akkor a nem megbízható támadót legitim felhasználóként fogadja el.

Teremtés

Tatu Ylönen, egy finn informatikus hozta létre először az SSH-t 1995-ben. A protokollcsomag továbbfejlesztése számos fejlesztői csoportban ment végbe, ami különféle implementációs iterációkhoz vezetett. Minden népszerű operációs rendszerhez elérhető megvalósítás, beleértve a beágyazott rendszereket is. Az OpenSSH, amelyet az OpenBSD készítői 1999-ben tettek elérhetővé nyílt forráskódú szoftverként, a leggyakrabban használt szoftvercsomag.

OpenSSH-kulcsok kezelése hitelesítéshez

A jóváhagyott nyilvános kulcsok listája Unix-szerű rendszereken általában a ~/.ssh/authorized keys fájlban található a felhasználó saját könyvtárában, amely távoli bejelentkezési jogosultsággal rendelkezik. Az SSH csak akkor tartja tiszteletben ezt a fájlt, ha azt a tulajdonoson és a root-on kívül senki nem módosíthatja. A jelszóra már nincs szükség, ha a távoli vég nyilvános kulcsa és a helyi vég egyező titkos kulcsa is jelen van. De használhatunk egy jelmondatot a privát kulcs zárolására a sokkal nagyobb védelem érdekében. A titkos kódban gyakori helyeken is kereshetünk, és egy parancssori kapcsolóval megadhatjuk a teljes elérési utat (ssh esetén -i opció).

Az SSH emellett automatikus kulcsgenerálású, titkosított, jelszó alapú hitelesítést biztosít. Ebben a forgatókönyvben a támadó kiadhatja magát a megbízható szerveroldalnak, kérheti a jelszót, és megszerezheti azt (man-in-the-middle támadás). A szerver oldalon kikapcsolhatjuk a jelszavas hitelesítést.

Használat

Az SSH a kliens-szerver paradigmát használja. Általában az SSH-t használják naplózásra. A TCP-portokat is alagútba helyezi, X11 kapcsolatokat továbbít, és parancsokat hajt végre távoli rendszeren. A távoli kapcsolatokat lehetővé tevő SSH-démonokhoz való kapcsolatok általában egy SSH-kliens alkalmazás segítségével jönnek létre. Mindkettő gyakran megtalálható a legtöbb kortárs operációs rendszeren, mint például a macOS, Linux disztribúciók, OpenBSD, FreeBSD, NetBSD, Solaris és OpenVMS. Egyes verziók szabadalmaztatottak, ingyenesek és nyílt forráskódúak, különböző bonyolultságú és átfogó jellegűek (például a PuTTY és az OpenSSH Cygwin és OpenSSH verziója). Nevezetesen, az SSH alapértelmezés szerint nem szerepel a Windows verziókban a Windows 10 1709-es verziójáig.

Hasonló fájlkezelési (szinkronizálás, másolás és távoli törlés) funkciókat kínál az ingyenes és nyílt forráskódú WinSCP Windows alkalmazás, amely háttérként PuTTY-t használ. Anélkül, hogy telepíteni kellene az ügyfélszámítógépre, a WinSCP és a PuTTY csomagolva közvetlenül USB-meghajtóról működik. Az SSH-kiszolgáló Windows rendszerben történő beállításához gyakran szükséges egy funkció engedélyezése a beállítások alkalmazásban.

Az SSH kulcsfontosságú a felhőalapú számítástechnikában a csatlakozási problémák kezeléséhez és a felhőalapú virtuális gépek közvetlen internetkapcsolatának kitett biztonsági kockázatok megelőzése érdekében. A biztonságos internetkapcsolat egy SSH-alagút virtuális számítógépen keresztül, tűzfalon keresztül lehetséges. Ehhez a protokollhoz az IANA a 22-es TCP-portot, a 22-es UDP-portot és a 22-es SCTP-portot jelölte ki.

Az IANA már 2001-ben a jól ismert portok közé sorolta az SSH-kiszolgálók alapértelmezett 22-es TCP-portját. Az SCTP kapcsolatorientált szállítási réteg protokoll használható az SSH futtatására TCP helyett.

Történelmi haladás

1. iteráció

Intézménye hálózatán történt jelszószipogás ihlette Tatu Ylönent, a finn Helsinki Műszaki Egyetem kutatóját, aki megalkotta a protokoll (ma SSH-1 néven ismert) kezdeti iterációját 1995-ben.

Az SSH-t úgy tervezték, hogy átvegye a korábbi protokollok szerepét, beleértve az rlogint, a TELNET-et, az FTP-t és az rsh-t, amelyekből hiányoztak a robusztus hitelesítési és titkossági garanciák. Ylönen ingyenesen elérhetővé tette alkalmazását. 1995 júliusában a készülék gyorsan népszerűvé vált. 1995 végére 20 000 SSH felhasználó volt 50 különböző országban.

Az SSH előmozdítása és fejlesztése érdekében Ylönen 1995 decemberében létrehozta az SSH Communications Security-t. Különféle ingyenes szoftverkomponenseket, köztük a GNU libgmp-t használtak az SSH program első kiadásában, de az SSH Communications Security későbbi iterációi egyre inkább védett szoftverré nőttek. Becslések szerint 2000-re 2 millió felhasználó volt.

2. iteráció

Az Internet Engineering Task Force (IETF) az SSH protokoll 2-es verziójának létrehozásáért felelős munkacsoportot „Secsh” néven jelölte meg hivatalos dokumentációjában.

Az SSH-2, egy továbbfejlesztett protokoll iteráció, 2006-ban szabványossá vált. Az SSH-1 nem kompatibilis ezzel a verzióval. Az SSH-2 funkciókat és biztonsági frissítéseket kínál az SSH-1-hez képest. Például a Diffie-Hellman kulcscsere és a robusztus integritás-ellenőrzés üzenet-hitelesítési kódokon keresztül magasabb biztonságot nyújt. Az SSH-2 egyik új képessége, hogy egyetlen SSH-kapcsolaton keresztül korlátlan számú shell-munkamenetet tud működtetni. Mivel az SSH-2 fejlettebb és szélesebb körben használt, mint az SSH-1, bizonyos megvalósítások, például a libssh (v0.8.0+), az Lsh és a Dropbear csak az SSH-2-t támogatják.

Iteráció 1.99

Az RFC 4253 megkövetelte, hogy a 2.0-t, valamint a korábbi verziókat támogató SSH-kiszolgálók 2006 januárjában, jóval a 2.1-es verzió kifejlesztése után 1.99-es protokollverziót jelezzenek. Ez a verziószám a visszamenőleges kompatibilitás jelzésére szolgál, nem pedig egy korábbi szoftververzió jelzésére.

OSSH és OpenSSH

Amióta az eredeti SSH program utolsó, 1.2.12-es verzióját nyílt forráskódú licenc alatt terjesztették 1999-ben, a fejlesztők egy ingyenes szoftververzión dolgoznak. Ezt használták Björn Grönvall OSSH programjának alapjául. Nem sokkal ezután az OpenBSD csapata klónozta Grönvall munkáját, hogy létrehozza az OpenSSH-t, amely bekerült az OpenBSD 2.6-os kiadásába. Ebből a verzióból létrehoztak egy „hordozhatósági” ágat, hogy az OpenSSH-t különböző operációs rendszerekre vigyék át.

A legszélesebb körben használt SSH implementáció 2005-ben az OpenSSH volt, amely számos operációs rendszer disztribúciójának alapértelmezett verziója. Miután eltávolította az SSH-1 támogatást a kódbázisból az OpenSSH 7.6 kiadásban, az OpenSSH továbbra is frissítés alatt áll, és támogatja az SSH-2 protokollt. Eközben az OSSH már nem releváns.

mvc java

Felhasználások

A „josh” felhasználó „SSHed” a helyi „foo fighter” számítógépről a távoli „tengwar” gépre, hogy xeyes-t futtasson, példaként egy X11-es program SSH-n keresztüli alagutazására. Az emberek a Windows SSH PuTTY klienst használják az OpenWrt eléréséhez.

Az SSH egy olyan protokoll, amely számos rendszerrel működik, beleértve a Microsoft Windows-t és a legtöbb Unix változatot (Linux, BSD-k, beleértve az Apple macOS-ét és a Solaris). A következő alkalmazásoknak olyan képességekre lehet szükségük, amelyek kizárólagosak vagy kompatibilisek bizonyos SSH-kliensekkel vagy szerverekkel. Például jelenleg csak az OpenSSH-kiszolgáló és az SSH-protokoll kliens-megvalósítása lehetséges VPN létrehozásához.

• Egy távoli gazdagépen lévő shell elérése (a Telnet és az rlogin lecserélése)
• Magányos parancs végrehajtásához egy távoli gépen (az rsh helyettesítése)
• Egy távoli szerver automatizált (jelszó nélküli) bejelentkezési konfigurálásához (például OpenSSH használatával)
• Mivel egy teljesen működőképes titkosított VPN, ne feledje, hogy csak az OpenSSH-kliens és -kiszolgáló támogatja ezt a képességet.
• X átviteléhez távoli gazdagépről (lehetséges, hogy több köztes állomáson keresztül)
• A SOCKS protokollt támogató SSH-kliensek használatához az interneten titkosított proxykapcsolaton keresztül történő böngészéshez.
• Egy távoli kiszolgáló könyvtárának fájlrendszerként való biztonságos csatlakoztatásához SSHFS-t használó helyi gépen.
• Egy vagy több fent említett technológián keresztül az automatikus távoli szerver figyelésére és adminisztrációjára.
• SSH-kompatibilis mobil vagy beágyazott eszközök fejlesztéséhez.
• A fájlátviteli mechanizmusok védelme.

Fájlok átviteli módszerei

Számos fájlátviteli rendszer használ Secure Shell protokollokat, mint pl

• Az SSH-n keresztül a Secure Copy (SCP) fejlesztése az RCP protokollból történik.
• Az SCP-nél hatékonyabbnak vélt rsync gyakran SSH-kapcsolaton keresztül működik.
• Az FTP biztonságos alternatívája az SSH File Transfer Protocol (SFTP) (nem tévesztendő össze az SSH-n vagy FTPS-n keresztüli FTP-vel)
• A FISH-t, vagyis a shell protokollon keresztül átvitt fájlokat 1998-ban vezették be, és SSH-ból Unix shell-utasításokkal fejlesztették ki.
• Az Aspera, más néven Fast and Secure Protocol (FASP), SSH-t alkalmaz a parancsokhoz és az adatátvitelhez, az UDP-portokhoz.

Építészet

Három különálló összetevő alkotja az SSH protokoll réteges architektúráját:

• A TCP/IP átvitelvezérlő protokollját (TCP) általánosan az átviteli réteg (RFC 4253) használja, a 22-es porttal a szerver figyelő portjaként. Ez a réteg titkosítást, tömörítést, integritás-ellenőrzést, kezdeti kulcscserét és szerver hitelesítést valósít meg. Bár az egyes megvalósítások ennél többet is megengedhetnek, egy interfészt tesz elérhetővé a magasabb réteg számára az egyenként legfeljebb 32 768 bájt méretű egyszerű szöveges csomagok továbbítására és fogadására. Általában 1 GB adat átvitele vagy egy óra elteltével – amelyik előbb bekövetkezik – a szállítási réteg gondoskodik a kulcsok újbóli cseréjéről.
  
• Az ügyfelek hitelesítését a felhasználói hitelesítési réteg (RFC 4252) kezeli, amely számos hitelesítési technikát is kínál. Az ügyfélvezérelt hitelesítés azt jelenti, hogy az SSH-kliens, nem pedig a szerver, kérhet jelszót a felhasználótól. Csak az ügyfél hitelesítési kérései kapnak választ a szervertől. A következő felhasználó-hitelesítési technikákat gyakran használják:
  Jelszó, egy egyszerű jelszó-hitelesítési technika, amely magában foglalja a jelszó módosításának lehetőségét. Nem minden szoftver használja ezt a technikát.
• Általában legalább a DSA, ECDSA vagy RSA kulcspárokat támogatja nyilvános kulcs egy nyilvános kulcson alapuló hitelesítési technika. Más megvalósítások emellett X.509 tanúsítványokat is elfogadnak.
Billentyűzet-interaktív(RFC 4256) egy rugalmas technika, amelyben a szerver egy vagy több felszólítást ad az információbevitelhez, a kliens megjeleníti azokat, majd visszaküldi a kliens által beírt válaszokat. Egyes OpenSSH-beállítások segítségével hatékony jelszó-hitelesítést kínál a PAM során. a mögöttes gazdagép-hitelesítési szolgáltató, amely esetenként megakadályozhatja a bejelentkezést olyan klienssel, amely csak az egyszerű jelszó-hitelesítési technikát támogatja.
• Az SSH-munkamenetek egyszeri bejelentkezési funkciója a következőn keresztül érhető el GSSAPI hitelesítési technikák, amelyek bővíthető rendszert kínálnak az SSH-hitelesítés kezelésére olyan külső mechanizmusok használatával, mint a Kerberos 5 vagy az NTLM. Bár az OpenSSH rendelkezik funkcionális GSSAPI-megvalósítással, a kereskedelmi SSH-megvalósítások gyakran integrálják ezeket a technikákat a vállalatok számára.
• A kínált SSH-szolgáltatásokat meghatározó csatornák ötletét a kapcsolati réteg (RFC 4254) határozza meg. Egyetlenről több SSH-kapcsolatot is multiplexelhetünk. Mindkettő mindkét irányba továbbítja az adatokat. A csatornakérések egy adott csatornára jellemző sávon kívüli adatokat továbbítanak, például egy szerveroldali folyamat kilépési kódját vagy egy terminálablak méretváltozását. Ezenkívül a vételi ablak méretével minden csatorna szabályozza az áramlását. Az SSH-kliens globális kérést küld egy szerveroldali port továbbítására. A gyakori csatornatípusok a következők:
  • Shell SFTP, exec és terminál shellekhez (beleértve az SCP átviteleket is)
  • Közvetlen TCPIP a kliens és a szerver között továbbított kapcsolatokhoz.
  • A kiszolgálók között továbbított kapcsolatok a forwarded-tcpip használatával
  • A gazdagép legitimitásának megerősítése érdekében az SSHFP DNS-rekord (RFC 4255) felajánlja a nyilvános gazdagép-kulcs ujjlenyomatait.

Nyitott kialakításának köszönhetően az SSH-t a shell-rögzítés mellett sokféle feladatra használhatjuk, ami nagy sokoldalúságot biztosít.

Sebezhetőségek

SSH-1

A jelen protokollverzióban a CRC-32 által biztosított nem megfelelő adatintegritás-védelem miatt 1998-ban az SSH 1.5-ös biztonsági rését azonosították, amely lehetővé tette az anyagok illetéktelen beillesztését egy titkosított SSH-folyamba. A legtöbb megvalósításhoz hozzáadtak egy SSH Compensation Attack Detector néven ismert javítást. Ezen felülvizsgált megvalósítások közül több új egész szám túlcsordulási hibát tartalmazott, amely lehetővé tette a támadók számára, hogy tetszőleges kódot futtatjanak root vagy az SSH démon képességeivel.

2001 januárjában találtak egy hibát, amely lehetővé teszi a támadók számára, hogy módosítsák az IDEA-titkosított munkamenet utolsó blokkját. Ugyanebben a hónapban egy másik hibát is találtak, amely lehetővé tette, hogy egy szélhámos szerver átadja a kliens bejelentkezését egy másik szervernek.

java véletlenszerű matematikai véletlenszerű

A benne rejlő sebezhetőségek miatt az SSH-1-et általában elavultnak tekintik, és az SSH-1 tartalék kifejezetten eltávolításával kerülni kell. A legtöbb jelenlegi szerver és kliens támogatja az SSH-2-t.

Egyszerű szöveges helyreállítás a CBC-hez

2008 novemberében az SSH összes verziójában felfedeztek egy elméleti sebezhetőséget, amely lehetővé tette akár 32 bitnyi egyszerű szöveg lekérését a kor szabványos titkosítási módszerével, CBC-vel titkosított titkosított szöveg blokkból. A legegyszerűbb megoldás a CTR-re váltás, a számláló. módban, a CBC mód helyett, amely az SSH-t immunissá teszi a támadásokkal szemben.

Az NSA-t visszafejtéssel gyanúsítják

Edward Snowden bizalmas dokumentumokat a Der Spiegelnek 2014. december 28-án kiadta, és arra utal, hogy a Nemzetbiztonsági Ügynökség potenciálisan képes lesz dekódolni bizonyos SSH-kommunikációkat.