Biztonságos héj - Secure Shell

Az "SSH" átirányít ide. A többi felhasználást lásd: SSH (egyértelműsítés) .
Biztonságos Shell
Kommunikációs protokoll
Célja biztonságos kapcsolat, távoli CLI
Fejlesztő (k) Tatu Ylönen, Internet Engineering Task Force (IETF)
Bemutatott 1995
OSI réteg Alkalmazási réteg
Port (ok) 22
RFC (k) RFC 4250, RFC 4251, RFC 4252, RFC 4253, RFC 4254
Internet protokoll csomag
Alkalmazási réteg
Szállítási réteg
Internet réteg
Linkréteg

A Secure Shell ( SSH ) egy kriptográfiai hálózati protokoll a hálózati szolgáltatások biztonságos üzemeltetéséhez nem biztonságos hálózaton keresztül. A tipikus alkalmazások közé tartozik a távoli parancssor , a bejelentkezés és a távoli parancsfuttatás, de bármely hálózati szolgáltatás SSH-val védhető.

Az SSH biztonságos csatornát biztosít a nem biztonságos hálózaton, kliens -szerver architektúra használatával, egy SSH -ügyfélalkalmazás és egy SSH -kiszolgáló összekapcsolásával . A protokoll specifikáció két fő verziót különböztet meg, SSH-1 és SSH-2 néven. Az SSH szabványos TCP-portja 22. Az SSH-t általában Unix-szerű operációs rendszerek elérésére használják , de Microsoft Windows rendszeren is használható . A Windows 10 az OpenSSH -t használja alapértelmezett SSH -ügyfélként és SSH -kiszolgálóként .

SSH célja az volt, a helyett a Telnet és nem biztonságos távoli shell protokollokat, mint például a Berkeley rsh és a kapcsolódó rlogin és rexec protokollokat. Ezek a protokollok érzékeny információkat, nevezetesen jelszavakat , egyszerű szövegben küldenek , így érzékenyek lesznek a lehallgatásra és a csomag -elemzéssel történő nyilvánosságra hozatalra . Az SSH által használt titkosítás célja az adatok bizalmasságának és integritásának biztosítása egy nem biztonságos hálózaton, például az interneten keresztül .

Meghatározás

SSH nyilvános kulcsú titkosítás , hogy hitelesítse a távoli számítógéphez, és lehetővé teszi, hogy a felhasználó azonosítása, ha szükséges.

Az SSH többféle módon használható; az egyik az, hogy az automatikusan generált nyilvános-privát kulcspárokat egyszerűen titkosítja a hálózati kapcsolatot, majd jelszavas hitelesítést használ a bejelentkezéshez. Egy másik lehetőség, hogy manuálisan létrehozott nyilvános-magán kulcspárt használ a hitelesítés végrehajtásához, lehetővé téve a felhasználóknak vagy programoknak, hogy jelszó megadása nélkül jelentkezzenek be. Ebben a forgatókönyvben bárki előállíthat egy pár különböző kulcsot (nyilvános és privát). A nyilvános kulcsot minden olyan számítógépen elhelyezi, amelynek lehetővé kell tennie a hozzáférést a megfelelő privát kulcs tulajdonosához (a tulajdonos titokban tartja a privát kulcsot). Míg a hitelesítés a privát kulcson alapul, maga a kulcs soha nem kerül át a hálózaton keresztül a hitelesítés során. Az SSH csak azt ellenőrzi, hogy a nyilvános kulcsot kínáló személy rendelkezik -e a megfelelő privát kulccsal is. Az SSH minden verziójában fontos, hogy ellenőrizze az ismeretlen nyilvános kulcsokat , azaz társítsa a nyilvános kulcsokat identitásokkal , mielőtt elfogadja őket érvényesként. Ha a támadó nyilvános kulcsát elfogadja érvényesítés nélkül, akkor jogosulatlan támadó jogosult jogosult felhasználónak.

Hitelesítés: OpenSSH kulcskezelés

A Unix-szerű rendszerek, a lista az engedélyezett nyilvános kulcsokat jellemzően tárolva van a home könyvtárat a felhasználó, amely lehetővé tette, hogy jelentkezzen be távolról, a fájl ~ / .ssh / authorized_keys. Ezt a fájlt csak akkor tartja tiszteletben az SSH, ha a tulajdonoson és a rooton kívül más nem írhatja. Ha a nyilvános kulcs jelen van a távoli oldalon, és a hozzá tartozó privát kulcs a helyi végén, akkor a jelszó beírása már nem szükséges. A további biztonság érdekében azonban a magánkulcs zárolható egy jelszóval.

A privát kulcsot szabványos helyeken is meg lehet keresni, és teljes útvonala parancssori beállításként adható meg (az -sh opció az ssh esetében). Az ssh-keygen segédprogram előállítja a nyilvános és a privát kulcsokat, mindig párban.

Az SSH támogatja a jelszóalapú hitelesítést is, amelyet automatikusan generált kulcsok titkosítanak. Ebben az esetben a támadó utánozhatja a jogos szerver oldalt, kérheti a jelszót, és megszerezheti ( emberközép támadás ). Ez azonban csak akkor lehetséges, ha a két fél még soha nem hitelesített, mivel az SSH megjegyzi azt a kulcsot, amelyet a szerveroldal korábban használt. Az SSH ügyfél figyelmeztetést küld, mielőtt elfogadja egy új, korábban ismeretlen szerver kulcsát. A jelszó -hitelesítés a szerver oldaláról letiltható.

Használat

Az SSH -t általában távoli gépre való bejelentkezéshez és parancsok végrehajtásához használják, de támogatja az alagútkezelést , a TCP -portok továbbítását és az X11 -kapcsolatokat is; fájlokat tud átvinni a hozzájuk tartozó SSH fájlátviteli (SFTP) vagy biztonságos másolási (SCP) protokollok használatával. Az SSH az ügyfél -szerver modellt használja .

Az SSH kliens programot általában a távoli kapcsolatokat elfogadó SSH démonhoz való kapcsolatok létrehozására használják . Mindkettő általában jelen van a legtöbb modern operációs rendszeren , beleértve a macOS -t , a Linux , OpenBSD , FreeBSD , NetBSD , Solaris és OpenVMS legtöbb disztribúcióját . Nevezetesen, a Windows 1070 -es verzióját megelőző Windows -verziók alapértelmezés szerint nem tartalmazzák az SSH -t. Saját tulajdonú , ingyenes és nyílt forráskódú (pl. PuTTY és a Cygwin részét képező OpenSSH verziója ) változatos összetettségű és teljességű változatok léteznek. A UNIX-szerű rendszerek fájlkezelői (pl. Konqueror ) a FISH protokoll segítségével osztott ablaktáblás GUI-t biztosíthatnak húzással. A nyílt forráskódú Windows program, a WinSCP hasonló fájlkezelési (szinkronizálási, másolási, távoli törlési) képességeket biztosít a PuTTY segítségével háttérként. Mind a WinSCP, mind a PuTTY csomagolva közvetlenül USB -meghajtóról futtatható, anélkül, hogy telepíteni kellene az ügyfélgépre. Az SSH -kiszolgáló beállítása a Windows rendszerben általában egy funkció engedélyezését jelenti a Beállítások alkalmazásban. A Windows 10 1709 -es verziójában az OpenSSH hivatalos Win32 portja érhető el.

Az SSH fontos szerepet játszik a felhőalapú számítástechnikában a csatlakozási problémák megoldásában, elkerülve a felhőalapú virtuális gépek közvetlen interneten történő közzétételével kapcsolatos biztonsági problémákat. Az SSH -alagút biztonságos utat biztosíthat az interneten keresztül, tűzfalon keresztül egy virtuális gépig.

Az IANA kiosztotta TCP port 22. UDP port 22 és SCTP port 22 ezt a protokollt. Az IANA már 2001-ben felsorolta az SSH-kiszolgálók szabványos TCP-22-es portját az egyik jól ismert portként . Az SSH-t SCTP-vel is lehet futtatni, nem pedig TCP-vel, mint kapcsolatorientált szállítási réteg protokollt.

Történelem és fejlődés

1.x verzió

1995-ben Tatu Ylönen , a finn Helsinki Műszaki Egyetem kutatója megtervezte a protokoll első változatát (ma SSH-1 néven ), amelyet jelszavas szaggatási támadás indított egyetemi hálózatában . Az SSH célja az volt, hogy lecserélje a korábbi rlogin , TELNET , FTP és rsh protokollokat, amelyek nem biztosítottak erős hitelesítést és nem garantálták a titoktartást. Ylönen kiadta végrehajtás ral 1995 júliusában, és az eszköz gyorsan szerzett népszerűségét. 1995 vége felé az SSH felhasználói bázisa ötven országban 20 000 felhasználóra nőtt.

1995 decemberében Ylönen megalapította az SSH Communications Security -t az SSH forgalmazása és fejlesztése érdekében. Az SSH szoftver eredeti verziója különféle ingyenes szoftvereket használt , mint például a GNU libgmp , de az SSH Communications Security által kiadott későbbi verziók egyre inkább szabadalmaztatott szoftverekké fejlődtek .

A becslések szerint 2000 -re a felhasználók száma 2 millióra nőtt.

2.x verzió

A "Secsh" volt a hivatalos Internet Engineering Task Force (IETF) neve az SSET protokoll 2. verziójáért felelős IETF munkacsoportnak. 2006-ban a protokoll felülvizsgált változatát, az SSH-2 szabványt fogadták el. Ez a verzió nem kompatibilis az SSH-1-el. Az SSH-2 biztonsági és funkciófejlesztéseket is tartalmaz az SSH-1-hez képest. A jobb biztonságot például a Diffie – Hellman kulcscsere és az erős hitelesség -ellenőrzés biztosítja az üzenet hitelesítési kódokon keresztül . Az SSH-2 új funkciói közé tartozik az a képesség, hogy tetszőleges számú shell munkamenetet futtasson egyetlen SSH kapcsolaton keresztül. Az SSH-2 fölénye és népszerűsége miatt az SSH-1-hez képest néhány megvalósítás, például a libssh (v0.8.0+), az Lsh és a Dropbear csak az SSH-2 protokollt támogatja.

Verzió 1.99

2006 januárjában, jóval a 2.1 -es verzió létrehozása után, az RFC 4253 meghatározta, hogy az SSH -kiszolgálónak, amely támogatja az SSH 2.0 -s és korábbi verzióit, 1,99 -nek kell azonosítania a protokollját. Ez nem egy tényleges verzió, hanem egy módszer a visszamenőleges kompatibilitás azonosítására .

OpenSSH és OSSH

1999 -ben a fejlesztők, akik azt akarták, hogy elérhető legyen egy ingyenes szoftververzió, visszatértek az eredeti SSH program 1.2.12 -es verziójához, amely utoljára nyílt forráskódú licenc alatt jelent meg . Ezt követően Björn Grönvall OSSH -ját fejlesztették ki ebből a kódbázisból. Röviddel ezután az OpenBSD fejlesztői elágazták Grönvall kódját, és alapos munkát végeztek rajta, megalkotva az OpenSSH -t , amelyet az OpenBSD 2.6 -os kiadásával szállítottak. Ebből a verzióból egy "hordozhatósági" ágat alakítottak ki az OpenSSH más operációs rendszerekre történő portolására.

2005 -től az OpenSSH volt az egyetlen legnépszerűbb SSH -implementáció, alapértelmezés szerint számos operációs rendszerben. Az OSSH időközben elavult. Az OpenSSH továbbra is karbantartott, és támogatja az SSH-2 protokollt, mivel az OpenSSH 7.6 kiadással megszüntette az SSH-1 támogatást a kódbázisból.

Felhasználások

Példa egy X11 alkalmazás alagútjainak SSH -n keresztüli alagútjára: a "josh" felhasználó "SSHed" -et kapott a "foofighter" helyi gépről a "tengwar" távoli gépre a xeyes futtatásához .
Bejelentkezés az OpenWrt -be SSH -n keresztül a Windows rendszeren futó PuTTY használatával .

Az SSH egy protokoll, amely számos alkalmazáshoz használható számos platformon, beleértve a legtöbb Unix változatot ( Linux , a BSD -k, beleértve az Apple macOS -ját és a Solaris -t), valamint a Microsoft Windows . Az alábbi alkalmazások némelyike ​​olyan funkciókat igényelhet, amelyek csak bizonyos SSH ügyfelekkel vagy kiszolgálókkal állnak rendelkezésre vagy kompatibilisek. Például az SSH protokoll használata VPN megvalósításához lehetséges, de jelenleg csak az OpenSSH szerver és az ügyfél megvalósításával.

  • Belépés egy távoli gazdagép héjába (a Telnet és az rlogin cseréje )
  • Egyetlen parancs végrehajtásához távoli gépen (az rsh helyett )
  • Automatikus (jelszó nélküli) bejelentkezés beállításához egy távoli szerverre (például OpenSSH használatával )
  • Az rsync kombinációjával hatékonyan és biztonságosan készíthet biztonsági másolatot, másolhat és tükrözhet fájlokat
  • Mert továbbítása egy kikötő
  • A tunneling (nem tévesztendő össze a VPN , amely útvonalak csomagokat különböző hálózatok közötti, vagy hidak két szórási tartományok egyetlen).
  • Teljes értékű titkosított VPN-ként való használatra. Ne feledje, hogy ezt a funkciót csak az OpenSSH szerver és kliens támogatja.
  • X továbbítására távoli gazdagépről (lehetséges több köztes gazdagépen keresztül)
  • A weben való böngészéshez titkosított proxykapcsolaton keresztül SSH ügyfelekkel, amelyek támogatják a SOCKS protokollt .
  • Egy könyvtár biztonságos telepítéséhez egy távoli szerverre fájlrendszerként egy helyi számítógépen SSHFS használatával .
  • A szerverek automatikus távfelügyeletéhez és felügyeletéhez a fent tárgyalt egy vagy több mechanizmuson keresztül.
  • Fejlesztésre SSH -t támogató mobil vagy beágyazott eszközön.
  • A fájlátviteli protokollok védelmére.

Fájlátviteli protokollok

A Secure Shell protokollokat több fájlátviteli mechanizmusban használják.

Építészet

Az SSH-2 bináris csomag diagramja.

Az SSH-2 protokoll belső architektúrája (az RFC 4251-ben meghatározott) jól elkülönített rétegekkel rendelkezik, nevezetesen:

  • A szállítási réteg (RFC 4253), amely általában a TCP/IP -n fut. Ez a réteg kezeli a kezdeti kulcscserét, valamint a szerver hitelesítését, és beállítja a titkosítást, a tömörítést és az integritás -ellenőrzést. A felső rétegnek egy felületet tesz közzé egyszerű szöveges csomagok küldésére és fogadására, egyenként 32 768 bájtos méretben (a megvalósítás ennél többet is megengedhet). A szállítási réteg gondoskodik a kulcsok cseréjéről is, általában 1 GB adatátvitel vagy 1 óra elteltével, attól függően, hogy melyik következik be előbb.
  • A felhasználói hitelesítési réteg (RFC 4252). Ez a réteg kezeli az ügyfél -hitelesítést, és számos hitelesítési módszert biztosít. A hitelesítés ügyfélvezérelt : ha a rendszer jelszót kér, akkor az SSH-ügyfél kérése lehet, nem a szerver. A szerver csupán válaszol az ügyfél hitelesítési kéréseire. A széles körben használt felhasználói hitelesítési módszerek a következők:
    • jelszó : egyszerű jelszó -hitelesítési módszer, beleértve a jelszó megváltoztatását lehetővé tevő lehetőséget. Nem minden program valósítja meg ezt a módszert.
    • publickey : nyilvános kulcson alapuló hitelesítési módszer, amely általában legalább DSA , ECDSA vagy RSA kulcspárokat támogat, más megvalósítások pedig szintén támogatják az X.509 tanúsítványokat.
    • interaktív billentyűzet (RFC 4256): sokoldalú módszer, amikor a szerver egy vagy több üzenetet küld az adatok megadására, és a kliens megjeleníti azokat, és visszaküldi a felhasználó által begépelt válaszokat. Használják fel, hogy egyszeri jelszó hitelesítés, például S / Key vagy SecurID . Ezt néhány OpenSSH-konfiguráció használja, amikor a PAM az alapul szolgáló hoszt-hitelesítési szolgáltató, amely hatékonyan biztosítja a jelszó-hitelesítést, néha pedig ahhoz, hogy nem tud bejelentkezni olyan ügyféllel, amely csak a sima jelszavas hitelesítési módszert támogatja .
    • GSSAPI hitelesítési módszerek, amelyek kiterjeszthető sémát biztosítanak az SSH hitelesítéshez külső mechanizmusok, például Kerberos 5 vagy NTLM használatával , és egyszeri bejelentkezési lehetőséget biztosítanak az SSH munkamenetekhez. Ezeket a módszereket általában kereskedelmi SSH implementációk valósítják meg, amelyeket szervezetekben használnak, bár az OpenSSH rendelkezik működő GSSAPI implementációval.
  • A csatlakozási réteg (RFC 4254). Ez a réteg határozza meg a csatornák, csatornakérések és globális kérések fogalmát, amelyek segítségével az SSH szolgáltatásokat nyújtják. Egy SSH -kapcsolat egyszerre több csatornát is fogadhat, mindegyik mindkét irányban továbbítja az adatokat. A csatornakérelmek a sávon kívüli csatornaspecifikus adatok, például a terminálablak megváltozott mérete vagy a kiszolgálóoldali folyamat kilépési kódjának továbbítására szolgálnak. Ezenkívül minden csatorna saját folyásszabályozást hajt végre a fogadóablak méretével. Az SSH kliens globális kéréssel továbbítja a szerveroldali portot. A standard csatornatípusok a következők:
    • héj terminálhéjakhoz, SFTP és végrehajtási kérésekhez (beleértve az SCP átvitelt)
    • direct-tcpip az ügyfél-kiszolgáló továbbított kapcsolatokhoz
    • forwarded-tcpip a kiszolgáló-ügyfél továbbított kapcsolatokhoz
  • Az SSHFP DNS -rekord (RFC 4255) biztosítja a nyilvános gazdakulcs ujjlenyomatát, hogy segítsen a gazdagép hitelességének ellenőrzésében.

Ez a nyitott architektúra jelentős rugalmasságot biztosít, lehetővé téve az SSH különböző célokra történő használatát a biztonságos héjon kívül. A szállítási réteg funkcionalitása önmagában összehasonlítható a Transport Layer Security (TLS) biztonsággal ; a felhasználói hitelesítési réteg nagy mértékben bővíthető egyéni hitelesítési módszerekkel; és a kapcsolódási réteg lehetővé teszi sok másodlagos munkamenet multiplexelését egyetlen SSH -kapcsolatba, ez a funkció a BEEP -hez hasonló, és nem érhető el a TLS -ben.

A népszerű tévhit ellenére az SSH nem a Telnet implementációja a Secure Sockets Layer (SSL) titkosítással .

Algoritmusok

Sebezhetőségek

SSH-1

1998-ban egy biztonsági rést írtak le az SSH 1.5-ben, amely lehetővé tette a tartalom jogosulatlan beillesztését egy titkosított SSH-adatfolyamba, mivel a protokoll ezen verziójában használt CRC-32 adatvédelmi integritás nem volt megfelelő . Az SSH kompenzációs támadásérzékelő néven ismert javítást a legtöbb megvalósításba bevezették. Sok ilyen frissített megvalósítás tartalmazott egy egész egész túlcsordulási biztonsági rést, amely lehetővé tette a támadók számára, hogy tetszőleges kódot futtassanak az SSH démon, általában root jogosultságaival.

2001 januárjában felfedeztek egy sebezhetőséget, 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 biztonsági rést fedeztek fel, amely lehetővé tette, hogy egy rosszindulatú szerver továbbítsa az ügyfél -hitelesítést egy másik szerverre.

Mivel az SSH-1 sajátos tervezési hibákkal rendelkezik, amelyek sebezhetővé teszik, most általában elavultnak tekintik, és el kell kerülni az SSH-1 tartalék explicit letiltásával. A legtöbb modern szerver és kliens támogatja az SSH-2-t.

CBC egyszerű szöveg helyreállítása

2008 novemberében egy elméleti sebezhetőséget fedeztek fel az SSH minden verziójában, amely lehetővé tette akár 32 bit egyszerű szöveg helyreállítását a titkosított szövegblokkból, amelyet akkoriban a szokásos alapértelmezett titkosítási mód, a CBC segítségével titkosítottak . A legegyszerűbb megoldás a CTR , számláló mód használata CBC mód helyett, mivel ez az SSH -t ellenáll a támadásnak.

Lehetséges biztonsági rések

2014. december 28 -án a Der Spiegel közzétette a bejelentő, Edward Snowden által kiszivárogtatott minősített információkat, amelyek azt sugallják, hogy a Nemzeti Biztonsági Ügynökség képes lehet az SSH -forgalom visszafejtésére. Az ilyen folyamathoz kapcsolódó technikai részleteket nem hozták nyilvánosságra. A CIA BothanSpy és Gyrfalcon hackelési eszközeinek 2017 -es elemzése azt sugallta, hogy maga az SSH protokoll nem sérült.

Szabványok dokumentációja

Az IETF "secsh" munkacsoport alábbi RFC- kiadványai az SSH-2 dokumentumot javasolják internetes szabványként .

  • RFC  4250 - A Secure Shell (SSH) protokollhoz rendelt számok
  • RFC  4251 - A Secure Shell (SSH) protokoll architektúra
  • RFC  4252 - A Secure Shell (SSH) hitelesítési protokoll
  • RFC  4253 - A Secure Shell (SSH) szállítási réteg protokoll
  • RFC  4254 - A Secure Shell (SSH) csatlakozási protokoll
  • RFC  4255 - DNS használata a Secure Shell (SSH) kulcs ujjlenyomatának biztonságos közzétételéhez
  • RFC  4256 - Generic Message Exchange hitelesítés a Secure Shell Protocol (SSH) számára
  • RFC  4335 - The Secure Shell (SSH) Session Channel Break kiterjesztés
  • RFC  4344 - A Secure Shell (SSH) szállítási réteg titkosítási módjai
  • RFC  4345 - Továbbfejlesztett Arcfour módok a Secure Shell (SSH) szállítási réteg protokollhoz

Később a következő kiadványok módosították és bővítették.

  • RFC  4419- Diffie-Hellman Group Exchange for Secure Shell (SSH) Transport Layer Protocol (2006. március)
  • RFC  4432 - RSA Key Exchange for Secure Shell (SSH) Transport Layer Protocol (2006. március)
  • RFC  4462- Generic Security Service Application Program Interface (GSS-API) hitelesítés és kulcscsere a Secure Shell (SSH) protokollhoz (2006. május)
  • RFC  4716 - A Secure Shell (SSH) nyilvános kulcs fájlformátuma (2006. november)
  • RFC  4819 - Biztonságos Shell nyilvános kulcs alrendszer (2007. március)
  • RFC  5647 - AES Galois számláló mód a Secure Shell Transport Layer Protocol számára (2009. augusztus)
  • RFC  5656 - Elliptikus görbe algoritmus integrálása a Secure Shell szállítási rétegbe (2009. december)
  • RFC  6187 - X.509v3 tanúsítványok a biztonságos Shell hitelesítéshez (2011. március)
  • RFC  6239 - B Suite Suite Cryptographic Suites for Secure Shell (SSH) (2011. május)
  • RFC  6594- Az SHA-256 algoritmus használata RSA-val, digitális aláírási algoritmus (DSA) és elliptikus görbe DSA (ECDSA) az SSHFP erőforrásrekordokban (2012. április)
  • RFC  6668- SHA-2 adatintegritás-ellenőrzés a Secure Shell (SSH) szállítási réteg protokollhoz (2012. július)
  • RFC  7479 - Ed25519 SSHFP erőforrásrekordok (2015. március)
  • RFC  5592 - Secure Shell Transport Model for Simple Network Management Protocol (SNMP) (2009. június)
  • RFC  6242 - A NETCONF protokoll használata Secure Shell (SSH) protokollon keresztül (2011. június)
  • draft-gerhards-syslog-transport-ssh-00-SSH szállítási leképezés a SYSLOG számára (2006. július)
  • draft-ietf-secsh-filexfer-13-SSH File Transfer Protocol (2006. július)

Ezenkívül az OpenSSH projekt számos szállítói protokoll specifikációt/kiterjesztést tartalmaz:

Lásd még

Hivatkozások

További irodalom

Külső linkek