Nëse punoni në IT, atëherë me siguri jeni përballur një mijë herë me nevojën për t'u identifikuar në një pajisje ose server nga distanca - kjo detyrë mund të bëhet në disa mënyra, dy kryesoret janë të kontrolloni pajisjen përmes linjës së komandës - telnet Dhe Secure Shell (SSH).
Ekziston një ndryshim kryesor midis tyre - në protokoll telnet të gjitha të dhënat transmetohen përmes rrjetit në formë të pakriptuar, dhe në rast SSH Të gjitha komandat janë të koduara me një çelës të veçantë. SSH u krijua si një zëvendësim për Telnet, për menaxhim të sigurt pajisjet e rrjetit përmes një rrjeti të pasigurt siç është interneti. Për çdo rast, mbani mend se Telnet përdor portin 22 , dhe SSH 23 .
Vendosja
Për të filluar, do t'ju duhet Gjurmuesi i paketaveështë një program emulimi rrjeti nga Cisco. Është plotësisht falas dhe mund të shkarkohet nga netacad.com pas regjistrimit. Nisni Packet Tracer dhe le të fillojmë.
Ndërtoni topologjinë si në pamjen e mëposhtme - një kompjuter dhe një ndërprerës i shtresës së tretë. Do t'ju duhet t'i lidhni ato së bashku dhe të filloni konfigurimin.
Gati? Tani do të ofrojmë lidhjen e rrjetit dhe do të konfigurojmë ndërfaqen vlan 1 në çelës, për ta bërë këtë, futni komandat e mëposhtme:
Nëse, menjëherë pas krijimit, tastiera e ndërruesit pyet nëse duhet të fillojë dialogu fillestar i konfigurimit, përgjigjuni "Jo".en conf t interface vlan 1 adresa IP 192.168.1.1 255.255.255.0 pa mbyllje
Tani le të përpiqemi të pingojmë çelësin dhe telnet nga kompjuteri ynë te çelësi - dhe do të shihni që lidhja do të refuzohet sepse ne nuk e kemi konfiguruar ende vërtetimin në çelës.
Le të kalojmë në konfigurimin e vërtetimit. Sistemi mbështet 20 virtuale tty/vty linja për shërbimet Telnet, SSH dhe FTP. Çdo seancë duke përdorur protokollin e mësipërm zë një rresht. Mund të përmirësoni gjithashtu sigurinë e përgjithshme duke vërtetuar kërkesat për autorizim në pajisje. Kthehu në modalitetin e konfigurimit të përgjithshëm ( conf t) në çelës duke përdorur komandën e daljes dhe futni komandat e mëposhtme:
Line vty 0 15 fjalëkalimi i hyrjes në cisco
Fjalëkalimi cisco i përdorur në këtë artikull është jashtëzakonisht e pasigurt dhe është vetëm për qëllime demonstruese. Nëse e lini një fjalëkalim të tillë në pajisje reale, shanset që ju të hakoheni do të priren në pafundësi. Përdorni më mirë tonën :)
Tani provoni përsëri te Telnet në çelës - gjithçka duhet të funksionojë! Sidoqoftë, kur përpiqeni të shkoni te konfigurimi dhe të ekzekutoni komandën e aktivizimit, do të shihni se kjo nuk është e mundur, për shkak të faktit se fjalëkalimi për modalitetin global nuk është vendosur. mundësojnë.
Për ta rregulluar këtë, futni komandat e mëposhtme:
Konf. aktivizoni fjalëkalimin cisco
Provo përsëri - duhet të funksionojë tani!
Tani le të konfigurojmë SSH në çelës - për këtë duhet të specifikoni emrin e hostit, Emri i domenit dhe gjeneroni një çelës enkriptimi.
Futni komandat e mëposhtme (nga mënyra kryesore e konfigurimit):
Emri i hostit merionet_sw1 emri i domenit ip merionet çelësi i kriptos gjeneron rsa
Zgjidhni gjatësinë e çelësit - vlera e paracaktuar është e barabartë me 512 bit, për versionin 2 SSH gjatësia minimale është 768 bit. Gjenerimi kryesor do të marrë pak kohë.
Pas gjenerimit të çelësit, le të vazhdojmë konfigurimin e çelësit:
Ip ssh version 2 line vty 0 15 input transporti ssh
Tani nuk do të jetë më e mundur të regjistroheni duke përdorur protokollin Telnet, pasi e kemi zëvendësuar me SSH. Provoni të identifikoheni përmes ssh duke përdorur hyrjen e paracaktuar - admin. Le ta ndryshojmë atë në diçka të mirë (përsëri nga konf t):
Emri i përdoruesit admin sekret cisco line vty 0 15 login local do wr
Tani provoni të identifikoheni nga stacioni i punës në çelës dhe sigurohuni që cilësimet e reja të kenë hyrë në fuqi.
A ju ndihmon ky artikull?
Te lutem me trego pse?
Na vjen keq që artikulli nuk ishte i dobishëm për ju: (Ju lutemi, nëse nuk është e vështirë, tregoni për çfarë arsye? Do t'ju jemi shumë mirënjohës për një përgjigje të detajuar. Faleminderit që na ndihmoni të bëhemi më të mirë!
Pyetja "si të krijoni një lidhje me Cisco protokoll SSH? i ndodh të gjithëve që ndeshen me këtë pajisje. Përgjigja është "E lehtë!"
Për shembull, le të marrim një model ruteri Cisco 881. Komandat për konfigurimin e ruterave të tjerë (1841, 2800, 3825…) ose ndërprerësit (2900, 3500, 4800…) do të jenë të ngjashme. Dallimi mund të jetë vetëm në cilësimet e ndërfaqes. (Vendosja e aksesit sipas protokollit SSH në muret e zjarrit Cisco ASA përshkruar në artikullin ""
Pra, ne kemi në dispozicion:
Detyra: vendosni një lidhje të sigurt me ruterin Cisco duke përdorur protokollin SSH dhe sigurohuni të sigurt telekomandë.
Hapi 0. Vendosja e ndërfaqes
Ndërfaqja që do të përdoret për menaxhim duhet të aktivizohet në ruter. Në rastin tonë do të jetë brendshme (LAN) ndërfaqe fastethernet 0.
Per referim:
Në ruter Cisco 881 ka një ndërfaqe 3 niveli Fastthernet 4(ai mbi të cilin mund të vendosni menjëherë IP adresa) dhe ndërprerësi i integruar me katër ndërfaqe 2 niveli ( Fastethernet 0 në Fastethernet 3). Për secilën nga këto 4 ndërfaqe, ju mund të lidhni një (!) ndërfaqe virtuale 3 niveli. ( Vlan).
Për ndërfaqen e menaxhimit të ruterit, zgjidhni adresën e parë të disponueshme në rrjetin e zyrës - 192.168.0.1
. Tjetra, shkoni te cilësimet e ndërfaqes virtuale VLAN 1 dhe caktojeni këtë ip adresë. Pas kësaj, ne e lidhim atë me njërën prej fizike ndërfaqet e ruterit ( fastethernet 0) dhe ndizni atë me komandën jo mbyllur.
Për qartësi:
adresa ip => ndërfaqja Vlan X => ndërfaqja Fastethernet Y
Pyetni ip adresa e ndërfaqes VLAN 1
R-DELTACONFIG (konfigurim)#
ndërfaqja Vlan 1
adresa ip 192.168.0.1 255.255.255.0
asnjë mbyllje
Ne lidhim VLAN 1 te ndërfaqe fizike Ethernet i shpejtë 0
R-DELTACONFIG (konfigurim)#
ndërfaqja Fa 0
qasja në portin e kalimit vlan 1
asnjë mbyllje
Veprimi i fundit kryhet për t'u siguruar që cilësimet janë të sakta. VLAN 1 i lidhur si parazgjedhje për secilën ndërfaqe 2 niveli dhe rreshti do të shfaqen në konfigurim vetëm nëse numri Vlan do të jetë ndryshe nga 1.
Tjetra, duhet të kontrolloni disponueshmërinë e ndërfaqes së krijuar nga vetë ruteri, dhe më pas nga çdo stacion pune zyre, për shembull, nga stacioni i punës i administratorit. Të përshtatshme kontroll i thjeshtë ekipi Ping. Natyrisht, ndërfaqja e ruterit fastethernet 0 duhet të lidhet me çelësin rrjet lokal(ose direkt me kompjuterin e administratorit) dhe adresa e kompjuterit nga i cili kryhet kontrolli është në të njëjtin rrjet me adresën e ndërfaqes së ruterit (për shembull, 192.168.0.10
).
Hapi 1 Krijoni një llogari administratori
Menaxhimi në distancë kërkon që ju të krijoni një llogari nëse nuk e keni tashmë një të tillë.
R-DELTACONFIG (konfigurim)#
emri i përdoruesit sekret i administratorit *****
Në vend të yjeve ******, vendosni fjalëkalimin për llogarinë e administratorit.
E rëndësishme!
Sipas rregullave të sjelljes së mirë, fjalëkalimi përbëhet nga shkronja të mëdha dhe të vogla, numra dhe karaktere speciale. karaktere, por jo më të shkurtra se 8 karaktere.
Hapi 2 Vendosja e fjalëkalimit për modalitetin e konfigurimit
Kur hapni konsolën e menaxhimit të ruterit, përdoruesi hyn në një modalitet të thjeshtuar, nga i cili është e mundur të shikohen vetëm disa parametra të pajisjes dhe informacion teknik rreth tij. Në të njëjtën kohë, pranë emrit të pajisjes, ka një shenjë shigjete " >
»
R-DELTACONFIG>
Për të parë konfigurimin e ruterit dhe për ta konfiguruar më tej, duhet të futni komandën mundësojnë
>aktivizo
#
Fillimisht, kjo mënyrë i mbrojtur me fjalëkalim dhe çdo përdorues që është lidhur me një kabllo konsole (rreth kabllos dhe mënyra e lidhjes përshkruhet në ) do të jetë në gjendje të hyjë në modaliteti i konfigurimit. Nga ana tjetër, përdoruesi që është lidhur në distancë ( ssh/telnet), për të cilin niveli i privilegjit nuk është vendosur (vetëm rasti ynë), nuk do të jetë në gjendje të hyjë në modalitetin e konfigurimit.
Vendosni një fjalëkalim për mënyra e privilegjuar(shenjë hash #
pranë emrit të ruterit) duke hyrë në modalitetin e konfigurimit ( conf t).
R-DELTACONFIG (konfigurim)#
R-DELTACONFIG (konfigurim)# aktivizo sekretin ******
Ky fjalëkalim do të jetë i njëjtë për të gjithë përdoruesit.
Mund të lexoni më shumë rreth mënyrave të konfigurimit.
Hapi 3: Aktivizo Menaxhimin në distancë
Për telekomandën, duhet të specifikoni metodën e vërtetimit të përdoruesit me komandën identifikimi lokal
R-DELTACONFIG (konfigurim)#
rreshti vty 0 4
identifikimi lokal
Pas përfundimit të këtij hapi dhe duke supozuar se ndërfaqja e menaxhimit të ruterit është e disponueshme për përdoruesin, bëhet lidhje e mundshme në ruter duke përdorur protokollin telnet. Për këtë është e nevojshme nga linja e komandës komandën e ekzekutimit të stacionit të punës admin
C:\Documents and Settings\***>telnet 192.168.0.1
Duhet t'ju kërkohet përdoruesi dhe fjalëkalimi që janë vendosur Hapi 1. Pas autorizimit të suksesshëm do të jetë i disponueshëm thjeshtuar mënyra e menaxhimit të ruterit (me shigjetë " >
"). Për të hyrë të privilegjuar modaliteti ( #
) duhet të futni komandën mundësojnë, dhe pas fjalëkalimit nga hapi 2.
Hapi 4 Konfiguro SSH
Kur përdorni protokollin telnet (Porta TCP 23) të gjitha komandat dhe të dhënat e konfigurimit të pajisjes transferohen te formë e hapur, e cila është potencialisht e pasigurt. Një protokoll përdoret për të siguruar lidhjen. SSH(TCP porta 22).
Për të vendosur një lidhje nëpërmjet një protokolli SSH ju duhet të vendosni një emër domeni (ndonjë), të gjeneroni një çelës aksesi kriptografik dhe të aktivizoni vetë protokollin SSH versioni 2.
R-DELTACONFIG (konfigurim)#
uebsajti i emrit të domenit ip
çelësi kripto gjeneron rsa
Zgjidhni madhësinë e modulit kyç në rangun nga 360 deri në 2048 për tuajin
Çelësat për qëllime të përgjithshme. Zgjedhja e një moduli kyç më të madh se 512 mund të marrë
Disa minuta.
// pas kërkesës, duhet të specifikoni 1024
Sa bit në modul: 1024
% Duke gjeneruar çelësa RSA 1024 bit, çelësat nuk do të jenë të eksportueshëm...
ip ssh ver 2
Pas përfundimit të këtij hapi, do të mund të lidheni nëpërmjet SSH duke përdorur një program të veçantë që e mbështet këtë funksion, për shembull stuko. Mund ta shkarkoni nga kjo lidhje.
Hapi 5 Kufizoni lidhjen me ruterin vetëm në SSH
Për të përjashtuar mundësinë e lidhjes me ruterin duke përdorur protokollin telnet duhet të futni komandat e mëposhtme:
R-DELTACONFIG (konfigurim)#
rreshti vty 0 4
hyrje transporti ssh
Pas kësaj, qasja në distancë në tastierën e pajisjes nuk do të jetë e mundur përveçse përmes protokollit SSH.
Për më tepër, mund të kufizoni aksesin në menaxhimin e një ruteri Cisco ose të kaloni vetëm nga disa adresa ip. Si ta bëni këtë është përshkruar.
E rëndësishme!
Kini kujdes me aksesin në pajisje. Mos neglizhoni mbrojtjen e lidhjes dhe kufizoni rrethin e personave të pranuar në menaxhim.
E rëndësishme!
Mos harro kurseni konfigurimi i të gjitha pajisjeve me komandën shkruaj ose fillimi i ekzekutimit të kopjes. Përndryshe, pas një rindezjeje, të gjitha ndryshimet do të humbasin.
shkruaj
konfigurimi i ndërtesës...
Protokolli SSH përdoret shpesh për të menaxhuar në distancë ruterat dhe çelsat. Në veçanti, për të menaxhuar pajisjet e rrjetit Cisco. Vendosja e kësaj pajisjeje për t'u lidhur nëpërmjet SSH do të diskutohet në këtë artikull.
Pse SSH për Cisco
SSH është një protokoll i sigurt që do të jetë një pengesë për mbledhësit dhe krisurat që duan të marrin në dorë pajisjet tuaja të rrjetit Cisco.
Por e rëndësishme vendosjen e saktë nëse doni ta mbani ruterin tuaj të sigurt.
Dhe për Cisco, protokolli SSH është konfiguruar duke përdorur rregulla të veçanta, jo si është krijuar menaxhimi i serverit në distancë FreeBSD.
Si të vendosni një lidhje SSH për Cisco
Konfigurimi fillon me faktin që ju duhet të hyni në modalitetin e privilegjuar. Për ta bërë këtë, përdorni komandën e mëposhtme: cisco> enable. Është më mirë të përdorni një çelës publik për t'u lidhur me pajisjen, kështu që rekomandohet të gjeneroni një RSA. Dhe për këtë, duhet të vendosni datën dhe orën e saktë në Cisco, përndryshe çelësi nuk do të funksionojë: cisco# clock set 17:10:00 28 gusht 2016. Pas kësaj, shkoni në modalitetin e modifikimit të drejtpërdrejtë të konfigurimit, i cili do të jetë nevojiten për të krijuar një lidhje nëpërmjet protokollit SSH: cisco# configure terminal
Për të formuar çelës publik, do t'ju duhet të vendosni emrin e domenit me të cilin klienti do të lidhet me pajisjet e rrjetit. Për ta bërë këtë, përdorni komandën: cisco(config)# ip emri i domenit domain_name.ru. Pas kësaj, mund të gjeneroni një çelës RSA duke përdorur kombinimin e mëposhtëm: cisco(config)# çelësi kripto gjeneron rsa. Nëse dëshironi të përmirësoni mbrojtjen tuaj pajisjet e rrjetit, atëherë mund ta përdorni fjalëkalime shtesë, thjesht aktivizoni fillimisht enkriptimin e tyre me komandën: cisco(config)# service password-encryption.
Më pas, duhet të krijoni një përdorues, të krijoni një fjalëkalim për të dhe të specifikoni nivelin e aksesit: cisco(config)# emri i përdoruesit privilegji i emrit të përdoruesit 15 fjalëkalimi 7 fjalëkalimi. Vetëm pasi të keni të paktën një përdorues në sistem, mund të filloni protokollin AAA duke përdorur komandën e mëposhtme: cisco(config)# aaa new-model. Dhe për të nisur përfundimisht linjat e terminalit përmes protokollit SSH, duhet të shkoni në konfigurimin e tyre. Për ta bërë këtë, shkruani: cisco(config)# rresht vty 0 4, ku mund të specifikoni vlerën e konfigurimit nga 0 në 4. Pas kësaj, mund të aktivizoni lidhjen përmes protokollit SSH - shkruani cisco(config-line)# transport hyrje ssh.
Edhe pse tashmë keni linja të terminalit SSH që funksionojnë, futni këtë funksion për të ruajtur ndryshimet: cisco(config-line)# logging sinkron, dhe gjithashtu vendosni vlerën e skadimit të seancës SSH: cisco(config-line)# exec-timeout 60 0. Pas kësaj dilni nga linja e konfigurimit dhe konfigurimi. Së fundi, shtoni konfigurime të reja në sistemin e pajisjeve të rrjetit Cisco: cisco# copy running-config startup-config. Kjo është e gjitha - puna ka mbaruar, tani pajisja juaj do të funksionojë me një lidhje të sigurt SSH.
Lidhja dhe konfigurimi i Cisco Catalyst 2960 ka nuancat e veta dhe është disi i ndryshëm nga lidhja e pajisjeve nga prodhuesit e tjerë.
Lidhja dhe konfigurimi i Cisco Catalyst 2960 ka nuancat e veta dhe është disi i ndryshëm nga lidhja e pajisjeve nga prodhuesit e tjerë. Konfigurimi fillestar do të kërkojë një kabllo të sheshtë RJ-45-RS-232 të pronarit (me një gërshet blu, të furnizuar me pajisjet) dhe praninë e një porti COM në pllakën amë të kompjuterit përmes së cilës do të kryhen procedurat e konfigurimit.
Aktiv motherboard kompjuterë modernë Nuk ka portë COM, kështu që kërkohet një përshtatës i veçantë për ta konfiguruar atë. Cisco përdor lidhësit Mini-USB në pajisjet e saj të konsolës. Për të konfiguruar nëpërmjet portës Mini-USB, shkarkoni programin e drejtuesit të konsolës USB cisco.
Vendosja e Hyper Terminal
Nëse procedura e konfigurimit kryhet duke përdorur sistemi operativ Windows 7/8, atëherë do të ketë një problem të mungesës së HyperTerminal. Mund të zgjidhet shpejt duke kopjuar dosjen e dëshiruar nga Windows XP në çdo drejtori të Windows 7/8. Në Windows XP, dosja ndodhet në drejtori Dosje programesh. Për të ekzekutuar programin, përdoret skedari hypertrm.exe, i cili ndodhet në të njëjtën dosje. Mund të përdoret gjithashtu një program tjetër, Putty. Përveç lidhjes me pajisjet Cisco, përdoret për të punuar me ruterë, serverë, kur ato duhet të lidhen me konfigurimi ssh.
Për të kryer procedurën e ndërrimit, kablloja duhet të lidhet me lidhësin RJ-45, i cili është emërtuar "Konsola" në panelin e përparmë. Tjetra, duhet të ndizni furnizimin me energji të çelësit dhe të shkoni te HyperTerminal në kompjuter. Në program, duhet të zgjidhni ndërfaqen e lidhësit që korrespondon me COM1 dhe shpejtësinë e tij të barabartë me 9600 B / s. Të gjitha pyetjet pasuese duhet të përgjigjen me "Jo" negative. Nëse zgjidhni cilësimin VLAN në ndërfaqen e lidhësit, mund të konfiguroni adresën IP të pajisjes në të.
Parime të përgjithshme për konfigurimin e pajisjeve Cisco
Për të siguruar një nivel të lartë sigurie, çelsat Cisco mbështesin dy mënyra të hyrjes së komandave:
- me porosi - përdoret për të kontrolluar gjendjen e pajisjeve;
- i privilegjuar - përdoret për të ndryshuar konfigurimin e çelësit (është analoge me modalitetin e administratorit për Windows ose root për UNIX).
Nëse ka një karakter "#" në rreshtin përpara komandës, atëherë modaliteti i privilegjuar është aktiv. Ashtu si në një sistem UNIX, kur futni një fjalëkalim në ekran, ai nuk do të shfaqet. Përdorni komandën enable për të hyrë në modalitetin e privilegjuar dhe çaktivizoni për të dalë.
Konfigurimi fillestar i ndërprerësit. Kur, gjatë nisjes së parë, magjistari i instalimit shfaq një mesazh konfigurimi hap pas hapi duhet ta refuzoni: Vazhdoni me dialogun e konfigurimit? : jo. Pas kësaj do të ngarkohet modaliteti i përdoruesit:Switch>
switch>aktivizo
Për të bërë cilësime që zbatohen për të gjithë çelësin, duhet të aktivizoni modalitetin e konfigurimit global. Për të konfiguruar ndërfaqet individuale, përdorni modalitetin e duhur të ndërfaqes.
Cilësimet bazë të Cisco 2960
Zëvendësimi i emrit të çelësit (fillimisht është Switch):
Ndërprerës # konfiguroni terminalin
Switch(config)# emri i hostit Switch01 (emri i ri është vendosur në Switch01)
Switch01(konfigurim)#
Nëse ka shumë ndërprerës, atëherë secili prej tyre duhet të ketë një emër unik. Në të ardhmen, kjo do të ndihmojë në përcaktimin se konfigurimi është zbatuar në pajisjen që nevojitet. Emra të gjatë përdorimi nuk rekomandohet, është më mirë të zgjidhni ato të shkurtra.
Vendosja e adresës IP për portin e menaxhimit të ndërprerësit
Switch01(config)# ndërfaqe fa0/0 (cakto ndërfaqen për të konfiguruar)
Switch01(config-if)# pa mbyllje (ndërfaqja është e ndezur)
Switch01(config-if)# adresa ip 192.168.0.1 255.255.255.0 (specifikoni adresën IP dhe maskën)
Switch01(config-if)# dalje (dalja nga modaliteti i konfigurimit të ndërfaqes)
Switch01(konfigurim)#
Vendosja e një fjalëkalimi të modalitetit të privilegjuar
Switch01(config)# aktivizo kalimin sekret1234 (fjalëkalimi1234)
Switch01(config)# dalje
Duke marrë parasysh që informacioni gjatë lidhjeve telnet transmetohet në mënyrë të qartë, ju duhet të përdorni lidhje SSH që do të ofrojnë kriptim të trafikut.
Switch01# conf t Switch01(config)# emri i domenit ip geek-nose.com (domeni është vendosur, nëse nuk ekziston, shkruhet ndonjë)
Switch01(config)# çelësi kripto gjeneron rsa (gjenerimi i çelësit RSA nën ssh)
Switch01(config)# ip ssh versioni 2 (versioni i protokollit ssh)
Switch01(config)# ip ssh authentication-riprovon 3 (numri i përpjekjeve për lidhje ssh)
Switch01(config)# shërbim me fjalëkalim-kriptim (ruani fjalëkalimet në formë të koduar)
Switch01(config)# rresht vty 0 2 (kaloni në modalitetin e konfigurimit dhe linjat e terminalit)
Switch01(config-line)# hyrje transporti ssh (lidheni vetëm përmes ssh)
Switch01(config-line)# exec timeout 20 0 (aktivizo shkëputjen automatike të sesionit ssh pas 20 minutash)
Switch01 (linja e konfigurimit) # fundi (Dalja nga modaliteti i konfigurimit)
Switch01# copy running-config startup-config (Ruaj cilësimet)
Ishte konfigurimi bazë SSH. Më e avancuar duket si:
Switch01# conf t Switch01(config)# aaa-model i ri (aktivizo protokollin AAA)
Switch01(config)# privilegj rrënjës i emrit të përdoruesit 15 kalim sekret1234 (i krijuar përdorues rrënjë, Me niveli maksimal privilegjet - 15 dhe fjalëkalimi1234)
Switch01(config)# access-list 01 permit 192.168.0 0.0.0.255 (vendos një rregull aksesi të quajtur 01 nëpërmjet ssh për të gjithë hostet në rrjetin 192.168.0.0/24; mund të vendoset një adresë IP specifike)
Switch01(config)# rresht vty 0 2 (kaloni në modalitetin e konfigurimit të linjës terminale) Switch01(config-line)# niveli i privilegjit 15 (aktivizoni qasjen në modalitetin e privilegjuar)
Switch01(config-line)# Access-class 23 in (lidhja e rregullit të krijuar të aksesit ssh me linjën e terminalit)
Switch01(config-line)# logging sinkron (çaktivizo mesazhet e regjistrimit)
Switch01 (linja e konfigurimit) # fundi (dalja nga modaliteti i konfigurimit)
Switch01# copy running-config startup-config (ruaj cilësimet).
Konfigurimi bazë Ndërprerës Cisco 2960 përfundon këtu. Nëse është e nevojshme, gjithmonë mund t'i rivendosni cilësimet e fabrikës dhe t'i kryeni cilësimet nga e para.
Instaloni SSH
Për pajisjet e rrjetit, ky hap nuk është i nevojshëm - Mbështetje SSH pothuajse gjithmonë i integruar edhe në versionin më minimalist të OS. Përjashtimi i vetëm është varianti mjaft i vjetër Cisco IOS W/O CRYPTO.
Të Varianti IOS- me heqjen e qëllimshme të të gjitha gjurmëve edhe të parëndësishme të asaj që lidhet me kriptografinë (deri në mungesë të (konfigurimit) #enable sekret) nevojitej për eksport në vendet me legjislacion të rreptë përsa i përket importit të kriptografisë. Nga rruga, kjo nuk është vetëm Kuba e dukshme + Koreja e Veriut + Siria + Irani, por edhe, për shembull, Australia.
Nëse keni një IOS të ngjashëm - mund të jetë, për shembull, në një Catalyst 2950, i cili, megjithëse i lashtë, mund të haset në prodhim - përditësoni atë. Pa përditësuar, veçoritë e nevojshme për SSH, në veçanti:
- Klient i integruar i Secure Shell SSH Version 1;
- Mbështetja e serverit Secure Shell SSH Version 1;
- Mbështetja e serverit Secure Shell SSH Version 2;
nuk do të jetë fizikisht i pranishëm në IOS.
Shtimi i mbështetjes SSH në Windows Server
Duke filluar me Windows Server 2016 build 1709, mbështetje SSH e shtuar në platformën Windows.
Është e lehtë për ta ndezur atë.
Para së gjithash, le të zbulojmë se cili version i klientit dhe serverit OpenSSH është në depot e disponueshme për instalim tani. Kjo është e nevojshme në mënyrë që kur versionet të fillojnë të rriten (në momentin e shkrimit, ekziston vetëm një version, 1.0), atëherë nuk do të kemi probleme si "diçka që skripti që instalon një version specifik nuk funksionon". Le ta bëjmë si kjo cmdlet:
Get-WindowsCapability -Online | ? Emri -si "OpenSSH*"
Unë kam Windows Server 2019, kështu që dalja duket si kjo:
Ne shohim që klienti SSH është instaluar tashmë fillimisht, por serveri SSH jo. Për Windows Server 2016, dalja do të jetë paksa e ndryshme, asgjë nuk është instaluar atje fillimisht. OK, le të instalojmë një server SSH:
Add-WindowsCapability -Online -Emri OpenSSH.Server~~~~0.0.1.0
Klienti, siç është e qartë, nëse mungon, atëherë vendoset në të njëjtën mënyrë. Tild - katër copë, mos vulosni.
Nëse merrni gabimin 0x800f0950, mos u dëshpëroni - është thjesht se Feature-On-Demand nuk mund ta gjejë depon. Provojeni me DISM të mirë të vjetër:
dism /Add-Capability /CapabilityName:OpenSSH.Server~~~~0.0.1.0 /LimitAccess /Online
Le të kontrollojmë nëse gjithçka është instaluar:
Get-Service sshd
mirë, ose thjesht pyet përsëri Get-WindowsCapability -Online | ? Emri si "OpenSSH*" :
Nëse gjithçka është në rregull, atëherë ne kemi shërbimin sshd - megjithatë, i ndaluar. Mos e ndizni menjëherë - së pari duhet ta mbani cilësimet minimale, për të cilën do të jetë në seksionin përkatës të artikullit.
Rregullimi i versionit SSHv2
Kopshti zoologjik fillestar i versioneve SSH - SSH 1.3, më pas SSH 1.5, më pas "një version i veçantë nga Cisco, që tregon se serveri mund të bëjë si 2.0 ashtu edhe ato të mëparshme", që është 1.99 - është plotësisht i parëndësishëm tani, sepse i gjithë softueri mund të SSHv2. Gjetja e softuerit që mbështet vetëm SSH 1.x është reale detyrë e vështirë. Prandaj, sigurisht, sigurohuni që të mos keni një softuer të tillë dhe përditësoni nëse është e nevojshme - por ne do të shqyrtojmë vetëm funksionalitetin dhe sigurinë e versionit të dytë të SSH.
Aktivizo SSH 2.x në Cisco IOS
Është rregulluar thjesht - për Cisco IOS do të jetë komanda:
atraining(config)#ip ssh versioni 2
Nëse në ky moment Nëse nuk keni krijuar ende ndonjë çift çelësash të përshtatshëm për SSHv2, atëherë mesazhi do të jetë diçka e tillë:
Ju lutemi krijoni çelësat RSA për të aktivizuar SSH (dhe të paktën 768 bit për SSH v2).
Kjo nuk është e tmerrshme, përveç që vërejmë se SSHv2 ka kërkesa "më të ulëta" për gjatësinë e çelësit në çiftin e çelësave. Sidoqoftë, ne nuk do të përpiqemi të krijojmë çelësa që nuk bien nën këtë kufizim - ditët kur, për shembull, çelësat 512-bit RSA përdoreshin në mënyrë aktive, kanë ikur.
Nëse çelësat nuk janë krijuar ende, atëherë kjo bëhet thjesht:
atraining(config)#crypto key gjeneron rsa modulus 2048 label SSH_KEYS
Parametrat janë të thjeshtë - rsa do të vendosë algoritmin (në iOS i ri shtohet varianti ec), moduli është gjatësia e bitit (mund ta vendosni në 4096, sigurisht që do të jetë më i sigurt), etiketa është për të krijuar një çift çelësash "të emërtuar për një qëllim specifik".
Disa versione të Cisco IOS kanë një kufi në çiftet e çelësave të ruajtur - deri në 10 për pajisje dhe deri në 2 për përdorues - kështu që mund të shfaqet një paralajmërim si "vëmendje, një çift i ri çelësash do të mbishkruajë atë të mëparshëm". Ndiqni atë.
Tani le t'i themi SSH që të përdorë pikërisht këtë çift:
atraining(config)#ip ssh rsa emri i çiftit të çelësave SSH_KEYS
Nëse gjithçka është në rregull, do të marrim diçka si kjo:
%SSH-5-DISABLED: SSH 2.0 është çaktivizuar
%SSH-5-ENABLED: SSH 2.0 është aktivizuar
Kjo do të tregojë se kalimi nga "çdo çelës" në "çift i specifikuar në mënyrë eksplicite" ishte i suksesshëm.
Nëse ne gjithashtu duhet ta raportojmë atë tek këtë pajisje duhet të lidhet vetëm duke përdorur SSH, jo telnet, për shembull, atëherë kjo bëhet si më poshtë - së pari kalojmë në modalitetin e konfigurimit VTY:
atraining(config)#line vty 0 5 (ose line vty 0 15 - varur nga modeli)
dhe specifikoni në mënyrë eksplicite që lidhjet hyrëse duhet të jenë ekskluzivisht përmes SSH:
atraining(config-line)#transport input ssh
Aktivizo SSH 2.x në Cisco NX-OS
Do të jetë e lehtë me Cisco Nexus - ata mbështesin vetëm SSH 2.x, kështu që veprime shtesë për të kufizuar lidhjen me versionet më të vjetra të SSH - nuk nevojitet.
Mos harroni të aktivizoni në mënyrë eksplicite përdorimin e SSH:
Nëse nuk ka çelësa, atëherë mund t'i krijoni në mënyrë eksplicite, menjëherë me gjatësinë e dëshiruar dhe me algoritmin e dëshiruar. Për ta bërë këtë, fikni SSH, gjeneroni çelësa dhe aktivizoni SSH - atëherë ai menjëherë do të "marr" të reja:
atraining-nx(config)#no feature ssh
tasti atraining-nx(config)#ssh rsa 2048
atraining-nx(config)#feature ssh
Parametrat e çelësit ssh janë të parëndësishëm, përveç që vërej se çelësat e vjetër nuk do të mbishkruhen automatikisht, nëse është e nevojshme, ato duhet të mbishkruhen - shtoni në fund të komandës së forcës
Aktivizo SSH 2.x në sshd
Në cilësimet sshd, do të na duhet të shtojmë (ose zëvendësojmë) rreshtin:
Aktivizo SSH 2.x në Windows Server
Në dosjen %WINDIR%\System32\OpenSSH\ do të ketë skedar standard konfigurimi i OpenSSH, sshd_config_default - dhe në teori mund të ketë një cilësim për "vetëm versionin e dytë", por në fakt vetëm SSHv2 përdoret gjithmonë. Kjo është arsyeja pse veprim të veçantë nuk ka asnjë mënyrë për të aktivizuar SSHv2 në Windows Server.
Tani le të kufizojmë listën e protokolleve që mund të përdoren për të vërtetuar kur një klient lidhet.
Kufizimi i listës së protokolleve të vërtetimit të serverit
SSH mbështet disa opsione për vërtetimin e hostit me të cilin po bëhet lidhja - duke përdorur algoritmet DSA, ECDSA, RSA dhe kurbën e zakonshme eliptike 25519.
Ne nuk na pëlqen DSA menjëherë, sepse. ajo njeh vetëm çelësat 1024 bit dhe ka një mendim të shprehur nga shoku Snowden se NSA nuk e do vetëm DSA-në në mënyrë aktive.
Prandaj, ne menjëherë ndërpresim mundësinë e përdorimit të DSA.
Ne rregullojmë në Cisco IOS përdorimin e RSA për identifikimin e hostit
Për Cisco do të jetë e thjeshtë:
atraining(config)#ip ssh server key key host ssh-rsa
Rregullimi i algoritmeve të identifikimit të hostit në sshd
Në cilësimet sshd, do të duhet të shkojmë në dosjen /etc/sysconfig/sshd dhe të korrigjojmë linjën AUTOCREATE_SERVER_KEYS atje:
AUTOCREATE_SERVER_KEYS="RSA ED25519"
Siç mund ta shihni, ky është cilësimi "në variantet e të cilave algoritme, çelësat pritës gjenerohen automatikisht". Unë vërej se nëse detyra është besueshmëri e lartë, atëherë RSA 4096-bit është zgjedhja e duhur, dhe nëse shpejtësitë - atëherë EC 25519 do të jetë i preferueshëm.
Pas kësaj, le të shkojmë te drejtoria e cilësimeve sshd - në versionin tonë do të jetë /etc/ssh - dhe fshijmë skedarët e algoritmeve të papërdorura me çelësat pritës atje. Kjo është, nga një listë e formularit:
- ssh_host_dsa_key
- ssh_host_dsa_key.pub
- ssh_host_ecdsa_key
- ssh_host_ecdsa_key.pub
- ssh_host_rsa_key
- ssh_host_rsa_key.pub
- ssh_host_ed25519_key
- ssh_host_ed25519_key.pub
lini vetëm të nevojshmet.
Nëse keni frikë të hiqni tepricën - mos kini frikë, në fillimin, shërbimi sshd do të lexojë skedarin e konfigurimit dhe do të krijojë ato që mungojnë, nëse është e nevojshme.
Pas kësaj në skedari i konfigurimit ju duhet të gjeni direktiva për përdorimin e këtyre skedarëve me çelësa - ato (direktivat) zakonisht duken kështu:
- HostKey /etc/ssh/ssh_host_rsa_key
- HostKey /etc/ssh/ssh_host_dsa_key
- HostKey /etc/ssh/ssh_host_ecdsa_key
- HostKey /etc/ssh/ssh_host_ed25519_key
dhe lini vetëm ato që ju nevojiten, duke komentuar pjesën tjetër duke shtuar simbolin # (të mprehtë) përpara rreshtave.
Nëse direktiva e përdorimit të skedarit mungon ose skedari nuk është i disponueshëm, atëherë algoritmi i duhur nuk mund të përdoret për të vërtetuar hostin, gjë që mund të çojë në probleme lidhjeje.
Për shembull, nëse lini vetëm modën Ed25519 dhe çaktivizoni RSA, atëherë PuTTY i përdorur gjerësisht mund të thotë diçka si kjo:
Kjo, meqë ra fjala, trajtohet duke përditësuar PuTTY në Versioni i fundit, i cili ka mbështetje për algoritme të reja. Kështu që bëjeni para kohe.
Duke u larguar vetëm llojet e dëshiruaraçelësat - zakonisht ED25519 dhe RSA - ju duhet t'i rikrijoni ato me dorë, d.m.th. kontraktimi "lëre serverin ta bëjë atë në rinisjen tjetër të shërbimit" nuk është një ide e mirë.
Bëhet kështu:
Për Ed25519: ssh-keygen -t ed25519 -f ssh_host_ed25519_key -N ""
Për RSA: ssh-keygen -t rsa -b 4096 -f ssh_host_rsa_key -N ""
Duke e bërë këtë hap me dorë, mund të jeni i sigurt se çelësi RSA do të jetë gjatësia e saktë dhe jo gjatësia e paracaktuar.
Kufizimi i protokolleve për vërtetimin SSH në Windows Server
Skema është e njëjtë - shkojmë te skedari sshd_config_default dhe lëmë vetëm:
- HostKey ssh_host_rsa_key
- HostKey ssh_host_ed25519_key
Nëse është e nevojshme, si Ed25519 ashtu edhe RSA, ose në përgjithësi vetëm Ed25519. Pas kësaj, ne gjenerojmë çelësat:
Për Ed25519: .\ssh-keygen -t ed25519 -f ssh_host_ed25519_key
Për RSA: .\ssh-keygen -t rsa -b 4096 -f ssh_host_rsa_key
.\ssh-shto ssh_host_ed25519_key
Në parim, gjithçka, shërbimi sshd mund të fillohet.
Paterica e markës nga Microsoft
Fryti i mendjes së errët zhvilluesit e Microsoft- një patericë për përshkrimin e të drejtave të skedarëve me çelësa. Rekomandohet ta ekzekutoni atë, por nëse jeni mendërisht të shëndetshëm dhe mendoni se shërbimi duhet të ketë të drejta për skedarët kryesorë që përdor, mund të bëni pa të. Megjithatë, nëse ka ndonjë gjë, është vendosur kështu:
Install-Module -Force OpenSSHUtils
Riparimi-SshdHostKeyPermission -FilePath
Do të kërkojë NuGet dhe në përgjithësi... shikojeni vetë:
vlerësoni nivelin audienca e synuar, e cila për këto veprime ju duhet të shkarkoni paketën e moduleve dhe të ekzekutoni cmdlet - d.m.th. jo për të ndezur trurin dhe për të shpërndarë të drejtat, por për të mësuar përmendësh komandën - mund ta bëni vetë. Jam i sigurt se Microsoft do të lëshojë disa MVP për këtë modul.
Tani në lidhje me shkëmbimin e informacionit kryesor.
Vendosja e shkëmbimit të çelësave / gjenerimi i materialit kyç
Ka shumë variante të DH, ose algoritmit Diffie-Hellman-Merkle. Pa u thelluar në material sipas vetë algoritmit në këtë artikull, le të shohim se si mund ta forcojmë pjesën e përparme nga kjo anë.
Shkëmbimi i çelësave dhe gjenerimi i përbashkët i materialit kyç për një seancë të caktuar është një temë shumë serioze në siguri. Detyra jonë është të shmangim opsionin kur do të kemi një skenar të "autentifikimit të fortë, por jo shkëmbimit të çelësave".
Le të shohim se si aktualisht kemi DH të konfiguruar në SSH në Cisco IOS:
atraining#sh ip ssh | duke përfshirë Diffie
Madhësia minimale e pritur e çelësit Diffie Hellman: 1024 bit
Keq. Ju duhen të paktën 2048 bit. E vendosim me komandën:
atraining(config)#ip ssh dh min madhësia 2048
Kështu që zgjidhni vetë - SHA-512, me mbështetje për të në të gjitha pajisjet e përdorura, do të jetë zgjidhja më e mirë.
Por ka një hollësi - mënyra e përdorimit të hash dhe enkriptimit.
Si parazgjedhje, SSH përdor një variant të quajtur Encrypt-and-MAC - MAC i shtohet të dhënave të koduara, të cilat u konsideruan nga të pakriptuara. Në këtë rast, për të kontrolluar MAC, së pari duhet të deshifroni bllokun e marrë të informacionit në mënyrë që të merrni tekstin e thjeshtë, dhe më pas të llogarisni dhe krahasoni hash-et. Ky opsion bën të mundur sulmin ndaj algoritmeve të kriptimit dhe marrjen e të dhënave "të ndërmjetme" në rast të një kompromisi të sistemit të synuar.
Opsioni më i mirë për sa i përket sigurisë do të ishte Encrypt-Then-MAC. Pse? Në rastin kur përdoret skema "hash nga tashmë i koduar", para së gjithash kontrollohet integriteti dhe nëse diçka nuk shkon, të dhënat hidhen menjëherë; nuk ndodh deshifrimi provë. Variante të tilla MAC do të kenë prapashtesën -etm. Me këto pika në mendje, konfigurimi ynë do të duket kështu:
MAC [email i mbrojtur],[email i mbrojtur]
Në Cisco Lloji iOS MAC do të vendoset si kjo:
atraining(config)#ip ssh algoritmi i serverit mac hmac-sha1
Cisco IOS ka një zgjedhje të kufizuar - hmac-sha1 dhe hmac-sha1-96. Opsioni i dytë me prerjen e daljes SHA-1 nga 160 bit në 96 (si në ipsec) nuk do të funksionojë për ne, sepse llogaritet me të njëjtën shpejtësi (ju duhet ende të llogaritni SHA-1 të zakonshme), dhe duke kursyer trafikun - Epo, ah, aspak.
MAC për llogaritjen e çelësit të gjurmëve të gishtërinjve
Në OpenSSH, ne gjithashtu mund të vendosim algoritmin me të cilin do të llogaritet "gjurma e gishtit" - gjurma e gishtit të çelësit. Parazgjedhja është MD5 - megjithatë, do të ishte më mirë të tregohet në mënyrë eksplicite se është më mirë të përdoret SHA-2/256 për të shfaqur dhe krahasuar hash-et kryesore:
Gjurmët e gishtaveHash sha256
Tani le të kalojmë nga pjesa kriptografike në pjesën e rrjetit.
Cilësimet e rrjetit SSHv2
Do të ketë shumë cilësime rrjeti, por shumica e tyre janë të parëndësishme - "çfarë të përdorni" dhe "si të filtroni trafikun", kështu që nuk ka kuptim të filloni një seksion për secilën.
Blloku do të duket diçka si kjo:
Porti 22
Adresa Familja inet
IgnoreRhosts po
Përdorni DNS nr
Dëgjo Adresa x.x.x.x
TCPKeepAlive po
#VerifyHostKeyDNS nr
#Përdor Roaming nr
Disa nga cilësimet janë të qarta - për shembull, Porta 22 lidh shërbimin SSH me numrin e portit të specifikuar, i cili mund të ndryshohet nëse është e nevojshme - të paktën në mënyrë që bots-et e hamendësimit të fjalëkalimit të mos trokasin dhe ListenAddress tregon qartë se cilat adresa L3 duhet të pranohen kërkesat për lidhje (kufizimi është i rëndësishëm në rastin e adresave të shumta dhe/ose ndërfaqeve të rrjetit, ose në skenarin "host mund të ketë të reja ndërfaqet e rrjetit, dhe kjo nuk do të thotë që ju duhet të prisni për lidhje SSH në to”). Cilësimet e tjera janë më pak të dukshme.
AddressFamily inet thotë se ne do të presim vetëm lidhjet IPv4. Nëse jeni duke përdorur IPv6 dhe lidhjet me serverin SSH janë të mundshme nëpërmjet tij, shtoni AddressFamily inet,inet6.
TCPKeepAlive po do të jetë i nevojshëm për të shtresa e rrjetit identifikoni përdoruesit e shkëputur dhe përfundoni seancat e tyre. Çaktivizimi i këtij mekanizmi, i cili ndonjëherë rekomandohet "për të kursyer trafikun" (lot, jo kursime), do të çojë në një situatë ku ssh nuk do të jetë në gjendje të kuptojë në disa raste se përdoruesi nuk është thjesht joaktiv, por kurrë nuk do të jetë në gjendje të vazhdojnë punën në këtë seancë. Kështu që ne e ndezim atë.
IgnoreRhosts po çaktivizon mekanizmin e lashtë për krijimin e një liste hostesh (zakonisht në një skedar .rhosts) nga i cili lejohen hyrjet e paautenifikuara.
UseDNS no do të nevojitet për të çaktivizuar kontrollin e regjistrimit PTR për pajtimtarin lidhës - përveç faktit që gjatë rrjeti i brendshëm, dhe kur lidheni nga jashtë, prania e PTR është gjithashtu plotësisht opsionale, këtë masë ai vetëm ngadalëson lidhjen, por nuk e ngre nivelin e sigurisë - maksimumi që bën është të shkruajë një paralajmërim në regjistër se "lidhja nuk e tha emrin e tij të vërtetë FQDN". Edhe pse është e mundur që ky kontroll të jetë i aktivizuar dhe DNS në host nuk funksionon (për shembull, tregon adresën e gabuar IP të serverit DNS), në këtë rast është e mundur që nuk do të jeni në gjendje të lidheni te pritësi. Por kjo nuk është aspak një “masë mbrojtëse”, por një arsye tjetër për të çaktivizuar këtë kontroll, sepse. për shkak të tij, rezulton, numri i nënsistemeve të përfshira po rritet, dhe për këtë arsye besueshmëria e përgjithshme e sistemit po bie.
E përdorur, nuk keni nevojë ta fikni. Është në logjikën e vet vendosjen e klientit, por për disa arsye ndonjëherë ka mendime "aktivizoni atë në server". E shtova në këtë listë dhe e komentova për të theksuar këtë pikë - nuk keni nevojë ta specifikoni këtë opsion në cilësimet e serverit.
UseRoaming nuk çaktivizon mbështetjen për roaming, një zgjerim eksperimental OpenSSH që supozohej të trajtonte skenarë të tillë si "filloi administratori nga një vend, pastaj u zhvendos në një tjetër dhe vazhdoi prej andej". Në fakt, askush nuk kishte nevojë për këtë funksionalitet dhe nuk shtoi ndonjë risi përparimtare, por solli probleme sigurie - deri në dobësi me PoC -. Prandaj, ne e çaktivizojmë në mënyrë të qartë. Ashtu si parametri i mëparshëm - klienti, d.m.th. është renditur këtu sepse, përsëri, në një numër udhëzuesish është shkruar "fik kudo, si në klient ashtu edhe në server". Nuk është, vetëm për klientin.
Kufizimet SSH në procedurën e lidhjes së sesionit
Procesi i lidhjes me një seancë gjithashtu duhet të përpunohet, sepse. se përdorimi i metodave "të pazakonta" të lidhjes, sigurimi i informacionit të panevojshëm për klientin lidhës, shpenzimi i burimeve të serverit për mbajtjen e shumë kërkesave "paralele" nuk është i nevojshëm.
Blloku i cilësimeve tona për të gjithë këtë do të duket si ky:
RhostsRSAA autentifikimi nr
PubkeyAutentifikimi nr
HostbaseAuthentication nr
ChallengeResponseAutentifikimi nr
KerberosAutentifikimi nr
Vërtetimi i fjalëkalimit po
LoginGraceTime 15
ClientAliveInterval 1800
ClientAliveCountMax 0
MaxAuth Provon 3
MaxSessions 1
LejeTuneli nr
MaxStartups 10:50:20
ShowPatchLevel nr
Le të kuptojmë se çfarë dhe si.
Blloku i RhostsRSAA Authentication nr, PubkeyAuthentication nr, HostbaseAuthentication nr, ChallengeResponseAuthentication nr, KerberosAuthentication nuk çaktivizon metodat e vërtetimit të papërdorura. Sigurisht, nëse përdorni, të themi, Kerberos për t'u identifikuar në serverin SSH, atëherë nuk keni nevojë të çaktivizoni Kerberos. Por në skenar tipik, kur hyrja kryhet në mënyra më të zakonshme, teprica duhet të çaktivizohet në mënyrë të qartë.
Parametri LoginGraceTime tregon se sa kohë mund të shpenzojë përdoruesi në procedurën e hyrjes. Parazgjedhja është 2 minuta. Kjo është shumë. Një përdorues shumë i ngadalshëm duhet të jetë i tillë që t'i duhet kaq shumë kohë për t'u identifikuar. Prandaj, ky parametër është vendosur në 15 - mund të futni në 15 sekonda. Nëse keni nevojë për më shumë - mund të rriteni, por në mënyrë të arsyeshme. Më e rëndësishmja, serveri do të "rivendos" seancat që kanë filluar, por nuk kanë përfunduar ende vërtetimin më shpejt dhe do të kursejë burime.
Analogu i Cisco IOS i LoginGraceTime është komanda atraining(config)#ip ssh time-out, e cila vendos koha maksimale për procedurën e hyrjes. Parazgjedhja është gjithashtu 2 minuta, që është gjithashtu shumë dhe duhet reduktuar. Në rastin e Cisco NX-OS, kjo do të ishte atraining-nx(config)#ssh login-gracetime .
Një palë cilësimesh ClientAliveCountMax dhe ClientAliveInterval do të nevojiten për të përcaktuar se kur duhet çaktivizuar një klient joaktiv. ClientAliveInterval është koha e pasivitetit në sekonda pas së cilës klienti do të shkëputet, dhe ClientAliveCountMax është numri i përpjekjeve për të "zgjuar" klientin. Në rastin tonë, klienti do të shkëputet pas gjysmë ore pasiviteti.
Parametri MaxAuthTries tregon se sa përpjekje për vërtetim të pasuksesshëm (për shembull, futja e fjalëkalimit të gabuar) sesioni do të shkëputet nga serveri. Parazgjedhja është 6, që është shumë. tri herë mjaft.
Ekuivalenti i MaxAuthTries në Cisco IOS është komanda atraining(config)#ip ssh authentication-retries, me një parazgjedhje prej 3 përpjekjesh.
Parametri MaxSessions tregon sa seanca brenda së njëjtës lidhje SSH mund të inicializohet. Ky nuk është një kufizim për "seancat paralele nga i njëjti host"! Kjo është pikërisht “vendosni një tub SSH në server dhe brenda tij ju multipleksoni shumë seanca me përcjelljen e të dhënave”. Nëse nuk ju nevojitet një skenar i tillë - kur lidheni me serverin X dhe kaloni trafikun thellë në rrjet përmes tij, atëherë mjafton një - dhe ju vetëm duhet të lidheni me një server specifik dhe ta administroni atë, atëherë MaxSessions 1, po . Parametri PermitTunnel no do të përfundojë konfigurimin e modalitetit "ssh vetëm për administrimin e serverit me të cilin po lidhemi".
MaxStartups 10:50:20 është një mekanizëm i ngjashëm me WRED, familja e të cilit diskutohet dhe logjika për konfigurimin e tij do të jetë si më poshtë - vlerat e para dhe të fundit janë numri fillestar i lidhjeve (po flasim vetëm për lidhjet që nuk janë vërtetuar), duke filluar nga i cili mekanizmi do të fillojë të funksionojë numrin maksimal të lidhjeve të mundshme (në rastin tonë, mekanizmi do të ndizet kur të ketë 10 lidhje me serverin dhe lidhja e 21-të do të të jetë teknikisht e pamundur), dhe parametri mesatar është probabiliteti në përqindje. E kemi 50, d.m.th. Ne do të refuzojmë në gjysmën e rasteve kur numri i seancave “varur në fazën e vërtetimit” do të jetë nga 10 në 20.
Mund ta bëni edhe më thjeshtë - për shembull, MaxStartups 10 , d.m.th. vendosni MaxStartups me një parametër. Thjesht do të tregojë numri maksimal seancat e vërtetuara njëkohësisht.
Ekuivalenti me një parametr i MaxStartups N në Cisco IOS është komanda atraining(config)#ip ssh maxstartups N, ku N është i njëjti numër maksimal i seancave të vërtetuara njëkohësisht.
Me komandën ShowPatchLevel pa, ne do ta çaktivizojmë publikimin informacion i detajuar në lidhje me versionin SSH me klientin lidhës.
Tani le të kalojmë në bllokun e cilësimeve që lidhen me llogaritë.
Grupet dhe përdoruesit në konfigurimin e serverit SSH
Është mjaft e qartë se ne duhet të tregojmë disi në mënyrë eksplicite se kush mund të lidhet me ne dhe çfarë kërkesash do të parashtrohen për këtë dikë.
AllowUsers admin admin2
AllowGroups nixadmins
DenyUsers nginx
DenyGroups nginx
PermitEmptyPasswords nr
PermitRootLogin nr
UsePrivilegeSeparation sandbox
Nuk ka gjithashtu asgjë veçanërisht befasuese këtu, të gjithë parametrat janë emërtuar mjaft saktë - përveç që do të ndalem në një ndalim të qartë të hyrjes përmes ssh për llogaritë dhe grupet e shërbimit (në tim shembull nginx). Mos u bëni dembel ta përshkruani në mënyrë eksplicite, të tilla Llogaritë ndryshojnë jashtëzakonisht rrallë, dhe rrjeta e sigurisë nuk dëmton. Po, dhe mos punoni si rrënjë, pa marrë parasysh sa e parëndësishme mund të tingëllojë.
Në versionin me Cisco IOS, nuk ka kuptim të bëni cilësime të tilla në nivel lokal në pajisje, sepse është më logjike të përdorni AAA dhe të ridrejtoni kërkesat për vërtetim dhe autorizim përmes RADIUS / TACACS në një server të centralizuar, ose (në IOS të ri) të shkoni direkt në ruajtjen LDAP me kërkesat "a ka një përdorues të tillë". Prodhimi i bazave të të dhënave lokale në secilën pajisje është i papërshtatshëm dhe i pasigurt. I gjithë ky mekanizëm nuk është i lidhur me SSH, por është një mënyrë më e përgjithshme e ridrejtimit të kërkesave për vërtetim / autorizim, kështu që nuk përshkruhet këtu në mënyrë që artikulli të mbetet për SSH, dhe jo "për gjithçka që mund të lidhet me SSH".
Sidoqoftë, për sa i përket fjalëkalimeve, ende nuk është e dëmshme të bësh cilësimin - komandën
atraining(config)#security password min-length N
cakton gjatësinë minimale të fjalëkalimeve në këtë pajisje.
Cilësimi UsePrivilegeSeparation sandbox do t'i tregojë në mënyrë eksplicite ssh se një proces i veçantë sshd me privilegje minimale do të krijohet për çdo lidhje hyrëse - dhe pas autorizimit të suksesshëm, do të krijohet një i ri, i cili do të përpunojë seancën e një përdoruesi specifik të lidhur. Kjo zvogëlon humbjet kur shfaqet një cenueshmëri e re në mekanizmin e lidhjes sshd - ai që e shfrytëzon këtë dobësi, edhe nëse procesi ssh kapet, do të marrë një minimum të drejtash në sistem.
Përmbledhje
Shpresoj që kjo listë e vogël kontrolli të jetë e dobishme për ju. SSH përdoret jashtëzakonisht gjerësisht, aq i konfiguruar në mënyrë të parashikueshme dhe akses të sigurt përmes tij - themeli për një infrastrukturë të besueshme rrjeti.
Data e tekstit të fundit të modifikuar:
