A Telnet az alapvető UNIX OS protokoll, amely a terminálfelhasználók számára hozzáférést biztosít egy távoli számítógéphez.

Kezdetben a terminál egy írógép típusú eszköz volt, amelyen a kezelő (felhasználó) parancsokat gépelt és megfigyelte az eredményeket. A terminált később monitorra és billentyűzetre osztották.

Alapértelmezés szerint a Telnet a 23-as portot használja. A kiszolgáló résznek futnia kell a távoli számítógépen, a kliens résznek pedig a felhasználó számítógépén. Az ügyfélprogramnak ugyanaz a neve - telnet, és lehetővé teszi a paraméterek bevitelét a parancssorból. Ezek a lehetőségek a következők:

Szervernév (IP-cím) és portszám

Szöveges terminál típusa

Felhasználónév

Kapcsolati napló neve

A billentyűzet egyes funkcióbillentyűinek működésének meghatározása stb.

Szintaxis parancs sor a telnet szoftveres megvalósításától függ, és ebből a szempontból a telnet szolgáltatásnak vagy szolgáltatásnak tekinthető.

A telnet protokoll működése biztosítja a felhasználó által külön csomagban beírt karakterek TCP protokoll használatával a szerverre (távoli számítógépre) történő továbbítását. Ha a visszhang engedélyezve van, a szerver visszaküldi a karaktert a felhasználó monitorának. A szerveren futó programok végrehajtásának eredményeit már blokkokban továbbítják. A felhasználói jogok és terminálképességek korlátain belül a telnet teljes hozzáférést biztosít a szerverprogramokhoz és fájlokhoz. Amikor a hitelesítési folyamat során létrejön a kapcsolat, a felhasználónév és a jelszó karakterei tiszta szöveggel kerülnek továbbításra, ami rendkívül veszélyessé teszi a telnet használatát.

Az alkalmazásterminál-protokollok (pl. telnet) biztonságának növelésére a legnépszerűbb módszer az SSH (Secure SHell) protokoll, amely alapértelmezés szerint a 22-es portot használja. A telnethez hasonlóan az SSH szerver része a távoli számítógépen, a kliens része pedig a felhasználói számítógépen indul el. A kapcsolat létrejötte után minden adat titkosított formában kerül továbbításra, és az összes alkalmazásprotokoll-adat alagútba kerül ezen a biztonságos kapcsolaton keresztül, amint az a 3.5.3.1. ábrán látható.

A telnet használata előtt a távoli számítógép és a felhasználó számítógépe biztonságos kapcsolatot létesít a 22-es porton (feltételezzük, hogy a kriptográfiai jelszavak már az SSH használata előtt meghatározásra kerültek a kliens és a szerver részeken). A telnet hívásakor a 23-as port megnyílik, de az átvitt csomagokat az SSH kliens elfogja, titkosítja és biztonságos csatornán továbbítja. Az SSH szerver dekódolja az adatokat, és elküldi a 23-as porton lévő telnet szervernek. A szerver válasza fordított sorrendben kerül továbbításra. A felhasználó nem érzi az SSH protokoll működését, és úgy működik, mint egy normál telnet kliens a 23-as porton.

E-mail protokollok

Az elektronikus levelezés (e-mail) az egyik legrégebbi és legelterjedtebb hálózati szolgáltatás, amely mind a helyi, mind a globális hálózatokban népszerű.

Rendszer Email 1982-ben jelent meg az Internet őse, az ARPANET szolgáltatásaként. Ez a rendszer jelentősen eltért a CCITT által elfogadott X.400-as ajánlássorozattól. Az X.400-as ajánlások összetettsége és átgondolatlan természete olyan ritka esethez vezetett a hálózati technológiában, amikor a kezdeményezés fejlesztése megnyerte a nemzetközi szabványt. Az X.400-ra válaszoló e-mail szolgáltatásokat nem használták széles körben, és nagyobb tudományos érdeklődésre tartanak számot.

Az elektronikus levél, akárcsak a hagyományos levél, tartalmaz egy borítékot a kézbesítéshez szükséges információkkal, egy fejlécet a címzett általi automatizált feldolgozáshoz hasznos adatokkal, valamint magát az üzenetet.

A boríték és a fejléc formalizált mezőkkel rendelkezik. Ezek közül a legfontosabbak (a küldőnek kötelezően kitöltendő mezők vastagon szedve):

Ezután: - a címzett(ek) címe(i) a formátumban postafiók_neve@mailszerver_neve

Сс: - (másolat) további címzett(ek) címe(i)

Titkos másolat: - (vak másolat) a címzett(ek) titkos címe(i) nem jelentették másoknak

Feladó: - email küldő címe

Fogadott: - egy mező, ahol az egyes csomópontok átadásakor hozzáadódik a csomópont neve, a beérkezés dátuma és időpontja

Return-Path: - a levél útjának csomópontjainak neve

Dátum: - az e-mail elküldésének dátuma és időpontja

Válaszcím: - cím, amelyre válaszolni kell

Üzenetazonosító: - egyedi üzenetazonosító (hivatkozásokhoz)

In-Reply-id: - annak az üzenetnek az azonosítója, amelyre a választ adják

Tárgy: - e-mail tárgya

Az üzenet törzse legfeljebb 1000 (legfeljebb 78 ajánlott) ASCII (amerikai szabványos információcsere kód) karakterből álló sztring, azaz 7 bites számok, amelyek a latin ábécé betűit, írásjeleket és számokat képviselnek (ezek népszerűek). reprezentáció a "kódolás" kifejezés). A nemzeti kódolások szimbólumai (például cirill karakterek), a bináris fájlok (például hang- vagy videoinformációkkal) stb. a MIME (Multipurpose Internet Mail Extension) egyezménynek megfelelően jelennek meg, amely mező jelzi a kódolási módot ( például Base64 – lásd a 3.5.2. bekezdést).

Az e-mailek titkosságának biztosításának alapvető módja annak kriptográfiai védelme. A legnépszerűbb rendszer a PGP (Pretty Good Privacy). Ezt a rendszert Phil Zimmerman javasolta, és számos titkosítási algoritmust használ (RSA, IDEA, MD5).

Egy másik rendszer az úgynevezett PEM (Privacy Enhanced Mail – fokozott titkosságú levelek), és abban különbözik a PGP-től, hogy kommunikálni kell a kulcshitelesítési hatóságokkal, alacsonyabb szintű a védelem (a PGP rendszerben történő adattitkosításhoz a kulcsok 128 bitesek, és a PEM rendszerben - csak 56 bit) , de teljes mértékben megfelel az ITU-T ajánlásainak (X.400 és X.509).

Az e-mail protokollokat jelentős változatosság jellemzi a márkás, az adott gyártó cégek szoftvertermékeihez megfelelőtől az általánosan elismert protokollokig. Az e-mail rendszerek protokolljairól beszélünk, és nem a HTTP protokollon alapuló levelezési szolgáltatások emulálásának általános rendszereiről (lásd például: www. mail. ru).

Az e-mail protokollok a következők:

Az SMTP (Simple Mail Transfer Protocol – egyszerű e-mail protokoll) egy protokoll, amelyet a csomópontok közötti levélváltásra és a levelek küldésére használnak egy klienstől a levelezőszerverhez. Alapértelmezés szerint a protokoll a 25-ös portot használja.

POP3 (Post Office Protocol v.3 – e-mail protokoll 3-as verzió) – a levelek ügyfél általi fogadására szolgáló protokoll. Alapértelmezés szerint a protokoll a 110-es portot használja.

Az IMAP v4 (Internet Message Access Protocol v.4 – protokoll az e-mailek interaktív eléréséhez, 4-es verzió) a POP3-hoz hasonló protokoll, de lehetővé teszi az ügyfél számára, hogy a leveleket magán a levelezőszerveren tárolja és dolgozza fel. Alapértelmezés szerint a protokoll az 585-ös portot használja

SMNP protokoll

Az SNMP-t (Simple Network Management Protocol) eredetileg az útválasztók kezelésére fejlesztették ki, de azóta minden hálózati eszközre kiterjesztették (alapértelmezés szerint a 161/162-es portok). Jelenleg a protokoll 2. verziója (1999) az irányadó.

A protokoll kliens-szerver elven épül (a kliens programnak futnia kell a felügyelt hálózati eszközön), és tartalmazza a felügyeleti protokollt (a felügyelt és a kezelő csomópontok közötti interakció), az ASN.1 nyelvet (Abstract Syntax Notation v.1 - absztrakt szintaktikai jelölések 1. verziója) az irányítási modell és maga a MIB (Management Information Base) irányítási modell leírása. A protokoll elterjedését hátráltatja az alacsony biztonság és az UDP protokoll használatára való összpontosítás, ami a DNS üzenetek esetleges elvesztéséhez vezethet.

A nevek feloldásának feladata egy csomópont IP-címének meghatározása a szimbolikus nevéből, és a szimbolikus név meghatározása egy adott IP-címből.

Történelmileg az első, de még mindig érvényes névfeloldási mechanizmus a szimbolikus nevek és IP-címek közötti megfelelési táblázat közvetlen beállításához kapcsolódik a hosts/lmhosts fájlban (az első fájlt a UNIX/Linux és néhány más operációs rendszer használja (OS), a második pedig a Microsoft OS-től). Mindkét fájl szöveges, formátumai és kulcsai az MS Windows rendszerben azonos nevű fájlokban találhatók meg a kiterjesztéssel. sam (minta). Nyilvánvaló, hogy minden nagy hálózatnál nem lehet teljesen megoldani a problémát ilyen módon, bár a fő szerverekről, útválasztókról, átjárókról stb. vonatkozó információk beírása ezekbe a fájlokba nagyon hatékony a számítógép indításának felgyorsítása érdekében. hálózati környezet.

Egy másik meglehetősen népszerű névfeloldási módszer a NetBIOS (Network Basic Input/Output System) használata TCP/IP-n keresztül. Ezt a rendszert a Microsoft és az IBM közösen fejlesztette ki az 1980-as években az operációs rendszer hálózati I/O szolgáltatásaként. Windows rendszerek. Később a hálózati erőforrásokhoz való felhasználói hozzáférés megvalósításához a NetBEUI (NetBIOS Extended User Interface) protokollt fejlesztették ki főként. hálózati protokoll Windows for Workgroups és NT rendszeren. Végül a TCP/IP-verem mindenütt jelenléte miatt a Microsoft kénytelen volt kiadni egy NetBIOS-megvalósítást, amely IP-t használ a szükséges adatok átviteléhez (NetBIOS TCP/IP-n keresztül). A NetBIOS továbbra is támogatott a Windows 2000/NT/XP rendszerben, bár nem a hálózati erőforrások elérésének fő mechanizmusaként. A NetBIOS hasznos kis, peer-to-peer hálózatokhoz.

Kezdetben a NetBIOS hálózat minden csomópontja rendelkezik egy szimbolikus névvel (legfeljebb 15 karakter), egy erőforrás-azonosítóval (16. karakter), amely jelzi a csomópont szerepét (fájlszerver, nyomtatószerver, munkaállomás stb.). A "tiszta" NetBIOS csak kis hálózatokhoz használható, és "nem irányíthatónak" minősül, mert -

az elnevezési rendszer nem teszi lehetővé a hálózat azonosítását

a broadcast kéréseket széles körben használják a hálózati csomópontokkal kapcsolatos információk megszerzésére és frissítésére (a legtöbb útválasztó nem engedélyezi a szórási kéréseket)

E hiányosságok kiküszöbölésére a Microsoft felajánlotta a WINS szolgáltatást (Windows Internet Name Service - windows szerviz Internet nevek) a NetBIOS névszervereken alapul. Megjegyzendő, hogy az internet említése ellenére a WINS-t ebben nem használják globális hálózat.

A NetBIOS első hátrányát a WINS-ben a hálózat közösségi nevének bevezetésével oldják meg, a másodikat pedig az, hogy a névfeloldási lekérdezések meghatározott WINS-kiszolgálókhoz szólnak. A szolgáltatás instabilitása, az adminisztrációs nehézségek és a globális interneten való használat nehézségei mára arra kényszerítették a Microsoftot, hogy átálljon a teljes DNS-támogatásra.

A DNS (Domain Name System – tartománynévrendszer) az azonos nevű alkalmazásprotokoll használatával valósul meg, amely alapértelmezés szerint az 53-as portot használja. A DNS rendszert a UNIX operációs rendszeren belül fejlesztették ki, és a megfelelő DNS-t használó szolgáltatásnak ugyanaz a rövidítése, de a Domain Name Service rövidítése.

A DNS-ben lévő nevek hierarchikusan, fordított fa formájában épülnek fel. A legfelső szintű domainek (rootok) a szakmai elv szerint (. com - trade, . gov - state, . net - network stb. csomópontok) vagy nemzeti (. ru - orosz, . fi - finn, . fr - francia stb. d.). A UNIX operációs rendszert az USA-ban fejlesztették ki, és természetesen feltételezték, hogy minden csomópont ott található. Most például dupla domain neveket láthat. com. tw - kereskedelmi tajvani.

Minden domain tartalmaz egy aldomaint, melynek neve a bal oldalon van hozzáadva, és ponttal elválasztva, stb. A bejegyzés a bal oldali gazdagépnév hozzáadásával ér véget. Az egyes tartományok, aldomainek vagy gazdagépek neve nem haladhatja meg a 63 karaktert, a teljes név pedig nem haladhatja meg a 255 karaktert. A nevek hagyományosan latin ábécében, számokban és kötőjelekben használatosak (a _ jel nem megengedett), de elvileg cirill betűs névvel is lehet domaint regisztrálni, de ennek jelentése problematikus.

A tetszőleges tartományban regisztrált aldomainek/gazdagépek nevéről és azok IP-címéről szóló adatok a DNS-kiszolgálókon két táblázatban tárolódnak, amelyek egyúttal az átfedő tartomány nevét és címét is tartalmazzák. Az első táblázat szerint egy adott szimbolikus névhez digitális címet határoznak meg (közvetlen konverzió és ennek megfelelően az ún. "közvetlen zóna"), a második táblázatban pedig egy szimbolikus név található egy adott címen ( fordított átalakítás és "fordított zóna").

A megbízhatóság növelése érdekében minden tartománynak legalább 2 szerverrel kell rendelkeznie (elsődleges - elsődleges és másodlagos - tartalék), és ezeknek a szervereknek fizikailag különböző hálózatokban kell elhelyezkedniük, és nem lehetnek azokban a tartományokban, amelyek gazdagépnevét tartalmazzák.

A gyökértartományt több mint 10 DNS-kiszolgáló támogatja, amelyek IP-címei és nevei „be vannak kötve” a hálózati operációs rendszerbe. Az új nevek regisztrációját és a megfelelő IP-címek kiosztását a domain tulajdonosa végzi. Például domain regisztráció. ru a RosNIIROS gyártja, ahol a név regisztrálása és az IP-cím megszerzése körülbelül 50 dollárba, az éves címtámogatás pedig 10 dollárba kerül. A névtáblázat minden módosítása az elsődlegesen történik DNS szerver, a készenléti kiszolgálók csak a rekordjaikat frissítik az elsődleges szerver rekordjaihoz képest. A zóna replikációja (frissítése) megbízható TCP protokoll, míg a DNS-lekérdezésekügyfelek esetén az UDP protokollt használják. A névfeloldási folyamat felgyorsítása és a hálózat forgalmának csökkentése érdekében időnként úgynevezett DNS cache szervereket telepítenek, amelyek a gyakran használt neveket és címeket rögzítik A DNS szerver működési módja lehet rekurzív és nem rekurzív. Rekurzív mód esetén, ha lehetetlen megoldani egy DNS-lekérdezést, akkor ezt a lekérdezést egy speciálisan meghatározott másik DNS-kiszolgálóra (továbbító - továbbítók) továbbítják, amely visszaadja a kapott választ. Nem rekurzív módban - a kért csomópontra vonatkozó információk hiányában a rendszer felveszi a kapcsolatot a gyökér DNS-kiszolgálókkal, és tőlük a láncon lefelé, amíg válasz nem érkezik.

A NAT (Network Address Translation – hálózati címfordítás) az IP-címek átalakítását (helyettesítését) valósítja meg helyi hálózatok a globális internet külső IP-címeire. Az ilyen átalakítás szükségessége az IP-címek egy részének csak helyi hálózatokban történő használatára vonatkozó megállapodásból következik (lásd 3.2. pont), amely szerint a WAN routerek megsemmisítik az ezekkel a címekkel rendelkező csomagokat.

A NAT a hálózaton és részben az átviteli szinteken működik, és biztosítja a helyi hálózati csomópontok címeinek IP-csomagjaiban külső címekké történő fordítását. Az átalakítás úgy történik, hogy a belső csomópont címét a külső címre cseréljük. A cserélendő címek egy táblázatban tárolódnak, amely a csere visszafordítására szolgál válaszcsomag érkezésekor. Megjegyzendő, hogy az esetleges megkülönböztethetetlenség kiküszöbölése érdekében nemcsak az IP-cím konvertálása történik meg, hanem a PAT (Port Address Translation) portszám használatával is.

A címfordítás mellett a NAT csökkenti a globális hálózatok IP-címeinek szükségességét, mivel a helyi hálózat minden felhasználója egyetlen külső címen keresztül hozzáférhet a globális hálózati erőforrásokhoz.

A NAT nem az egyetlen módja annak, hogy csomagokat küldjünk a helyi hálózatról a globális hálózatra, a címfordítás alternatívája egy közvetítő szerver használata.

Az SSH (Secure Shell) egy hálózati protokoll távoli hozzáférés A, amely titkosítást és tömörítést használ a továbbított adatokhoz. Egyszerűen fogalmazva, ez egy nagyon hasznos és hatékony eszköz, amely lehetővé teszi a hitelesítést a rendszerben és a teljes körű munkát a helyi felhasználó, mivel sok kilométerre van egy futó géptől. Ezenkívül a telnettől és az rsh-től eltérően az SSH az összes forgalmat titkosítja, így minden továbbított információ bizalmas marad.

Tehát az ssh már telepítve van, és az ssh-daemon hozzáadódik az automatikus betöltéshez a rendszer indításakor. A következő paranccsal vezérelheti:

service ssh stop|start|restart

Ubuntun, vagy:

/etc/init.d/ssh (start|stop|reload|force-reload|restart|status)

Debianon vagy:

systemctl start|stop|indítsa újra az sshd.service fájlt

ArchLinuxban (a konfiguráció minden szerkesztése után újra kell indítani). A csomag tartalmaz egy klienst és egy szervert.

Próbáljuk ki működés közben! Először hozzon létre egy mappát ~/.ssh

mkdir ~/.ssh

Kulcsokat generál az adott szerver felhasználóhoz a következő paranccsal:

ssh-keygen (normál felhasználóként).

A generálás során beállíthat egy jelszót a kulcshoz (lehetőleg beállítva, és egy hosszú - akkor is, ha megkapja a kulcsot, de nem tudja a kulcshoz tartozó jelszót, a támadó nem tud bejelentkezni), vagy kihagyhatja az "Enter" megnyomásával - ebben az esetben a jelszó soha nem fog kérni. Ugyanazok a nyilvános és privát kulcsok jelentek meg a ~/.ssh mappában.

Keress egy másik gépet (még egy okostelefon is megteszi – Androidon vannak nagyszerű SSH-kliensek, mint a ConnectBot vagy a JuiceSSH), telepítsd rá az ssh-t, és csatlakozz a szerverhez a következő paranccsal:

ssh [e-mail védett]

Ha mindent helyesen csináltunk, akkor a rendszer kéri a felhasználó jelszavát, és a belépés után a rendszerében találja magát a parancssorból kitekintve.

Windowshoz egyébként vannak szerverek és ssh kliensek is.

Miután élveztük munkánk eredményét, térjünk át a még unalmasabb részre - a kliens/szerver beállítására.

Az ügyféloldali konfiguráció be van kapcsolva /etc/ssh/ssh_configés szerver - /etc/ssh/sshd_config. A legtöbb teljes útmutató A konfigurációhoz valószínűleg a man oldal - man ssh és man sshd_config, ezért javasoljuk, hogy olvassa el. És ebben a cikkben megvizsgáljuk a legszükségesebb dolgokat.

Beállítás

A szabványos ssh port a 22. Bármilyen nem szabványosra módosítható (nehezíti az esetleges feltörést a biztonság miatt az ismeretlenségen keresztül, vagy hogy felhívja a potenciális hackerek figyelmét :) - ehhez törölje a megjegyzést a sorból:

#22-es port

És adjon hozzá bármit 65535-ig (bizonyosodjon arról, hogy a port nem ütközik más szolgáltatásokkal a paranccsal #netstat -tupln | grep HALLGAT).

Most, amikor csatlakozik a szerverhez, a kliensnek a következő kulccsal kell írnia:

ssh -p [port]:

Alapértelmezés szerint a root hozzáférés engedélyezett. Nagyon kívánatos a korlátozása (és ehelyett a helyi felhasználó jogainak megfelelő elhatárolása sudo-val). Ehhez keresse meg a "PermitRootLogin" sort, és módosítsa az értéket "no"-ra. Módosíthatod "jelszó nélkül"-re is - ebben az esetben a root felhasználóként való bejelentkezés csak megbízható kulccsal rendelkező gépekről lesz engedélyezve.

Letilthatja a jelszavas hitelesítést, és csak kulcsokkal dolgozhat - keresse meg a "PasswordAuthentication" sort, és módosítsa az értéket "no"-ra. Minek? Ha valaki valóban hozzá akar férni a rendszeréhez, akkor vagy brutálisan kikényszerítheti a jelszót az engedélyezés során, vagy meghallgathatja és visszafejtheti a kapcsolatot. Ha letiltja a jelszavas hitelesítést, és hozzáadja például a munkahelyi laptopjának nyilvános kulcsát a ~/.ssh/authorized_keys fájlhoz a szerveren, akkor emlékeink szerint azonnal beengedünk minket a szerverre. De mi van akkor, ha valaki más gépén dolgozik, és sürgősen hozzá kell férnie az ssh szerverhez, de az nem enged be minket a várt módon? Ekkor nem tudja letiltani a jelszavas hitelesítést, hanem használja a fail2ban segédprogramot. Csak telepítse a tárolóból, majd alkalmazza az alapértelmezett beállításokat, és legalább megvédi az ssh-csatornát a brute-force támadásoktól. További információ a fail2ban-ról: http://putty.org.ru/articles/fail2ban-ssh.html.

Abban az esetben, ha a szerverén megvannak a kulcsok a nukleáris rakéták indításához, a következőket teheti:

PermitRootLogin nem - a root alatti bejelentkezés tilos.

PasswordAuthentication nem – belépés jelszó nélkül

Hozzunk létre egy hosszú kulcsot a távoli gépen (-t titkosítási_típus, -b bithossz):

ssh-keygen -t rsa -b 4096

Ugyanilyen összetett jelmondattal (recover elfelejtett jelszó, mellesleg lehetetlen. Megváltoztathatod az "ssh-keygen -p" paranccsal, de úgyis a régit fogják kérni). Helyezze át a távoli helyi gép nyilvános kulcsát a kiszolgáló ~/.ssh/authorized_keys mappájába, és íme, most már egyetlen gépről is elérheti a privát kulcs jelmondatával. Az SSH sok biztonsági konfiguráció beállítását teszi lehetővé, és ehhez nagyon sok specifikus beállítás van - olvassa el az emberben.

Két sshd_config beállítás ugyanazt a célt szolgálja:

BejelentkezésGraceTime- beállítja azt az időt, amely után a kapcsolat megszakad, ha a hitelesítés nem történik meg.

MaxAuthTries- beállítja az érvénytelen bejelentkezési kísérletek számát, amelyek elérésekor a kapcsolat megszakad.

MaxSessions- az egyidejű munkamenetek száma (ha a szerver az Öné) otthoni számítógép, amelyhez az egyetemről vagy a munkahelyéről fog csatlakozni, akkor ésszerű lenne az ülések számát egyre korlátozni - a visszautasított bejelentkezés ebben az esetben a paranoia fokozódását, új kulcsok generálását és megváltoztatását okozza. a jelszó). Ha azonban óvatos, akkor észreveheti, hogy minden bejelentkezéskor a kiszolgálóra megjelenik az „Utolsó bejelentkezés” sor. Ezen kívül hozzáadhat saját üdvözlő üzenetet - keresse meg a "Banner" sort, és a semmi helyett állítsa be a fájl elérési útját a bejelentkezéskor olvasható és megjelenített szöveggel.

Többek között csak bizonyos felhasználóknak engedélyezheti a bejelentkezést, vagy bizonyos felhasználók kivételével mindenki számára:

AllowUsers user1- csak a bejelentkezés engedélyezése user1.

DenyUsers user1- mindenkit engedélyez, kivéve user1-et.

És hasonló lehetőségek bizonyos csoportok elérésére - AllowGroups és DenyGroups.

Az X11 munkamenetet SSH-n keresztül is átviheti. Ehhez keresse meg a "ForwardX11" sort, és módosítsa az értéket "yes"-re.

Keressen egy hasonló sort a kliens konfigurációjában - /etc/ssh/ssh_config, és módosítsa "yes"-re.

Most csatlakoznia kell a szerverhez ssh-n keresztül a -X argumentummal:

ssh -X [e-mail védett]>

Csatlakozáskor azonnal elindíthatja az alkalmazást:

ssh -X [e-mail védett]"Függelék"

Így néz ki egy futó GIMP egy ssh munkamenetben:

Vagy lekérheti a kimenetet egy gyanútlan felhasználó laptopjának webkamerájáról :)

A számítások közvetlenül a szerveren történnek, és a kimenet átkerül a kliens gépre (azaz akkor is, ha magának a szervernek nincs X11, grafikus alkalmazások le lehet renderelni a távoli gépen). Ez a séma meglehetősen lassan működik (ne felejtsük el, hogy az összes forgalom dinamikusan titkosított) - de ez a funkció nagyon hasznos.

SSH-munkameneten keresztül is másolhat fájlokat – erre van egy egyszerű "scp" segédprogram. A fájlokat közvetlenül a munkamenetben viheti át a szerverről a kliensre:

scp [e-mail védett]:/elérési út/fájl/szerveren/hova/mentés/helyi/gépre

És a klienstől a szerverig:

scp elérési út/fájlhoz/klienshez [e-mail védett]:/elérési út/szerverhez

Ez nagyon kényelmes, ha szöveget vagy fényképet kell másolnia, de mi van akkor, ha sok fájllal kell dolgoznia? Ehhez van a legkényelmesebb dolog - az sshfs (a legtöbb * nix rendszer tárolójába telepíthető).

Csak állítsa be az elérési utat ugyanúgy, mint az scp:

sshfs [e-mail védett]:/home/user /mnt/

A szerver /home/user mappája pedig megjelenik a helyi gép /mnt csatolási pontján!

A leválasztás az umount segítségével történik.

És végül beszéljünk egy kevéssé ismert funkcióról. Ha létrehoz egy fájlt /.ssh/configés töltsd ki így:

házigazda [név]

gazdagépnév

Felhasználó [szerver felhasználónév]

kívánt opciókat

tetszik

ElőreX11 igen

30000 port

Ezután bejelentkezhetünk:

ssh [név]

ssh -X -p 30000 [e-mail védett]

És az összes opció automatikusan megjelenik. Így egy adott szerveren végzett gyakori hitelesítéssel néhány pillanat alatt leegyszerűsíti ezt a folyamatot.

Nos, mindent (és még többet) leírtunk, amit az SSH-ról tudni kell a mindennapi használathoz – megtanultuk a kulcshitelesítés használatát, a brute force megvédte a szervert a feltörésektől, és általában befoltozta a legtöbb lehetséges lyukat. Valójában az SSH sok más dolgot is tud végezni - például alagútkezelést és porttovábbítást egy ssh-munkameneten keresztül, de nem valószínű, hogy Ön, mint a leghétköznapibb felhasználó, valaha is használni fogja ezt. További források

A könyv részletesen tárgyalja a hálózati szolgáltatások beállításait, amelyek lehetővé teszik a szükséges konfigurációval és funkcionalitással rendelkező szerver létrehozását a Linux OS alapján. Bármilyen típusú kiszolgálót beállíthat: a LAN-kiszolgálótól az Internet-kiszolgálóig és a távelérési kiszolgálóig. A Linux adminisztrációja részletesen le van írva.

Az anyag bemutatása a Red Hat és Mandrake disztribúciókra épül. Rengeteg egyedi információ: Windows játékok indítása Linux alatt és Linux szerver létrehozása a játékterembe, Dr. Web és AVP for Linux, MRTG forgalom könyvelő program, LIDS védelmi és behatolásjelző rendszer és még sok más. Speciális figyelem a Linux szerverek biztonságára összpontosított. Magát a Linux operációs rendszert kellően részletesen leírják, és a parancsairól referenciakönyvet adunk. A könyv elolvasása után birtokossá válik a kernel konfigurálása és fordítása, saját rpm csomagok létrehozása, a bash parancsértelmező RAID tömbök használatával. Megismerheti a Linux belső világát. A könyv professzionális és kezdő rendszergazdák számára egyaránt alkalmas, hiszen az anyag bemutatása a Linux operációs rendszer telepítésével kezdődik, az első fejezet pedig a főbb hálózati technológiákat és protokollokat ismerteti (Young Administrator Course).

A könyvben található összes adatot a gyakorlatban ellenőrizzük, és a mellékelt CD-n helyezzük el. Ezen kívül rengeteget tartalmaz háttér-információ(HOGYAN, RFC), valamint a Linuxról szóló cikkeket. Segédeszközök gazdag készlete és szoftver a szerverhez (Apache, MySQL, MRTG stb.).

Könyv:

Az oldal szakaszai:

A Telnet szolgáltatás alapvető terminálemulációt biztosít olyan távoli rendszerek számára, amelyek támogatják a Telnet protokollt a TCP/IP protokollon keresztül. A Digital Equipment Corporation VT 100, a Digital Equipment Corporation VT 52, a TTY terminálok emulációja biztosított. A Telnet protokoll leírása az RFC 854-ben található, amely a mellékelt CD-n található.

Bármilyen parancs, amelyet ezzel hajtottak végre Telnet, a telnet szerver kezeli, nem helyi számítógép. A felhasználó csak ezeknek a parancsoknak az eredményét látja.

A Telnet használatához a telnet démont telepíteni kell a távoli számítógépre. A felhasználó számítógépére telepíteni kell egy kliens programot. Szinte minden operációs rendszer rendelkezik telnet segédprogram, amely a telnet protokoll kliense (lásd: 8.2. ábra).

A Telnet szolgáltatás a távoli bejelentkezés és a távoli gépen végzett munka egyik legnépszerűbb módja volt és marad is. Fő hátránya, hogy minden információ, beleértve a jelszavakat is, tiszta szövegben, titkosítás nélkül kerül továbbításra.

Az SSH (Secure Shell) egy program, amely lehetővé teszi a távoli számítógépekre való bejelentkezést és titkosított kapcsolat létrehozását. Létezik a telnet "biztonságos" változata is, a stelnet.

Az SSH nyilvános kulcsú titkosítást használ a két gép közötti kapcsolat titkosítására és a felhasználók hitelesítésére.

Rizs. 8.2.Telnet kliens Windowshoz

Az ssh shell segítségével biztonságosan bejelentkezhet egy távoli szerverre, vagy adatokat másolhat két gép között, miközben megakadályozza a középső támadásokat (munkamenet-eltérítés) és a névszerver-hamisítást (DNS-felderítés).

A Secure Shell a következő titkosítási algoritmusokat támogatja:

BlowFish egy 64 bites titkosítási séma. Ezt az algoritmust gyakran használják nagy mennyiségű adat nagy sebességű titkosításához.

Tripla DES(Data Encryption Standard) - az adattitkosítás szabványa. Ez az algoritmus meglehetősen régi, ezért nem ajánlott használni. A DES-t általában nem titkos adatok titkosítására használják.

ÖTLET(International Data Encryption Algorithm) - egy nemzetközi algoritmus információk titkosítására. Ez az algoritmus 128 bites kulccsal működik, ezért biztonságosabb, mint a BlowFish és a DES.

RSA(Rivest-Shamir-Adelman algoritmus) - Rivest-Shamir-Adelman algoritmus. Ez egy titkosítási séma nyilvános és privát kulcsokkal.

A titkosítási algoritmus kiválasztásakor az átvinni kívánt információk bizalmas jellegére kell törekednie. Ha az információ titkos, jobb az IDEA vagy az RSA algoritmusok használata. Ha egyszerűen nem akarsz adatátvitelt végezni, használd a BlowFish algoritmust, mivel az sokkal gyorsabb, mint a DES.

Az ssh shell nagyon hatékony a protokollszagolókkal szemben, mivel nem csak titkosítja, hanem tömöríti is a forgalmat, mielőtt továbbadná távoli számítógép. Az ssh program innen tölthető le http://www.cs.hut.fi/ssh/. Az ssh UNIX-os verziója ingyenes, míg a Windows verzió (értsd: Windows kliens) pénzbe kerül.

Az ssh shell nélkülözhetetlen olyan esetekben, amikor távolról kell adminisztrálnia a szervert, vagy ha a szervernek nincs saját monitora. Telnet használatakor a telnet kapcsolaton keresztül küldött összes adat szöveges formában elérhető. Ez azt jelenti, hogy a felhasználónevek és jelszavak bárki számára elérhetőek lesznek, aki az elemző segítségével figyeli a forgalmat. Az ssh számos különböző algoritmussal hajt végre titkosítást, beleértve a DES-t és a 3DES-t.

A program egy sshd démonból áll, amely Linux/UNIX gépen fut, és egy ssh kliensből, amely Linuxra és Windowsra egyaránt terjesztett. Az ssh telepítéséhez vegye ki a forrásokat, és hagyományosan a /usr/src/ könyvtárba helyezze őket. Ezután csomagolja ki az archívumot, és telepítse a programot az alábbi lépések végrehajtásával:

cd /usr/src/
tar xzf ssh-2.4.0.tar.gz
cd ssh-2.4.0
./Beállítás
készítsenek
telepítse

Az ssh működéséhez el kell indítani az sshd démont azon a gépen, amelyhez csatlakozni akarunk. Az automatikus indítás érdekében ajánlatos egy indítási parancsot hozzáadni a rendszerindító szkripthez. Az sshd démon a 22-es porton fut (lásd a 8.6-os listát). Ha nem tévedek, az ssh nem használható xinetd/inetd-vel – úgy kell futtatni, mint egy httpd szervert önálló módban.

Felsorolás 8.6. Az /etc/services fájl töredéke

ssh 22/tcp # SSH távoli bejelentkezési protokoll
ssh 22/udp # SSH távoli bejelentkezési protokoll

Általában nincsenek kellemetlen pillanatok az sshd beállításával. A démonkonfigurációról a fejezet későbbi részében lesz szó. Most próbáljon meg ssh-n keresztül bejelentkezni erre a gépre. Ehhez telepítenie kell ugyanazt a csomagot egy másik Linux/UNIX rendszert futtató gépre (vagy telepítenie kell egy Windows ssh klienst), és ki kell írnia a parancsot:

$ ssh hostname.domain

Az ssh kérni fogja a felhasználó jelszavát. A kapcsolat létesítéséhez az aktuális felhasználó neve, vagyis az a név, amellyel éppen bejelentkezett a rendszerbe. Ha a hitelesítés sikeres, elindul a kommunikációs munkamenet. A munkamenet a Ctrl+D billentyűkombináció lenyomásával fejezhető be.

Ha másik felhasználónevet kell megadnia, használja az ssh program -l kapcsolóját:

ssh –l felhasználó hostname.ru

Így megmondhatja az ssh programnak, hogy melyik felhasználóhoz kell bejelentkeznie a távoli gépen (lásd: 8.3. ábra).

A Windows kliens használatakor a számítógép nevét, felhasználónevét és jelszavát meg kell adni a program párbeszédpanelében. Ha a kapcsolat sikertelen, próbálja meg kiválasztani a blowfish kódolási módszert. Ha ez nem segít, válassza a 3DES-t.

Az ssh-ban dolgozni hasonló a telnethez. Egy távoli gépet ugyanolyan egyszerűen felügyelhet, mint egy helyi gépet. Az ssh program opciói az 1. táblázatban vannak felsorolva. 8.5.

8.Z. Regisztráció távoli gépen

ssh program opciók 8.5. táblázat

választási lehetőség	Leírás
-a	Letiltja a kapcsolati ügynök hitelesítési átirányítását
-DE	Engedélyezi a kapcsolati ügynök hitelesítési átirányítását
-c blowfish|3des	Lehetővé teszi a titkosítási algoritmus kiválasztását az SSH protokoll első verziójának használatakor. Megadhat blowfish-t vagy 3des-t
-rejtjellel	A titkosítások vesszővel elválasztott listáját adja meg preferencia szerinti sorrendben. Csak az SSH protokoll második verziójához. Az érvényes értékek: blowfish, twofish, arcfour, cast, des és 3des
-f	Ez az opció megváltoztatja az ssh-t háttér módban felhasználói hitelesítés után. A program futtatásához az X11 használata javasolt. Például ssh -f hostxterm
-én	file-ident Nem szabványos azonosító fájlt határoz meg (nem szabványos RSA/DSA hitelesítéshez)
-l felhasználónév	Meghatározza, hogy a távoli gépen a regisztráció melyik felhasználó nevében történik
-r port	Megadja azt a portot, amelyhez az ssh program csatlakozni fog (alapértelmezés szerint a 22-es portot használja)
-q	Csendes mód. Csak a végzetes hibaüzenetek jelennek meg. Az összes többi figyelmeztető üzenet nem kerül kinyomtatásra a szabványos kimenetre.
-x	Az X11 átirányítás letiltása
-X	Engedélyezze az X11 átirányítást
-1	Csak az SSH protokoll első verzióját használja
-2	Csak az SSH protokoll második verzióját használja
-4
-6

Az ssh shell két konfigurációs fájlt használ: ssh_conf és sshd_conf. Szerintem nincs értelme azt mondani, hogy az /etc/ssh könyvtárban vannak. Azt javaslom, hogy adja hozzá a következő sort az sshd_conf fájlhoz:

engedélyezett cím 10.1.1.1 10.1.2.1 10.1.3.1

Ez azt jelenti, hogy az ssh hozzáférést csak a 10.1.1.1, 10.1.2.1, 10.1.3.1 címmel rendelkező gépekről lehet végrehajtani. Ez megvédi számítógépét a nem kívánt kívülről érkező behatolásoktól.

A stelnet program mindenben teljesen hasonló a telnet programhoz, de titkosítja a telnet kapcsolat során továbbított forgalmat.

Az sshd démon egy démonprogram az ssh shell számára. Általában az sshd azon a gépen fut, amelyhez az ssh kliensek csatlakoznak. Legújabb verziók Az sshd démon az ssh protokoll két verzióját támogatja - az ssh 1-es verziót és az ssh-2-es verziót.

SSH protokoll 1-es verzió

Minden csomópontnak saját RSA-kulcsa van (általában 1024 bites), amely a csomópont azonosítására szolgál. Ezt a kulcsot nyilvános kulcsnak is nevezik. Ezenkívül a démon indításakor egy másik RSA-kulcs generálódik - a szerverkulcs (általában 768 bites). Ezt a kulcsot óránként újra létrehozzák, és soha nem mentik lemezre.

Minden alkalommal, amikor kapcsolat jön létre egy klienssel, a démon válaszul visszaküldi a nyilvános kulcsát és a szerver kulcsát. Az ügyfél összehasonlítja a kapott nyilvános kulcsot az adatbázisával, hogy megnézze, változott-e. A kliens ezután véletlenszerűen generál egy 256 bites számot, és egyidejűleg két kulccsal – a nyilvános és a szerver kulcsával – kódolja. Mindkét fél ezt a véletlen számot használja munkamenetkulcsként, amely a munkamenet során továbbított összes adat kódolására szolgál.

A kliens ezután megpróbálja hitelesíteni magát .rhosts hitelesítéssel, RSA hitelesítéssel vagy jelszavas hitelesítéssel.

Általában az .rhosts hitelesítés nem biztonságos, ezért le van tiltva.

SSH protokoll 2-es verziója

A 2-es verzió hasonlóan működik: minden csomópont rendelkezik egy adott DSA-kulccsal, amely a csomópont azonosítására szolgál. A démon indításakor azonban a szerverkulcs nem jön létre. A kapcsolat biztonságát a Diffie-Hellman kulcsszerződés biztosítja.

Egy munkamenet a következő módszerekkel kódolható: 128 bites AES, Blowfish, 3DES, CAST128, Arcfour, 192 bites AES vagy 256 bites AES.

Az sshd démon opciókat az 1. táblázat tartalmazza. 8.6.

sshd démon beállítások 8.6. táblázat

választási lehetőség	Leírás
-b bitek	Megadja a kiszolgálókulcs bitjeinek számát (alapértelmezett 768). Ez az opció csak akkor használható, ha az SSH protokoll 1-es verzióját használja
-d	Hibakeresési mód (DEBUG). Ebben a módban a szerver nem megy a háttérbe, és a műveleteit részletesen naplózza a rendszernaplóban. Ennek az opciónak a használata különösen hasznos a szerver működésének megismerésekor.
-e	Ha ez a beállítás meg van adva, az sshd démon nem a rendszernaplónak küld hibakeresési üzeneteket, hanem a szabványos hibafolyamnak.
-f config_file	Készletek alternatív fájl konfigurációt. Az alapértelmezett az /etc/ssh/sshd_config
-g idő	További időt ad a nem hitelesített ügyfélnek a hitelesítésre. Az alapértelmezett idő 600 másodperc. Ha ezalatt az ügyfél nem tudja magát hitelesíteni, a kapcsolat megszakad. A 0 értéket a rendszer végtelen várakozásként értelmezi
-h	keyfile Megad egy alternatív nyilvános kulcsfájlt (gazdakulcs). Az alapértelmezett fájl az /etc/ssh/ssh_host_key. Erre az opcióra szükség lehet ahhoz, hogy az sshd a root helyett bármi másként fusson. Ezen opció gyakori használata az sshd indítása olyan szkriptekből, amelyek a napszaktól függően különböző beállításokat adnak meg. Például a nappali (munka) időben bizonyos beállítások vannak beállítva, és az esti (munka) időben mások
-én	Akkor használható, ha az sshd-t a xinetd (inetd) szuperkiszolgálón keresztül szeretné futtatni. Általában az sshd démont nem az xinetd superserver (inetd) indítja el, hanem a rendszerindításkor indul el, mert az sshd démonnak némi időbe telik (10 másodperc) előállítani a kiszolgálókulcsot, mielőtt válaszolni tudna az ügyfél kérésére.
-k idő	Meghatározza azt az időt, amely után a kiszolgálókulcs újragenerálásra kerül. Az alapértelmezett idő 3600 másodperc (1 óra). Ez a beállítás csak akkor használható, ha az SSH protokoll 1-es verzióját használja
-r port	Meghatároz egy alternatív portot, amelyen az sshd démon figyelni fog. Az alapértelmezett port a 22
-q Csendes üzemmód.	Ebben a módban a munkamenet naplózása nem történik meg. Általában a hitelesítés kezdete, a hitelesítés eredménye és a munkamenet befejezési ideje naplózásra kerül.
-t	Teszt üzemmódban. Ez a mód a konfigurációs fájl helyességének ellenőrzésére szolgál
-D	Ezzel az opcióval a démon nem megy a háttérbe
-4	Az IP-címeket csak IPv4 formátumban használhatja
-6	Csak IPv6 formátumú IP-címeket használhat

A /etc/ssh/sshd_config démon konfigurációs fájl úgy néz ki, mint a Listing 8.7

Lista 8.7 /etc/ssh/sshd_config konfigurációs fájl

# $OpenBSD: sshd_config,v 1.38 2001/04/15 21:41:29 deraadt Exp $
# Ezt az sshd-t a PATH=/usr/bin:/bin:/usr/sbin:/sbin paraméterrel fordították
# Ez az sshd szerver rendszerszintű konfigurációs fájlja. Lásd: sshd(8)
# további információért.
22-es kikötő
#Protokoll 2.1
# ListenAddress 0.0.0.0
# ListenAddress::
HostKey /etc/ssh/ssh_host_key
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_dsa_key
ServerKeyBits 768
BejelentkezésGraceTime 600
KeyRegenerationInterval 3600
PermitRootLogin igen
#
# Ne olvassa el a ~/.rhosts és ~/.shosts fájlokat
IgnoreRhosts igen
# Törölje a megjegyzést, ha nem bízik a ~/.ssh/known_hosts for
RhostsRSAAhitelesítés
# IgnoreUserKnownHosts igen
StrictModes igen
X11 Továbbítás igen
X11 DisplayOffset 10
PrintMotd igen
# PrintLastLog sz
Maradj életben Igen
# Naplózás
SyslogFacility AUTHPRIV
LogLevel INFO
# elavult a QuietMode és a FascistLogging
RhostsAuthentication no
#
# Ahhoz, hogy ez működjön, az /etc/ssh/ gazdakulcsokra is szükséged lesz
ssh_known_hosts
RhostsRSAAhitelesítési sz
# hasonló a protokoll 2-es verziójához
Gazda alapú hitelesítés sz
#
RSAA-hitelesítés igen
# Az alagútban lévő szöveges jelszavak letiltásához módosítsa itt a nem értékre!
Jelszóhitelesítés igen
PermitEmptyPasswords sz
# Törölje a megjegyzéseket az s/key jelszavak letiltásához
# ChallengeResponseAuthentication sz
# A PAM-billentyűzet interaktív hitelesítés engedélyezéséhez törölje a megjegyzést
# Figyelmeztetés: ennek engedélyezése megkerülheti a "Jelszó hitelesítés" beállítását
# PAMAuthenticationViaKbdInt igen
# A Kerberos beállításainak módosítása
# KerberosAuthentication no
# KerberosOrLocalPasswd igen
# AFSTokenPassing sz
# KerberosTicketCleanup sz
# A Kerberos TGT Passing csak az AFS kaserverrel működik
# KerberosTgtPassing igen
# CheckMail igen
# Use Login sz
# MaxStartups 10:30:60
# Banner /etc/issue.net
# ReverseMappingCheck igen
sftp/usr/libexec/openssh/sftp-server alrendszer

UKRAJNA KÖZLEKEDÉSI ÉS HÍRKÖZLÉSI MINISZTÉRIUMA

ODESSZAI NEMZETI HÍRKÖZLÉSI AKADÉMIA őket. A.S. POPOVA

Kommunikációs Hálózatok Tanszék

absztrakt

a témán: "SSH, CMIP, Telnet protokollok"

Odessza 2013

• • Szabványok és szoftvermegvalósítások
  • SSH szerverek
  • SSH kliensek és shellek
  • SSH biztonsági tippek
  • SSH használati példák
  • SSH alagút
  • Technikai információk a protokollról

A CMIP protokoll főbb jellemzői

CMIP protokoll és CMIS szolgáltatások

Szűrés

Szinkronizálás

• Eszköz
• Lehetőségek
• NVT nyomtató és billentyűzet
• Telnet parancsstruktúra
• Alkalmazások
• Biztonság
• Telnet és egyéb protokollok

Szabványok és szoftvermegvalósítások

SSH (Eng. Secure SHell - "secure shell") - egy alkalmazásszintű hálózati protokoll, amely lehetővé teszi távirányító operációs rendszer valamint a TCP-kapcsolatok alagútkezelése (pl. fájlátvitelhez). Funkciójában hasonló a Telnet és az rlogin protokollokhoz, de azokkal ellentétben titkosítja az összes forgalmat, beleértve a továbbított jelszavakat is. Az SSH lehetővé teszi a különböző titkosítási algoritmusok kiválasztását. SSH-kliensek és SSH-kiszolgálók állnak rendelkezésre a legtöbb hálózati operációs rendszerhez.

Az SSH lehetővé teszi szinte bármilyen más hálózati protokoll biztonságos átvitelét nem biztonságos környezetben. Így nemcsak távolról dolgozhat számítógépen egy parancshéjon keresztül, hanem egy titkosított csatornán (például webkameráról) keresztül is továbbíthat hangfolyamot vagy videót. Az SSH a továbbított adatok tömörítését is használhatja a későbbi titkosításhoz, ami kényelmes például az X WindowSystem kliensek távoli indításakor.

A legtöbb tárhelyszolgáltató térítés ellenében SSH-hozzáférést biztosít az ügyfeleknek a kezdőkönyvtárukhoz. Ez kényelmes lehet mind a parancssorban, mind a programok távoli indításához (beleértve a grafikus alkalmazásokat is).

A protokoll első változatát, az SSH-1-et 1995-ben Tatu Ulyonen, a Helsinki Műszaki Egyetem kutatója fejlesztette ki (Finnország). Az SSH-1 privátabbnak készült, mint az rlogin, telnet és rsh protokoll. 1996-ban kifejlesztették a protokoll biztonságosabb verzióját, az SSH-2-t, amely nem kompatibilis az SSH-1-gyel. A protokoll még nagyobb népszerűségre tett szert, és 2000-re körülbelül kétmillió felhasználója volt. Jelenleg az "SSH" kifejezés általában az SSH-2-re vonatkozik, mert. a protokoll első verzióját jelentős hiányosságok miatt gyakorlatilag nem használják.

2006-ban a jegyzőkönyvet jóváhagyták munkacsoport Az IETF mint internetes szabvány.

Egyes országokban (Franciaország, Oroszország, Irak és Pakisztán) azonban továbbra is külön engedélyre van szükség az illetékes hatóságoktól bizonyos titkosítási módszerek, köztük az SSH használatához.

Az SSH két megvalósítása gyakori: egy privát kereskedelmi és egy ingyenes. Az ingyenes megvalósítást OpenSSH-nak hívják. 2006-ra az interneten lévő számítógépek 80%-a OpenSSH-t használt. A privát megvalósítást az SSH Communications Security, a Tectia Corporation 100%-os tulajdonában lévő leányvállalat fejleszti, és nem kereskedelmi használatra ingyenes. Ezek a megvalósítások majdnem ugyanazt az utasításkészletet tartalmazzák.

Az SSH-2 protokoll a telnet protokolltól eltérően ellenáll a forgalom szippantása elleni támadásoknak, de nem ellenáll a köztes támadásoknak. Az SSH-2 protokoll a középső csatlakozással (angol sessionhijacking) is ellenáll a támadásoknak, mivel nem lehet csatlakozni egy már létrehozott munkamenethez, vagy elfogni azt.

A köztes támadások elkerülése érdekében, amikor olyan gazdagéphez csatlakozik, amelynek kulcsát az ügyfél még nem ismeri, a kliensszoftver "kulcsujjlenyomatot" (angolul keyfingerprint) mutat a felhasználónak. Javasoljuk, hogy gondosan ellenőrizze a kliensszoftver által megjelenített „kulcsformát” a szerver kulcs pillanatfelvételével, lehetőleg megbízható kommunikációs csatornákon keresztül vagy személyesen.

Az SSH-támogatás minden UNIX-szerű rendszerben megvalósul, és a legtöbben ssh-kliens és kiszolgáló szabványos segédprogramok. Az SSH-klienseknek számos megvalósítása létezik nem UNIX operációs rendszerekhez is. A protokoll nagy népszerűségre tett szert a forgalomelemzők és a helyi hálózatok megszakítására szolgáló módszerek széles körű kifejlesztése után, a nem biztonságos Telnet protokoll alternatívájaként a fontos csomópontok kezelésére.

Az SSH-hoz SSH-kiszolgálóra és SSH-kliensre van szükség. A szerver figyeli a kliens gépekről érkező kapcsolatokat, és a kapcsolat létrejöttekor hitelesítést hajt végre, majd megkezdi a kliens kiszolgálását. Az ügyfél egy távoli gépre való bejelentkezésre és parancsok végrehajtására szolgál.

A csatlakozáshoz a szervernek és a kliensnek kulcspárokat kell létrehoznia – nyilvános és privát –, és nyilvános kulcsokat kell cserélnie. Általában jelszót is használnak.

SSH szerverek

*BSD: OpenSSH

Linux: dropbear, lsh-server, openssh-server, ssh

Windows: freeSSHd, copssh, WinSSHD, KpyM Telnet/SSH Server, MobaSSH, OpenSSH a Cygwin segítségével

SSH kliensek és shellek

GNU/Linux, *BSD: kdessh, lsh-kliens, openssh-kliens, putty, ssh, Vinagre

· MS Windows és Windows NT: PuTTY, SecureCRT, ShellGuard, Axessh, ZOC, SSHWindows, ProSSHD, XShell

KISASSZONY Windows Mobile: PocketPuTTy, mToken, sshCE, PocketTTY, OpenSSH, PocketConsole

Mac OS: NiftyTelnet SSH

SymbianOS: PuTTY

Java: MindTerm, AppGateSecurityServer

J2ME: MidpSSH

iPhone: i-SSH, ssh (terminált is tartalmaz)

Android: connectBot

Szeder: BBSSH

MAEMO 5: OpenSSH

SSH biztonsági tippek

3. Nem szabványos port kiválasztása az SSH-kiszolgálóhoz.

4. Hosszú SSp RSA kulcsok használata (2048 bit vagy több). Az RSA-alapú titkosítási rendszerek akkor tekinthetők biztonságosnak, ha a kulcs hossza legalább 1024 bit.

5. Azon IP-címek listájának korlátozása, amelyekről a hozzáférés engedélyezett (például a tűzfal beállításával).

7. Általános vagy jól ismert rendszerbejelentkezések használatának megtagadása SSH-hozzáféréshez.

8. Rendszeresen ellenőrizze a hitelesítési hibaüzeneteket.

9. Behatolásjelző rendszerek telepítése.

10. SSH-szolgáltatást hamisító csapdák (honeypots) használata.

SSH használati példák

A helyi SSH szerverhez való csatlakozás parancsa a GNU/Linux vagy a FreeBSD parancssorból a pacify felhasználó számára (a szerver nem szabványos 30000-es porton figyel): $ ssh -p 30000 [e-mail védett]

A kulcspárok létrehozása (UNIX-szerű operációs rendszereken) a $ ssh-keygen paranccsal történik

4096 bites SSH-2 RSA kulcspár generálása puttygen segítségével UNIX-szerű operációs rendszer alatt:

$ puttygen -t rsa -b 4096 -o minta

Egyes kliensek, például a PuTTY, grafikus felhasználói felülettel is rendelkeznek.

Az SSH Pythonban való használatához olyan modulok állnak rendelkezésre, mint a python-paramiko és a python-twisted-conch.

SSH alagút

Az SSH-alagút egy SSH-kapcsolaton keresztül létrehozott alagút, amelyet az alagútban lévő adatok titkosítására használnak. Internetes adatátvitel biztosítására szolgál. Ha SSH-alagúton keresztül továbbítják, bármely protokoll titkosítatlan forgalmát az SSH-kapcsolat egyik végén titkosítják, a másik végén pedig visszafejtik. A gyakorlati megvalósítás többféleképpen történhet:

Socks proxy létrehozása olyan alkalmazásokhoz, amelyek nem tudják, hogyan kell SSH-alagúton keresztül dolgozni, de működhetnek Socks proxyn keresztül

· SSH-alagúton keresztül működő alkalmazások használata.

· VPN-alagút létrehozása, amely szinte minden alkalmazáshoz alkalmas.

· Ha az alkalmazás egy adott kiszolgálóval működik, beállíthatja az SSH-ügyfelet úgy, hogy az áthaladjon az SSH-alagút TCP-kapcsolatain, amelyek az SSH-klienst futtató gép egy adott TCP-portjához érkeznek. Például a Jabber-kliensek alapértelmezés szerint a 443-as porton csatlakoznak. Ezután az SSH-alagúton keresztül a Jabber-kiszolgálóval való kapcsolat létrehozásához az SSH-kliens úgy van beállítva, hogy a kapcsolatokat a helyi gép bármely portjáról továbbítsa. távoli szerver: $ ssh -L 4430:jabber.example.com:443 somehost. Ebben az esetben a Jabber kliens úgy van beállítva, hogy csatlakozzon a localhost szerver 4430-as portjához (ha az ssh kliens ugyanazon a gépen fut, mint a Jabber kliens). Ssh-alagút létrehozásához olyan gépre van szükség, amelyen egy futó ssh-kiszolgáló található, és hozzá kell férnie a jabber.example.com címhez. Ez a konfiguráció akkor használható, ha a helyi gépről a jabber.example.com webhelyhez való hozzáférést blokkolja egy tűzfal, de van hozzáférése néhány ssh-kiszolgálóhoz, amelyen nincsenek internet-hozzáférési korlátozások.

Technikai információk a protokollról

Az SSH egy alkalmazási rétegbeli protokoll. Az SSH-kiszolgáló általában a 22-es TCP-porton figyeli a kapcsolatokat. Az SSH-2 protokoll specifikációját az RFC 4251 tartalmazza. Az SSH RSA vagy DSA digitális aláírási algoritmusokon alapuló fél hitelesítési protokollt használ a szerver hitelesítésére. Az RSA vagy DSA digitális aláírás is használható kliens hitelesítésre, de a jelszavas hitelesítés (visszafelé Telnet móddal kompatibilis) és még a gazdagép IP-címe (visszafelé kompatibilis az rlogin móddal) is megengedett. A jelszavas hitelesítés a leggyakoribb; biztonságos, mert a jelszó titkosított virtuális csatornán kerül továbbításra. Az IP-cím alapján történő hitelesítés nem biztonságos, ez a funkció legtöbbször ki van kapcsolva. A Diffie-Hellman (DH) algoritmus egy megosztott titok (munkamenetkulcs) létrehozására szolgál. A továbbított adatok titkosításához szimmetrikus titkosítást, AES, Blowfish vagy 3DES algoritmusokat használnak. Az adatok integritásának ellenőrzése a CRC32 használatával történik SSp-ben vagy a HMAC-SHA1/HMAC-MD5-tel SSp-ben. A titkosított adatok tömörítésére a LempelZiv (LZ77) algoritmus használható, amely ugyanolyan szintű tömörítést biztosít, mint a ZIP archiváló. Az SSH-tömörítés csak az ügyfél kérésére engedélyezett, és a gyakorlatban ritkán használják.

A CMIP protokoll főbb jellemzői

A CMIP megvalósítja a CMIS szolgáltatások teljes készletét. Ezekkel a szolgáltatásokkal a CMIP a következő távoli műveleteket támogatja:

Kérés (meghívás);

Eredmény;

Hiba visszaküldése;

A szolgáltatás igénybevevője a kérés elutasítása;

A kérelem elutasítása a szolgáltató részéről.

A menedzsertől az ügynöknek a CMIP protokollon keresztül továbbított vezérlési információk az ASN.1 és a BER szabályai szerint vannak kódolva.

Minden egyes művelethez meg van határozva a hálózaton keresztül a menedzsertől az ügynökhöz és fordítva továbbított adatblokk formátuma.

A CMIP PDU-k formátumát ASN.1 jelölés írja le, és szerkezete sokkal összetettebb, mint az SNMP-blokkok. Például egy M-GET művelet adatblokkjában vannak olyan mezők, amelyek megadják azon attribútumok nevét, amelyek értékét a menedzser kéri, valamint mezők a böngészési és szűrési paraméterek megadására. Vannak mezők is az objektum hozzáférési jogainak paramétereinek megadására.

A CMIP protokoll használata a vezérlőrendszer meglehetősen magas kezdeti bonyolultsági szintjét határozza meg, mivel működéséhez számos segédszolgáltatás, objektum és objektum adatbázis megvalósítása szükséges.

A CMIP-ügynökértesítések továbbítása mindig megbízható átviteli protokoll használatával történik, és elvesztés esetén újraküldésre kerül.

A CMIP protokollt olyan ügynökök számára tervezték, akik összetett műveletsort tudnak végrehajtani a menedzser egyetlen egyszerű parancsával.

A CMIP protokoll sokkal jobban méretezhető, mivel egyszerre több objektumot is érinthet, és az ügynökök válaszai olyan szűrőkön haladnak át, amelyek csak bizonyos ügynökökhöz és menedzserekhez korlátozzák a vezérlési információk továbbítását. A CMIP protokoll, amely az OSI felügyeleti rendszer ügynökei és menedzserei közötti interakciós protokoll, lehetővé teszi, hogy egyetlen paranccsal azonnal intézkedjen ügynökök csoportján, olyan opciók használatával, mint a böngészés és a szűrés.

A CMIP protokollhoz tartozó MIB-eknek nincs egyetlen szabványuk, és minden távközlési berendezés gyártója csak saját igényeire fejleszti őket. saját felszerelés. Az egyetlen kivétel a G.722, G.774 átviteli rendszerek MIB szabványa.

CMIP protokoll és CMIS szolgáltatások

A felügyelt objektumokban tárolt felügyeleti információkhoz való hozzáférést a CMSIE (Common Management Information Service Element) nevű felügyeleti rendszerelem biztosítja. A CMSIE szolgáltatás elosztott alkalmazásarchitektúrára épül, ahol a funkciók egy részét a menedzser, néhányat pedig az ügynök látja el. A menedzser és az ügynök közötti interakció a CMIP protokoll használatával történik. A CMSIE szolgáltatás által nyújtott szolgáltatások neve CMIS (Common Management Information Services).

A CMIP protokollt és a CMIS szolgáltatásokat az X.710 és X.711 ITU-T szabvány határozza meg. A CMIS szolgáltatások két csoportra oszthatók, a menedzser által kezdeményezett szolgáltatásokra (kérések) és az ügynök által kezdeményezett szolgáltatásokra (értesítések).

A menedzser által kezdeményezett szolgáltatások a következő tevékenységeket foglalják magukban:

· Az M-CREATE utasítja az ügynököt, hogy hozzon létre egy új példányt egy bizonyos osztály objektumából vagy egy új attribútumot egy objektum példányán belül;

· Az M-DELETE utasítja az ügynököt, hogy törölje egy adott osztály vagy attribútum objektumának egy példányát egy objektum példányán belül;

· Az M-GET utasítja az ügynököt, hogy adja vissza egy adott objektumpéldány valamely attribútumának értékét;

· Az M-SET utasítja az ügynököt, hogy változtassa meg egy bizonyos objektumpéldány attribútumának értékét;

· Az M-ACTION utasítja az ügynököt egy adott művelet végrehajtására egy vagy több objektumpéldányon.

Az ügynök csak egy műveletet kezdeményez:

M-EVENT_REPORT - értesítés küldése a menedzsernek.

Szolgáltatásai megvalósításához a CMISE szolgáltatásnak az OSI verem alkalmazási réteg szolgáltatásait kell használnia - ACSE, ROSE.

A CMIS-szolgáltatások és a hasonló SNMP-szolgáltatások közötti különbség a nagyobb rugalmasság. Míg az SNMP GET és SET kérések egy objektumnak csak egy attribútumára vonatkoznak, az M-GET, M-SET, M-ACTION és M-DELETE kérések egynél több objektumra vonatkozhatnak. Ennek érdekében a CMIP/CMIS szabványok olyan fogalmakat vezetnek be, mint a hatókör, szűrés és szinkronizálás.

Felülvizsgálat

A CMISE-lekérdezés a tallózás segítségével több objektumot is lekérdezhet egyszerre. A felülvizsgálat négy szintje kerül bevezetésre:

· az alapobjektum, amelyet megkülönböztető neve FDN határoz meg;

helyen található objektumok n-edik szint alárendeltség a fába való alapbefoglaláshoz képest;

az alapobjektum és az alárendelt szintjein elhelyezkedő összes objektum egészen az n-edikig (beleértve) a zárványfában;

részfa - az alapobjektum és az összes alárendeltje a befogadófában.

Szűrés

A szűrés abból áll, hogy logikai kifejezést alkalmazunk a kezelő kérésére. A lekérdezés csak azokra az objektumokra és azok attribútumaira vonatkozik, amelyekre az adott logikai kifejezés igaz. A logikai kifejezések tartalmazhatnak relációs operátorokat =>,<=,<,>vagy bizonyos tulajdonságokat. Lehetőség van összetett szűrők létrehozására több szűrő egy összetett szűrőbe történő kombinálásával.

Szinkronizálás

Több objektum lekérdezésekor két szinkronizálási séma egyikét használja a rendszer: atomi vagy amikor csak lehetséges. Az atomséma esetén a lekérdezés csak akkor hajtható végre, ha a tallózás vagy a szűrő hatókörén belül minden objektum sikeresen teljesíti a lekérdezést. A „ha lehetséges” szinkronizálás a kérés továbbítását jelenti minden olyan objektumhoz, amelyre a kérelem vonatkozik. A művelet akkor fejeződik be, ha a lekérdezést tetszőleges számú objektum végrehajtja.

A CMIP protokoll olyan műveletek halmaza, amelyek közvetlenül megfelelnek a CMIS szolgáltatásoknak. Így a CMIP protokoll meghatározza az M-GET, M-SET, M-CREATE stb. műveleteket. Minden egyes művelethez meg kell határozni a hálózaton keresztül a menedzsertől az ügynökhöz és fordítva továbbított adatblokk formátumát. A CMIP PDU-k formátumát ASN.1 jelölés írja le, és szerkezete sokkal összetettebb, mint az SNMP-blokkok. Például egy M-GET művelet adatblokkjában vannak mezők a kezelő által kért attribútumok nevének meghatározásához, valamint olyan mezők, amelyek megadják a böngészési és szűrési beállításokat, amelyek meghatározzák a kérés által érintett objektumpéldányok halmazát. . Vannak mezők is az objektum hozzáférési jogainak paramétereinek megadására.

Az SNMP és CMIP protokollok összehasonlítása

Az SNMP protokoll használata lehetővé teszi mind egyszerű, mind összetett felügyeleti rendszerek felépítését, a CMIP protokoll használata pedig meghatározza az irányítási rendszer bizonyos, meglehetősen magas kezdeti összetettségi szintjét, mivel működéséhez számos megvalósításra van szükség. kiegészítő szolgáltatások, objektumok és objektum adatbázisok.

· A CMIP-ügynökök általában összetettebb funkciókat látnak el, mint az SNMP-ügynökök. Emiatt a menedzser által az SNMP-ügynökön végrehajtható műveletek atomi jellegűek, ami többszörös adatcserét eredményez a menedzser és az ügynök között.

· Az SNMP ágens csapdákat a rendszer anélkül küldi el a menedzsernek, hogy megvárná a nyugtát, ami fontos hálózati problémákat okozhat, mert a megfelelő csapdák elvesznek, míg a CMIP ügynök csapdákat mindig megbízható szállítási protokoll használatával továbbítják, és abban az esetben, ha a veszteségek újraküldésre kerülnek.

· Az SNMP-problémák egy része megoldható intelligensebb MIB-k használatával (amelyek tartalmazzák az RMON MIB-et is), de sok eszköznél és helyzetnél nincsenek ilyen MIB-k (vagy nincs szabvány, vagy nincs megfelelő MIB a felügyelt berendezésben) .

· A CMIP protokollt olyan intelligens ügynökök számára tervezték, amelyek összetett műveletsort tudnak végrehajtani a kezelő egyetlen egyszerű parancsára.

· A CMIP protokoll sokkal jobban skálázható, mivel egyszerre több objektumot is érinthet, és az ügynökök válaszai olyan szűrőkön haladnak át, amelyek csak bizonyos ügynökök és menedzserek számára korlátozzák a vezérlési információk továbbítását.

hálózati protokoll működési szövege

TELNET(A TERminaLNETwork) egy hálózati protokoll szöveges interfész hálózaton keresztüli megvalósítására (modern formájában, TCP-transzport segítségével). A „telnet” nevet bizonyos segédprogramok is használják, amelyek a protokoll kliens oldalát valósítják meg. A jelenlegi protokollszabványt az RFC 854 írja le.

Ellátja az OSI modell alkalmazási réteg protokolljának funkcióit.

A TELNET protokoll célja egy meglehetősen általános, kétirányú, nyolc bites, bájtorientált kommunikációs eszköz biztosítása. Fő célja, hogy lehetővé tegye a termináleszközök és terminálfolyamatok közötti kommunikációt. Azt tervezzük, hogy ez a protokoll használható terminálok közötti kommunikációra ("kötés") vagy folyamatok közötti kommunikációra ("elosztott számítástechnika").

Eszköz

Bár egy Telnet szekciónak külön kliens és szerver oldala van, a protokoll valójában teljesen szimmetrikus. A szállítási kapcsolat (általában TCP) létrehozása után mindkét vége a "hálózati virtuális terminálok" (eng. Network Virtual Terminal, NVT) szerepét tölti be, kétféle adatot cserélve:

· Alkalmazásadatok (vagyis azok az adatok, amelyek a felhasználótól a szerveroldali szöveges alkalmazásba kerülnek és fordítva);

· Telnet protokoll parancsok, amelyek speciális esetei olyan opciók, amelyek a felek képességeinek és preferenciáinak tisztázását szolgálják.

Bár a TCP-n keresztüli Telnet-munkamenet eleve full-duplex, az NVT-t félduplex eszközként kell kezelni, amely alapértelmezés szerint pufferelt vonal módban működik.

Az alkalmazásadatok változtatás nélkül haladnak át a protokollon, vagyis a második virtuális terminál kimenetén pontosan azt látjuk, amit az első bemenetén adtunk meg. A protokoll szempontjából az adatok egyszerűen bájtok (oktett) sorozata, amely alapértelmezés szerint az ASCII készlethez tartozik, de a Bináris opció bekapcsolásával bármilyen lehet. Bár javasoltak kiterjesztéseket a karakterkészlet azonosítására, a gyakorlatban nem használják őket. A \377 (tizedesjegy 255) kivételével minden alkalmazásadat-oktett érték átadásra kerül a szállításon, ahogy van. A \377 oktett két oktett \377\377 sorozataként kerül átvitelre. Ennek az az oka, hogy a szállítási réteg a \377 oktettet használja az opciók kódolására.

Lehetőségek

A protokoll alapértelmezés szerint biztosítja a minimális funkcionalitást és az azt kiterjesztő opciókat. A kikötött opciók elve megköveteli, hogy a tárgyalásokat akkor kell lefolytatni, amikor mindegyik opció szerepel. Az egyik fél kezdeményezi a kérést, a másik fél pedig elfogadhatja vagy elutasíthatja az ajánlatot. A kérés elfogadása esetén az opció azonnal életbe lép. Az opciókat magától a protokolltól külön ismertetjük, és a szoftver általi támogatásuk tetszőleges. A protokoll kliens (hálózati terminál) utasítja a nem támogatott és ismeretlen opciókat tartalmazó kéréseket.

NVT nyomtató és billentyűzet

Az NVT nyomtató kocsiszélessége és oldalhossza nem meghatározott, és mind a 95 nyomtatható US-ASCII karaktert (32-126 kód) képviselnie kell. A vezérlőkarakterek jelentése a következő:

Név		Leírás
		Nincs művelet
		A nyomtatót a következő nyomtatási sorra viszi, miközben ugyanabban a vízszintes helyzetben marad.
kocsi vissza (CR) *		A nyomtatót az aktuális sor bal szélére mozgatja.
		Hang- vagy videojelet állít elő (de NEM mozgatja a nyomtatófejet).
		A nyomtatófejet egy karakterrel a bal margó felé mozgatja.
Vízszintes lap (HT)		A nyomtatót a következő vízszintes tabulátorhelyre helyezi. Meghatározatlan marad, hogy az oldal hogyan határozza meg és állítja be ezeket a tabulátorokat.
Függőleges lap (VT)		A nyomtatót a következő függőleges tabulátorhoz mozgatja. Meghatározatlan marad, hogy az oldal hogyan határozza meg és állítja be ezeket a tabulátorokat.
		A nyomtatót a következő oldal tetejére mozgatja, miközben ugyanabban a vízszintes helyzetben marad.

A *-gal jelölt karakterek műveleteinek támogatása szükséges. Mások végrehajthatnak egy adott műveletet, vagy nem hajtanak végre semmit; az egyik oldalnak nem kell semmi konkrétat feltételeznie a másik oldal bizonyos opcionális vezérlőkarakterek támogatásáról.

A "CR LF" szekvenciát egyetlen újsor karakterként kell kezelni, és akkor kell használni, amikor együttes műveletükre van szükség; a "CR NUL" szekvenciát kell használni, ha csak a kocsi visszatérése szükséges; és a CR karakter használatát kerülni kell más összefüggésekben.

Telnet parancsstruktúra

Minden TELNET parancs egy többbájtos sorozat, amely a \377 (tizedes: 255) "InterpretasCommand" (IAC) kóddal és a parancskóddal kezdődik. Az opció egyeztetéséért felelős parancsok három bájtos sorozatok, ahol a harmadik bájt az opció kódja. A következő kódok és kódsorozatok csak akkor rendelkeznek megfelelő jelentéssel, ha közvetlenül követik az IAC-t.

Név	Kód (tizedes/hexadecimális)	Leírás
		Befejezi az SB paranccsal elindított egyeztetést
		Nincs művelet.
		Szinkronizálás (Synch) adatcsere. Ezt a parancsot mindig egy TCP Sürgős értesítés követi.
		Megnyomja a „Szünet” vagy „Figyelem” gombot.
InterruptProcess		Felfüggeszt, megszakít, megszakít vagy leállít egy folyamatot.
		Elnyomja az aktuális folyamat kimenetét. Szinkronjelet is küld a felhasználónak.
		Nyomtatható karakterekből álló terminálválaszt küld vissza.
		A címzettnek lehetőség szerint el kell távolítania az előző karaktert.
		Törölje az utoljára beírt sort, azaz az utolsó sor után kapott összes adatot.
		Adatátvitel függőben.
		Paraméterátadást igénylő opció egyeztetés kezdete.
		Jelzi a végrehajtási szándékot, vagy megerősíti, hogy a megadott opció éppen végrehajtás alatt áll.
NEM LESZ opció		A megadott opció elindításának vagy végrehajtásának sikertelenségét jelzi.
		Kérelem, hogy a másik fél hajtsa végre vagy erősítse meg a megadott opció lehívását.
NE opció		Kérelem, hogy a másik fél állítsa le a végrehajtást, vagy erősítse meg, hogy a megadott opció már nem hajtódik végre.
		255. adatbájt.

Alkalmazások

A múltban a Telnet az operációs rendszerek parancssori felületéhez való távoli hozzáférést szolgálta. Ezt követően más szöveges felületekhez kezdték használni, egészen MUD játékokig és animált ASCII-art. Elméletileg a protokoll mindkét oldala nem csak emberek, hanem programok is lehetnek.

Néha a telnet klienseket más protokollokhoz való hozzáférésre használják a TCP átvitelen alapulva, lásd a #Telnet és más protokollok című részt.

A telnet protokollt az FTP vezérlőkapcsolatban használják, vagyis a szerver elérése a telnet ftp.example.net ftp paranccsal hibakeresés és kísérletezés céljából nem csak lehetséges, hanem helyes is (ellentétben a telnet kliensekkel a HTTP, IRC eléréséhez). és a legtöbb egyéb protokoll).

Biztonság

A protokoll nem rendelkezik sem titkosítás, sem adathitelesítés használatáról. Ezért ki van téve minden olyan támadásnak, amellyel szemben a szállítása, azaz a TCP protokoll sebezhető. A rendszer távoli elérésének funkcionalitásához jelenleg az SSH hálózati protokollt (különösen annak 2-es verzióját) alkalmazzák, melynek létrehozása során a biztonsági kérdésekre helyezték a hangsúlyt. Ezért ne feledje, hogy a Telnet-munkamenet meglehetősen bizonytalan, hacsak nem teljesen ellenőrzött hálózaton vagy hálózati rétegbiztonsággal rendelkezik (a VPN-ek különféle megvalósításai). A Telnet, mint operációs rendszerek felügyeleti eszközének megbízhatatlansága miatt ezeket már régóta elhagyták.

Telnet és egyéb protokollok

Az internetes technológusok körében széles körben elterjedt az a vélemény, hogy a Telnet kliens alkalmas az alkalmazási rétegbeli protokollokhoz, mint például a HTTP, IRC, SMTP, POP3 és más, TCP átvitelen alapuló szöveges protokollok kézi eléréséhez (például hibakeresési célokra). A telnet kliens TCP-kliensként való használata azonban a következő nemkívánatos hatásokkal jár:

· A kliens küldhet olyan adatokat, amelyeket nem Ön adott meg (Telnet opciók);

· Az ügyfél nem fogadja el a \377 oktettet;

· A kliens a \377 oktettet megzavarja átvitelkor;

A kliens egyáltalán megtagadhatja a legjelentősebb 1-es bittel rendelkező oktetteket.

Az olyan programok, mint a netcat, tiszta TCP-hozzáférést biztosítanak, de speciális trükkök (mint például az stty -icrnl UNIX rendszeren) szükségesek a soremelés CR LF-ként való átadásához (amire sok protokoll megköveteli). Általában egy Telnet kliens alapértelmezés szerint minden új sort CR LF-ként küld, függetlenül a kliens rendszerén található kódolástól. Az alkalmazásprotokollokhoz (kivéve az FTP-t és valójában a Telnetet) való hozzáférés hibakereséséhez a PuTTY klienst "Nyers" módban kell használni (tiszta TCP hozzáférés) – a PuTTY a Telnet protokoll támogatásától elkülönítve alakítja át az újsorokat.

Hasonló dokumentumok

A CAN protokoll fizikai rétege. Átviteli sebesség és hálózat hossza. A CAN protokoll kapcsolati rétege. Recesszív és domináns bitek. A CAN szabványú hálózat működési diagramja. Hibafelismerési módszerek. A hálózat főbb jellemzői. Magas szintű protokollok.

absztrakt, hozzáadva: 2013.05.17


Az elektronikus levelezés (E-Mail) és fő összetevői: információforrás, levelezőszerver, kliens és protokollok az interakciójukhoz. Az SMTP, POP3 és IMAP4 protokollok összehasonlító jellemzői. Telekonferenciák, fájlarchívumok FTP, Telnet, World Wide Web.

teszt, hozzáadva 2011.01.19


A TMN számítógépes hálózat általános fogalmai, feladatai, jellemzői: vezérléstechnika, fő elemek összetétele és célja, funkcionalitás, architektúra. A vezérlés megvalósítása az OSI modellben. Az SNMP és CMIP protokollok összehasonlító jellemzői.

szakdolgozat, hozzáadva 2011.03.18


Az OSI modell hálózati rétegének általános funkcióinak leírása: naplózás, útválasztás és logikai címzés. Ismerje meg a TCP/IP hálózati protokoll és a parancssori hálózati segédprogramok működését. Helyi hálózati cím és internetosztály meghatározása.

bemutató, hozzáadva: 2013.12.05


A protokoll megállapodások és szabályok összessége, amelyek meghatározzák, hogyan történik az információcsere a számítógépes hálózatban. Néhány interneten használt protokoll rövid leírása és jellemzői: TCP / IP, POP3, IMAP4, SMTP, FTP, HTTP, WAIS, TELNET, WAP.

bemutató, hozzáadva 2011.04.27


Hálózati kapcsolatok védelmét szolgáló rendszer megvalósításának különféle módszereinek elemzése és összehasonlítása. A hálózati támadások típusai és negatív hatásuk módszerei, lehetséges következményei és a megelőzésükre irányuló intézkedések. A biztonságos hálózati kapcsolatok létrehozására szolgáló protokoll felépítése ISAKMP.

szakdolgozat, hozzáadva: 2010.06.19


Az ICMP protokoll általános jellemzői, célja és üzenetformátuma. Az ICMP protokoll alkalmazhatóságának elemzése az IP v4 protokollcsomagról az IP v6 protokollcsomagra való áttérés során. Az útválasztási információcsere protokollok tulajdonságai és működési elve, terjedelme.

szakdolgozat, hozzáadva 2009.08.24


Az ARPANET hálózat létrehozásán, a hálózati interakciós TCP/IP protokollokon dolgozik. Szoftver jellemzője TCP/IP-hez. A TCP/IP család protokolljainak rövid leírása a rövidítések magyarázatával. Architektúra, hálózati rétegek és TCP/IP protokollok.

absztrakt, hozzáadva: 2010.03.05


A protokoll funkciója és a fejlesztés alatt álló protokoll csomagstruktúrája. A fejlécmezők hossza. A vételi puffer hosszának kiszámítása a csomag hosszától és a megengedett késleltetéstől függően. Adatfeldolgozási algoritmusok vételhez és továbbításhoz. A protokoll szoftveres megvalósítása.

szakdolgozat, hozzáadva 2014.05.18


Internetes szolgáltatások: e-mail, fájlátvitel. Hálózati szolgáltatások fogadása távoli számítógépen keresztül. Internet protokollok: HTTP, FTP, Telnet, WAIS, Gopher, SMTP, IRC. A videokonferencia bevezetésének céljai. Telekonferenciák szervezése és lebonyolítása.

A CLI-környezet többféleképpen is elérhető. A leggyakoribb módszerek:

• Telnet vagy SSH

Konzol

A CLI egy konzolmunkameneten keresztül érhető el, más néven CTY karakterlánc. A konzol kis sebességű soros kapcsolatot használ, amely egy számítógép vagy terminál és egy útválasztó vagy kapcsoló konzolportjához való közvetlen kapcsolaton keresztül történik.

A konzolport egy felügyeleti port, amely sávon kívüli hozzáférést biztosít az útválasztóhoz. A konzolport akkor is elérhető, ha nincs hálózati szolgáltatás konfigurálva az eszközön. A konzolportot gyakran használják az eszköz eléréséhez, amikor a hálózati szolgáltatások nem indultak el, vagy már nem működnek.

Példák a konzol használatára:

A hálózati eszköz kezdeti beállítása

Katasztrófa utáni helyreállítási eljárások és hibaelhárítás, ha a távoli hozzáférés nem lehetséges

Jelszó-helyreállítási eljárások

Az útválasztó első használatakor a hálózati beállítások még nincsenek konfigurálva. Ezért az útválasztó nem tud kommunikálni a hálózaton keresztül. A kezdeti indításra és konfigurációra való felkészítéshez futtassa a terminálemulációs szoftvert a számítógépen, hogy csatlakozzon az eszköz konzolportjához. Az útválasztó konfigurálásához szükséges konfigurációs parancsokat a csatlakoztatott számítógépen keresztül lehet megadni.

Működés közben, ha az útválasztó nem érhető el távolról, a konzolhoz számítógépen keresztül történő csatlakozás meghatározhatja az eszköz állapotát. Alapértelmezés szerint a konzol információkat jelenít meg az eszköz indításáról, a hibakeresésről és a hibaüzenetekről.

Sok IOS-eszköz esetében a konzolhoz való hozzáférés alapértelmezés szerint nem igényel semmilyen biztonságot. A konzolt azonban jelszavakkal kell konfigurálni az eszközhöz való jogosulatlan hozzáférés elkerülése érdekében. A jelszó elvesztése esetén speciális eljárások állnak rendelkezésre a jelszó megkerülésére és az eszközhöz való hozzáférésre. A fizikai hozzáférés megakadályozása érdekében a készüléket zárt helyiségben vagy berendezési állványban kell elhelyezni.

Telnet és SSH

A Telnet egy módszer az útválasztó CLI-munkamenetéhez való távoli hozzáféréshez. A konzolkapcsolattal ellentétben a Telnet szekciókhoz aktív hálózati szolgáltatásokra van szükség az eszközön. A hálózati eszköznek legalább egy aktív interfésszel kell rendelkeznie 3. rétegbeli címmel, például IPv4-címmel. A Cisco IOS-eszközök tartalmaznak egy Telnet-kiszolgáló folyamatot, amely az eszköz indításakor indul el. Az IOS Telnet klienst is tartalmaz.

A Telnet klienssel rendelkező gazdagép hozzáférhet a Cisco-eszközön futó vty szekciókhoz. Biztonsági okokból az IOS megköveteli, hogy a Telnet munkamenet minimális hitelesítési módszerként jelszót használjon. A fiókok és jelszavak beállításának módszereit a szakasz következő cikkei tárgyalják.

A Secure Shell (SSH) protokoll egy biztonságosabb módszer az eszközök távoli elérésére. Ez a protokoll a Telnethez hasonló távoli bejelentkezést biztosít, azzal a különbséggel, hogy biztonságosabb hálózati szolgáltatásokat használ.

Az SSH erősebb jelszavas hitelesítést biztosít, mint a Telnet, és titkosítást használ a munkamenetadatok továbbítására. Az SSH-munkamenet titkosítja az ügyfél és az IOS-eszköz közötti összes kommunikációt. Ez védi a felhasználói azonosítót, a jelszót és a vezérlési munkamenet részleteit. A legjobb gyakorlat szerint mindig SSH-t használjon Telnet helyett, amikor csak lehetséges.

Az IOS legtöbb újabb verziója tartalmaz SSH-kiszolgálót. Egyes eszközökön ez a szolgáltatás alapértelmezés szerint engedélyezve van. Más eszközökön engedélyezni kell az SSH-kiszolgálót.

Az IOS-eszközök tartalmaznak egy SSH-klienst is, amely SSH-munkamenetek létrehozására használható más eszközökkel. Hasonlóképpen használhat egy távoli gépet egy SSH-ügyféllel biztonságos CLI-munkamenet indításához. Az SSH-ügyfélszoftver alapértelmezés szerint nem minden számítógépes operációs rendszerhez tartozik. Előfordulhat, hogy be kell szereznie, telepítenie és konfigurálnia kell az SSH-ügyfélszoftvert a számítógépéhez.

AUX

A CLI-munkamenet távolról történő létrehozásának másik módja a betárcsázós kapcsolat az útválasztó AUX-portjához csatlakoztatott modemmel. A konzolkapcsolathoz hasonlóan ehhez a módszerhez sem szükséges semmilyen hálózati szolgáltatás konfigurálása vagy elérhetősége az eszközön.

Az AUX port helyileg konzolportként is használható, ha közvetlenül egy terminálemulációs programot futtató számítógéphez csatlakozik. A konzolport szükséges az útválasztó konfigurálásához, de nem minden útválasztó rendelkezik kiegészítő porttal. A konzolportot a diagnosztikai célból is előnyben részesítik a segédporttal szemben, mivel alapértelmezés szerint megjeleníti az útválasztó indítási adatait, a hibakeresési információkat és a hibaüzeneteket.

Általában az AUX portot helyileg csak akkor használják a konzolport helyett, ha probléma van a konzolport használatával, például ha bizonyos konzolbeállítások ismeretlenek.