Dacă lucrați în IT, probabil că v-ați confruntat de o mie de ori cu nevoia de a vă conecta la un dispozitiv sau un server de la distanță - o astfel de sarcină poate fi efectuată în mai multe moduri, principalele două sunt pentru controlul unui dispozitiv prin linia de comandă - Telnetși Shell securizat (SSH).

Există o diferență principală între ele - în protocol Telnet toate datele sunt transmise prin rețea în formă necriptată, iar în cazul SSH toate comenzile sunt criptate cu o cheie specială. SSH a fost dezvoltat ca înlocuitor pentru Telnet pentru a gestiona în siguranță dispozitivele de rețea printr-o rețea nesigură, cum ar fi Internetul. Pentru orice eventualitate, amintiți-vă că Telnet folosește portul 22 și SSH este 23 .

Personalizare

În primul rând, ai nevoie Packet Tracer- un program pentru emularea rețelelor de la compania Cisco. Este complet gratuit și poate fi descărcat de pe netacad.com după înregistrare. Lansați Packet Tracer și continuați cu configurarea.

Construiți topologia ca în captura de ecran de mai jos - un computer și un comutator Layer 3. Va trebui să le conectați împreună și să începeți configurarea.

Gata? Acum vom oferi conectivitate la rețea și vom configura interfața vlan 1 pe comutator, pentru a face acest lucru, introduceți următoarele comenzi:

Dacă imediat după creare în consola comutatorului există o întrebare dacă să porniți dialogul de configurare inițială - răspundeți „Nu”.

en conf t interfață vlan 1 adresa ip 192.168.1.1 255.255.255.0 fără oprire

Acum să încercăm să facem ping la comutator și la telnet de pe computerul nostru la comutator - și veți vedea că conexiunea va fi respinsă din cauza faptului că nu am configurat încă autentificarea pe switch.

Să trecem la configurarea autentificării. Sistemul acceptă 20 virtuale tty / vty linii pentru servicii Telnet, SSH și FTP. Fiecare sesiune care utilizează protocolul de mai sus ocupă o linie. De asemenea, puteți îmbunătăți securitatea generală prin validarea cererilor de autorizare pe dispozitiv. Reveniți la modul de configurare generală ( conf t) pe comutator folosind comanda exit și introduceți următoarele comenzi:

Line vty 0 15 parola Cisco login end

Parola Cisco folosită în acest articol este extrem de nesigureși servește exclusiv în scopuri demonstrative. Dacă lăsați o astfel de parolă pe hardware real, șansele de a fi piratat sunt nesfârșite. Mai bine foloseste-ne :)

Acum încercați să conectați din nou Telnet la comutator - totul ar trebui să meargă! Cu toate acestea, când încercați să treceți la configurarea și executarea comenzii de activare, veți vedea că acest lucru este imposibil, din cauza faptului că parola pentru modul global nu este setată. permite.

Pentru a remedia acest lucru, introduceți următoarele comenzi:

Conf. activați parola cisco

Încearcă din nou - ar trebui să fii bine acum!

Acum să configuram SSH pe comutator - pentru aceasta, trebuie să specificați numele de gazdă, numele domeniului și să generați o cheie de criptare.

Introduceți următoarele comenzi (din modul principal de configurare):

Nume gazdă merionet_sw1 nume de domeniu ip merionet cheia criptografică genera rsa

Selectați lungimea cheii - în mod implicit, valoarea este egală 512 biți, pentru SSH versiunea 2 lungimea minimă este de 768 de biți. Generarea cheii va dura ceva timp.

După generarea cheii, vom continua configurarea comutatorului:

Ip ssh versiunea 2 line vty 0 15 transport input ssh

Acum nu vă veți putea autentifica prin Telnet, deoarece l-am înlocuit cu SSH. Încercați ssh folosind administratorul de conectare implicit. Să-l schimbăm cu ceva mai decent (din nou de la conf t):

Nume utilizator admin secret cisco line vty 0 15 login local do wr

Acum încercați să vă conectați la comutator de la stația de lucru și asigurați-vă că noile setări au loc.

Ți-a fost de ajutor acest articol?

Te rog spune-mi de ce?

Ne pare rău că articolul nu v-a fost util: (Vă rog, dacă nu vă îngreunează, indicați de ce? Vă vom fi foarte recunoscători pentru un răspuns detaliat. Vă mulțumim că ne ajutați să devenim mai buni!

Întrebarea „cum se stabilește o conexiune la Cisco prin protocol SSH?" se întâmplă tuturor celor care întâlnesc acest echipament. Răspunsul este „Simplu!”
Să luăm ca exemplu modelul routerului Cisco 881... Comenzile pentru configurarea altor routere (1841, 2800, 3825 ...) sau comutatoare (2900, 3500, 4800 ...) vor fi similare. Singura diferență poate fi în setările interfeței. (Configurarea accesului la protocol SSH la firewall-uri Cisco ASA descris în articolul ""
Deci, la dispoziția noastră:

Sarcină: configurați o conexiune sigură la router Cisco prin protocol SSHși oferă o gestionare securizată de la distanță.

Pasul 0. Configurarea interfeței

Interfața trebuie să fie activată pe router pentru a fi utilizată pentru management. În cazul nostru va fi interior (LAN) interfață Fastethernet 0.

Pentru trimitere:
Pe router Cisco 881 există o singură interfață al 3-lea nivel Fastethernet 4(cel pe care poți seta imediat IP adresa) și comutator încorporat cu patru interfețe al 2-lea nivel ( Fastethernet 0 - Fastethernet 3). Pentru fiecare dintre aceste 4 interfețe, puteți lega unu (!) interfata virtuala al 3-lea nivel. ( Vlan).
Pentru interfața de gestionare a routerului, selectați prima adresă disponibilă în rețeaua de birou - 192.168.0.1 ... Apoi, accesați setările interfeței virtuale Vlan 1și atribuiți asta ip abordare. După aceea o legăm de unul dintre fizic interfețe de router ( Fastethernet 0) și porniți-l cu comanda nu închis.

Pentru claritate:
adresa ip => interfață Vlan X => interfață Fastethernet Y
Noi am stabilit ip adresa interfeței Vlan 1
R-DELTACONFIG (config.) #
interfața Vlan 1
adresa ip 192.168.0.1 255.255.255.0
nicio închidere
Lega Vlan 1 la interfața fizică FastEthernet 0
R-DELTACONFIG (config.) #
interfața Fa 0
vlan de acces switchport 1
nicio închidere
Ultimul pas este efectuat pentru a vă asigura că setările sunt corecte. Vlan 1 legat în mod implicit la fiecare interfață al 2-lea nivelul și linia vor fi afișate în configurație numai dacă numărul Vlan va fi diferit de 1.
Apoi, trebuie să verificați disponibilitatea interfeței create de la routerul însuși și apoi de la orice stație de lucru din birou, de exemplu, de la stația de lucru a unui administrator. O simplă verificare cu comanda va face. Ping... Desigur, interfața routerului Fastethernet 0 trebuie să fie conectat la un switch LAN (sau direct la computerul administratorului) iar adresa computerului de pe care se efectuează testul se află în aceeași rețea cu adresa interfeței routerului (de exemplu 192.168.0.10 ).

Pasul 1 Creați un cont de administrator

Pentru control de la distanță, trebuie să vă creați un cont, dacă nu există deja unul.
R-DELTACONFIG (config.) #
nume de utilizator secret de administrator *****
În loc de asteriscuri ******, setați parola pentru contul de administrator.

Important!
Conform regulilor bunei forme, parola este formată din litere mari și mici, numere și speciali. caractere, în același timp nu mai scurt de 8 caractere.

Pasul 2 setarea parolei pentru modul de configurare

Când deschideți consola de management a routerului, utilizatorul intră în modul simplificat, din care este posibil să vizualizați doar o parte dintre parametrii dispozitivului și informațiile tehnice despre acesta. În acest caz, lângă numele dispozitivului există un semn săgeată „ > »
R-DELTACONFIG>
Pentru a vizualiza configurația routerului și a o configura în continuare, introduceți comanda permite
> activați
#
Inițial, acest mod nu este protejat prin parolă și orice utilizator care s-a conectat cu un cablu de consolă (despre cablu și modul de conectare este descris în) va putea intra în modul de configurare... Pe de altă parte, utilizatorul care s-a conectat de la distanță ( ssh/telnet), pentru care nu este setat niciun nivel de privilegii (doar cazul nostru), nu va putea intra în modul de configurare.
Setați o parolă pentru modul privilegiat(semnul hash # lângă numele routerului) prin intrarea în modul de configurare ( conf t).
R-DELTACONFIG (config.) #
R-DELTACONFIG (config) # activare secret ******
Această parolă va fi aceeași pentru toți utilizatorii.
Puteți citi mai multe despre modurile de configurare.

Pasul 3. Activarea telecomenzii

Pentru controlul de la distanță, trebuie să specificați metoda de autentificare a utilizatorului cu comanda autentificare locală
R-DELTACONFIG (config.) #
linia vty 0 4
autentificare locală
După finalizarea acestui pas și cu condiția ca interfața de gestionare a routerului să fie disponibilă utilizatorului, devine posibilă conectarea la router folosind protocolul telnet... Pentru a face acest lucru, executați comanda din linia de comandă a stației de lucru a administratorului
C: \ Documente și setări \ ***> telnet 192.168.0.1
Ar trebui să existe o solicitare pentru utilizatorul și parola care au fost setate pasul 1... După autorizarea cu succes, acesta va fi disponibil simplificat modul de gestionare a routerului (cu săgeata " > "). A accesa privilegiat modul ( # ) trebuie să introduceți comanda permite, iar după parola de la pasul 2.

Pasul 4 Configurarea SSH

Când se utilizează protocolul Telnet(portul TCP 23) toate comenzile și datele de configurare a dispozitivului sunt transmise în text clar, care este potențial nesigur. Protocolul este folosit pentru a securiza conexiunea SSH(portul TCP 22).
Pentru a configura o conexiune de protocol SSH trebuie să setați un nume de domeniu (orice), să generați o cheie de acces criptografic și să activați protocolul în sine SSH versiunea 2.
R-DELTACONFIG (config.) #
site-ul nume de domeniu ip
cheie cripto genera rsa
Alegeți dimensiunea modulului cheii în intervalul de la 360 la 2048 pentru dvs
Chei de uz general. Alegerea unui modul cheie mai mare de 512 poate dura
câteva minute.
// după solicitare, trebuie să specificați 1024
Câți biți în modul: 1024
% Se generează chei RSA pe 1024 de biți, cheile nu vor fi exportabile...
ip ssh ver 2
După finalizarea acestui pas, devine posibilă conectarea prin SSH folosind un program special care acceptă această funcție, de exemplu chit... Puteți descărca acest link.

Pasul 5. Restricționarea conexiunii la router numai prin SSH

Pentru a exclude posibilitatea conectării la router prin protocol Telnet trebuie să introduceți următoarele comenzi:
R-DELTACONFIG (config.) #
linia vty 0 4
intrare de transport ssh
După aceea, accesul de la distanță la consola dispozitivului nu va fi posibil decât prin protocolul SSH.
În plus, puteți restricționa accesul la gestionarea unui router Cisco sau puteți comuta numai de la anumite adrese IP. Cum se face este descris.

Important!
Aveți grijă la accesarea dispozitivelor. Nu neglijați protecția conexiunii și restrângerea cercului de persoane autorizate să opereze.

Important!

Nu uita Salvați configurarea tuturor dispozitivelor cu comanda scrie sau începe executarea copiei... În caz contrar, după o repornire, toate modificările se vor pierde.
scrie
Configurația clădirii...

Protocolul SSH este adesea folosit pentru gestionarea de la distanță a routerelor și comutatoarelor. În special, pentru gestionarea echipamentelor de rețea Cisco. Configurarea acestui echipament pentru conectarea prin SSH va fi discutată în acest articol.

De ce SSH pentru Cisco

SSH este un protocol securizat care va descuraja hoții și hoții care doresc să preia echipamentul de rețea Cisco.

Dar configurarea corectă este esențială dacă doriți ca routerul să fie în siguranță.

Iar pentru Cisco, configurarea protocolului SSH se realizează conform unor reguli speciale, nu în același mod cu crearea administrării serverului de la distanță în Free BSD.

Cum se configurează conexiunea SSH pentru Cisco

Configurarea începe cu faptul că trebuie să intrați în modul privilegiat. Pentru a face acest lucru, utilizați următoarea comandă: cisco> enable. Cel mai bine este să utilizați o cheie publică pentru a vă conecta la echipament, de aceea este recomandat să generați RSA. Și pentru aceasta, în Cisco, trebuie să setați data și ora exactă, altfel cheia nu va funcționa: cisco # clock set 17:10:00 28 Aug 2016. După aceea, treceți la modul de modificare directă a configurației, pe care îl veți va trebui să creeze o conexiune prin protocolul SSH: cisco # configure terminal

Pentru a genera o cheie publică, va trebui să introduceți numele de domeniu sub care clientul se va conecta la echipamentul de rețea. Pentru a face acest lucru, utilizați comanda: cisco (config) # ip domain name domain_name.ru. După aceea, puteți genera o cheie RSA folosind următoarea combinație: cisco (config) # crypto key generate rsa. Dacă doriți să consolidați protecția echipamentului dvs. de rețea, puteți utiliza parole suplimentare, trebuie doar să activați mai întâi criptarea acestora folosind comanda: cisco (config) # service password-encryption.

Apoi, trebuie să creați un utilizator, să creați o parolă pentru acesta și să specificați nivelul de acces: cisco (config) # username username privilegie 15 password 7 password. Numai după ce ați creat cel puțin un utilizator pe sistem puteți porni protocolul AAA folosind următoarea comandă: cisco (config) # aaa new-model. Și pentru a lansa în sfârșit linii terminale prin protocolul SSH, trebuie să mergeți la configurația lor. Pentru a face acest lucru, scrieți: cisco (config) # line vty 0 4, unde puteți specifica valoarea configurației de la 0 la 4. După aceea, puteți activa conexiunea prin protocolul SSH - scrieți cisco (config-line) # transport input ssh.

Deși ați pornit deja linii terminale prin SSH, introduceți această funcție pentru a salva modificările: cisco (config-line) # logging synchronous și, de asemenea, notați valoarea pentru sesiunea SSH: cisco (config-line) # exec-timeout 60 0. După aceea, ieșiți din config-line și config. În cele din urmă, adăugați noi configurații la sistemul de echipamente de rețea Cisco: cisco # copy running-config startup-config. Asta este - treaba este gata, echipamentul dvs. va funcționa acum printr-o conexiune SSH sigură.

Conectarea și configurarea Cisco Catalyst 2960 are propriile sale nuanțe și este oarecum diferită de conectarea echipamentelor de la alți producători.

Conectarea și configurarea Cisco Catalyst 2960 are propriile sale nuanțe și este oarecum diferită de conectarea echipamentelor de la alți producători. Configurarea inițială va necesita un cablu plat proprietar RJ-45-RS-232 (în împletitură albastră, furnizat împreună cu echipamentul) și un port COM pe placa de bază a computerului prin care vor fi efectuate procedurile de configurare.

Nu există niciun port COM pe plăcile de bază ale computerelor moderne, așa că este necesar un adaptor special pentru a efectua configurarea. Cisco folosește conectori Mini-USB în hardware-ul consolei sale. Pentru a configura prin portul Mini-USB, descărcați programul de driver pentru consolă USB Cisco.

Configurarea Hyper Terminal

Dacă procedura de instalare este efectuată folosind sistemul de operare Windows 7/8, atunci va exista o problemă cu absența HyperTerminal. Poate fi rezolvată rapid prin copierea folderului necesar cu sistemul de operare Windows XP în orice director din Windows 7/8. În Windows XP, folderul se află în directorul Fișiere program. Pentru a rula programul, se folosește fișierul hypertrm.exe, care se află în același folder. Se poate folosi și un alt program, Putty. Pe lângă conectarea la echipamente Cisco, este folosit pentru a lucra cu routere, servere, atunci când este necesară configurația SSH pentru a le conecta.

Pentru a finaliza procedura de conectare, cablul trebuie conectat la conectorul RJ-45, care este etichetat „Consola” pe panoul frontal. Apoi, trebuie să porniți sursa de alimentare a comutatorului și să accesați HyperTerminal pe computer. În program, trebuie să selectați interfața conectorului corespunzătoare COM1 și viteza acesteia egală cu 9600 B / s. Pentru toate întrebările ulterioare, ar trebui să alegeți un răspuns negativ „Nu”. Dacă selectați setarea VLAN în interfața slotului, puteți configura adresa IP a dispozitivului pe aceasta.

Principii generale de configurare a echipamentelor Cisco

Pentru a asigura un nivel ridicat de securitate, switch-urile Cisco acceptă două moduri de introducere a comenzii:

• personalizat - folosit pentru a verifica starea echipamentului;
• privilegiat - folosit pentru a schimba configurația comutatorului (este analog modului administrator pentru Windows sau root pentru UNIX).

Dacă există un caracter „#” în linia de dinaintea comenzii, atunci modul privilegiat este activ. Ca și în cazul sistemelor UNIX, parola nu va fi afișată pe ecran când o introduceți. Comanda enable este folosită pentru a intra în modul privilegiat, iar disable este folosită pentru a ieși.

Configurația inițială a comutatorului. Când, în timpul primei porniri, asistentul de instalare afișează un mesaj de configurare pas cu pas, trebuie să îl refuzați: Continuați cu dialogul de configurare? : Nu. Aceasta va încărca modul personalizat: Comutare>

Comutare> activare

Pentru a configura setările la nivelul întregului comutator, trebuie să activați modul de configurare globală. Pentru a configura interfețele individuale, utilizați modul de interfață corespunzător.

Setări de bază Cisco 2960

Schimbați numele comutatorului (inițial este Switch):

Comutator # configura terminal

Switch (config) # hostname Switch01 (este setat un nume nou - Switch01)

Switch01 (config) #

Dacă există multe comutatoare, fiecare trebuie să aibă un nume unic. În viitor, acest lucru va ajuta la stabilirea faptului că configurația este implementată exact pe dispozitivul necesar. Nu este recomandat să folosiți nume lungi, este mai bine să alegeți cele scurte.

Setarea adresei IP pentru portul de administrare al comutatorului

Switch01 (config) # interfață fa0 / 0 (setează interfața pentru configurare)

Switch01 (config-if) # fără oprire (interfața este activată)

Switch01 (config-if) # adresă ip 192.168.0.1 255.255.255.0 (setează adresa IP și masca)

Switch01 (config-if) # ieșire (ieșire din modul de configurare a interfeței)

Switch01 (config) #

Setarea unei parole pentru modul privilegiat

Switch01 (config) # enable secret pass1234 (parola pass1234)

Switch01 (config) # ieșire

Având în vedere că informațiile sunt transmise în text clar în timpul conexiunilor telnet, trebuie să utilizați conexiuni SSH, care vor asigura criptarea traficului.

Switch01 # conf t Switch01 (config) # ip nume de domeniu geek-nose.com (domeniul este setat, dacă nu este scris niciunul)

Switch01 (config) # crypto key generate rsa (generează cheia RSA sub ssh)

Switch01 (config) # ip ssh versiunea 2 (versiunea de protocol ssh)

Switch01 (config) # ip ssh autentification-retry 3 (număr de încercări de conectare ssh)

Switch01 (config) # service password-encryption (salvați parolele în formă criptată)

Switch01 (config) # line vty 0 2 (tranziție la modul de conf- și linii terminale)

Switch01 (config-line) # transport input ssh (doar conexiune ssh)

Switch01 (config-line) # exec timeout 20 0 (activați deconectarea automată a sesiunii ssh după 20 de minute)

Switch01 (config-line) # end (Ieșire din modul de configurare)

Switch01 # copy running-config startup-config

Aceasta a fost o configurare SSH de bază. Mai avansat arată astfel:

Switch01 # conf t Switch01 (config) # aaa nou-model (protocolul AAA este activat)

Switch01 (config) # username root privilegie 15 secret pass1234 (creează un utilizator root cu un nivel maxim de privilegii de 15 și o parolă pass1234)

Switch01 (config) # access-list 01 permit 192.168.0 0.0.0.255 (o regulă de acces cu numele 01 prin ssh este setată pentru toate gazdele din rețeaua 192.168.0.0/24; o anumită adresă IP poate fi setată)

Switch01 (config) # line vty 0 2 (peekhod la modul de conf-și linii terminale) Switch01 (config-line) # nivel de privilegiu 15 (permisiunea de a intra în modul privilegiat)

Switch01 (config-line) # access-class 23 in (legarea regulii de acces ssh creată la linia terminalului)

Switch01 (config-line) # înregistrare sincronă

Switch01 (config-line) # end (ieșire din modul de configurare)

Switch01 # copy running-config startup-config (salvați setările).

Aceasta completează configurația de bază a comutatorului Cisco 2960. Dacă este necesar, puteți oricând să resetați la setările din fabrică și să efectuați setările „de la zero”.

Instalați SSH

Pentru echipamentele de rețea, acest pas nu este necesar - suportul SSH este aproape întotdeauna integrat chiar și în cea mai minimalistă versiune a sistemului de operare. Singura excepție este versiunea Cisco IOS destul de veche a W/O CRYPTO.

Această versiune de IOS - cu eliminarea deliberată a tuturor, chiar și a urmelor nesemnificative a ceea ce se referă la criptografie (până la absența (config) #enable secret) a fost necesară pentru export în țări cu legislație strictă în ceea ce privește importul criptografiei. De altfel, acest lucru nu este doar evident Cuba + Coreea de Nord + Siria + Iran, ci și, de exemplu, Australia.

Dacă aveți un IOS similar - acesta poate fi, de exemplu, pe Catalyst 2950, ​​​​care, deși vechi, poate apărea în producție - actualizați-l. Fără actualizare, funcțiile necesare pentru SSH, în special:

• Client integrat Secure Shell SSH versiunea 1;
• Suport server Secure Shell SSH versiunea 1;
• Suport pentru server Secure Shell SSH Versiunea 2;

va fi absent fizic din IOS.

Adăugarea suportului SSH la Windows Server

Începând cu Windows Server 2016 build 1709, suportul SSH a fost adăugat pe platforma Windows.

Este ușor să-l porniți.

Primul pas este să aflați ce versiune a clientului și serverului OpenSSH se află în depozitele disponibile pentru instalare chiar acum. Acest lucru este necesar pentru ca atunci când versiunile cresc (la momentul scrierii, versiunea unu, 1.0), atunci să nu avem probleme de genul „ceva cu scriptul care pune o anumită versiune nu funcționează”. Să o facem cu următorul cmdlet:

Get-WindowsCapability -Online | ? Nume cum ar fi „OpenSSH *”

Am Windows Server 2019, deci rezultatul arată astfel:

Vedem că clientul SSH este deja instalat inițial, dar serverul SSH nu este. Windows Server 2016 va avea o ieșire ușor diferită, nimic nu a fost instalat acolo inițial. OK, hai să instalăm un server SSH:

Add-WindowsCapability -Online -Nume OpenSSH.Server ~~~~ 0.0.1.0

Clientul, după cum este clar, dacă lipsește, este plasat în același mod. Tild - patru bucăți, nu face o greșeală.

Dacă primiți eroarea 0x800f0950, nu disperați - doar că Feature-On-Demand nu poate găsi depozitul. Încercați-l prin vechiul DISM:

dism / Add-Capability /CapabilityName:OpenSSH.Server~~~~0.0.1.0 / LimitAccess / Online

Să verificăm dacă totul este instalat:

Get-Service sshd

bine, sau doar întrebați din nou Get-WindowsCapability -Online | ? Nume cum ar fi „OpenSSH *”:

Dacă totul este în regulă, atunci serviciul sshd a apărut - totuși, sa oprit. Nu îl porniți imediat - mai întâi trebuie să faceți setările minime, care vor fi descrise în secțiunea corespunzătoare a articolului.

Remedierea versiunii SSHv2

Zoo de pornire a versiunilor SSH este SSH 1.3, apoi SSH 1.5, apoi „o versiune specială de la Cisco, care arată că serverul poate face atât 2.0, cât și anterioare”, care 1.99 este acum complet irelevant, deoarece tot software-ul este capabil să SSHv2. Găsirea unui software care acceptă doar SSH 1.x este o adevărată provocare. Prin urmare, desigur, asigurați-vă că nu aveți un astfel de software și actualizați dacă este necesar - dar vom lua în considerare funcționalitatea și securitatea doar celei de-a doua versiuni de SSH.

Activarea SSH 2.x în Cisco IOS

Se remediază simplu - pentru Cisco IOS va fi comanda:

atragerea (config) #ip ssh versiunea 2

Dacă în acest moment nu ați creat încă o singură pereche de chei potrivită pentru SSHv2, atunci veți primi ceva de genul acesta:

Creați chei RSA pentru a activa SSH (și de cel puțin 768 de biți pentru SSH v2).

Aceasta nu este mare lucru, cu excepția cazului în care observăm că SSHv2 are cerințe „mai mici” pentru lungimea unei chei într-o pereche de chei. Cu toate acestea, nu vom încerca să creăm chei care nu se încadrează în această limitare - zilele în care, de exemplu, cheile RSA de 512 biți erau utilizate în mod activ, au dispărut.

Dacă cheile nu au fost încă create, atunci acest lucru se face simplu:

atraining (config) #crypto key generate rsa module 2048 label SSH_KEYS

Parametrii sunt simpli - rsa va seta algoritmul (varianta ec este adăugată în noul IOS), modulul - lungimea biților (puteți seta la 4096, cu siguranță va fi mai sigur), eticheta - pentru a crea un „numit pentru un pereche de chei cu scop specific".

În unele versiuni de Cisco IOS există o limită a perechilor de chei stocate - până la 10 per dispozitiv și până la 2 per utilizator - așa că poate fi afișat un avertisment precum „atenție, o nouă pereche de chei o va suprascrie pe cea anterioară”. Urmăriți-l.

Acum să spunem lui SSH să folosească exact această pereche:

atraining (config) #ip ssh rsa keypair-name SSH_KEYS

Dacă totul este în regulă, vom obține ceva de genul acesta:

% SSH-5-DISABLED: SSH 2.0 a fost dezactivat
% SSH-5-ENABLED: SSH 2.0 a fost activat

Acest lucru va indica faptul că trecerea de la „orice chei” la „perechea specificată în mod explicit” a avut succes.

Dacă, de asemenea, trebuie să informăm că acest dispozitiv ar trebui să fie conectat numai folosind SSH și nu telnet, de exemplu, atunci acest lucru se face după cum urmează - mai întâi intrăm în modul de configurare VTY:

atraining (config) #line vty 0 5 (sau line vty 0 15 - în funcție de model)

și indică în mod explicit că conexiunile de intrare trebuie să fie exclusiv prin SSH:

atraining (config-line) #transport input ssh

Activarea SSH 2.x în Cisco NX-OS

Va fi ușor cu Cisco Nexus - acceptă doar SSH 2.x, așa că nu este nevoie de pași suplimentari pentru a restricționa conectivitatea la versiunile mai vechi de SSH.

Nu uitați să activați în mod explicit utilizarea SSH:

Dacă nu există chei, atunci le puteți crea în mod explicit, imediat de lungimea dorită și cu algoritmul dorit. Pentru a face acest lucru, dezactivați SSH, generați chei și activați SSH - apoi va „prelua” imediat altele noi:

atraining-nx (config) #nicio caracteristică ssh

atraining-nx (config) cheie #ssh rsa 2048

atraining-nx (config) #feature ssh

Parametrii pentru cheia ssh sunt banali, cu excepția că voi observa că cheile vechi nu vor fi suprascrise automat, dacă este necesar, pentru a le suprascrie - adăugați la sfârșitul forței de comandă

Activarea SSH 2.x în sshd

În setările sshd, va trebui să adăugăm (sau să înlocuim) linia:

Activarea SSH 2.x pe Windows Server

În directorul% WINDIR% \ System32 \ OpenSSH \ va exista un fișier de configurare standard OpenSSH, sshd_config_default - și, în teorie, ar putea exista o setare despre „doar a doua versiune”, dar de fapt numai SSHv2 este întotdeauna utilizat. Prin urmare, nu există un pas specific pentru a activa SSHv2 pe Windows Server.

Acum să limităm lista de protocoale care pot fi utilizate pentru autentificare atunci când conectăm un client.

Limitarea listei de protocoale de autentificare a serverului

SSH acceptă mai multe opțiuni pentru verificarea identității nodului la care se face conexiunea - folosind algoritmii DSA, ECDSA, RSA și populara curbă eliptică 25519.

Nu ne place DSA imediat, pentru că el cunoaște doar chei de 1024 de biți și există o opinie exprimată de tovarășul Snowden că NSA nu este atât de pasionată de DSA.

Prin urmare, vom întrerupe imediat cazul de utilizare pentru DSA.

Remediem utilizarea RSA pentru identificarea gazdei în Cisco IOS

Pentru Cisco, va fi simplu:

atraining (config) #ip ssh server algoritm hostkey ssh-rsa

Remedierea algoritmilor de identificare a gazdei pentru sshd

În setările sshd, va trebui să mergem în folderul / etc / sysconfig / sshd și să corectăm acolo linia AUTOCREATE_SERVER_KEYS:

AUTOCREATE_SERVER_KEYS = „RSA ED25519”

După cum este clar, aceasta este setarea „în variantele căror algoritmi ar trebui să fie autogenerate cheile gazdei”. Rețineți că, dacă sarcina este de înaltă fiabilitate, atunci RSA de 4096 de biți este alegerea potrivită, iar dacă viteza este, atunci EC 25519 va fi de preferat.

După aceea, mergeți la directorul de setări sshd - în versiunea noastră va fi / etc / ssh - și ștergeți fișierele algoritmilor neutilizați cu chei gazdă acolo. Adică dintr-o listă ca:

• 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

vom lăsa doar cele necesare.

Dacă vă este frică să ștergeți inutil - nu vă fie teamă, la pornirea serviciului sshd va citi fișierul de configurare și va crea pe cele lipsă, dacă este necesar.

După aceea, în fișierul de configurare, trebuie să găsiți directive pentru utilizarea acestor fișiere cu chei - ele (directivele) arată de obicei astfel:

• 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

și lăsați doar pe cele de care aveți nevoie, comentând restul adăugând caracterul # (hash) în fața rândurilor.

Dacă directiva privind utilizarea fișierului este absentă sau fișierul este indisponibil, atunci algoritmul corespunzător nu va putea fi utilizat pentru a verifica identitatea nodului, ceea ce poate duce la probleme de conexiune.

De exemplu, dacă lăsați doar Ed25519 elegant și dezactivați RSA, atunci PuTTY-ul utilizat pe scară largă ar putea spune ceva de genul:

Acest lucru, apropo, este tratat prin actualizarea PuTTY la cea mai recentă versiune, care are suport pentru noi algoritmi. Așa că fă-o din timp.

Lăsând doar tipurile de chei necesare - de obicei ED25519 și RSA - trebuie să le recreați manual, de exemplu. a externaliza „lăsați serverul să o facă la următoarea repornire a serviciului” nu este o idee bună.

Acest lucru se face astfel:

Pentru Ed25519: ssh-keygen -t ed25519 -f ssh_host_ed25519_key -N ""

Pentru RSA: ssh-keygen -t rsa -b 4096 -f ssh_host_rsa_key -N ""

Făcând acest pas manual, puteți fi sigur că cheia RSA va avea lungimea corectă și nu lungimea implicită.

Limitarea protocoalelor pentru autentificarea SSH în Windows Server

Schema este aceeași - mergeți la fișierul sshd_config_default și lăsați doar acolo:

• HostKey ssh_host_rsa_key
• HostKey ssh_host_ed25519_key

Dacă aveți nevoie atât de Ed25519, cât și de RSA, sau în general doar de Ed25519. După - generăm chei:

Pentru Ed25519:. \ Ssh-keygen -t ed25519 -f ssh_host_ed25519_key

Pentru RSA:. \ Ssh-keygen -t rsa -b 4096 -f ssh_host_rsa_key

. \ ssh-add ssh_host_ed25519_key

În principiu, totul, serviciul sshd poate fi pornit.

Cârja marca Microsoft

Fructul minții întunecate a dezvoltatorilor Microsoft este o cârjă pentru înregistrarea drepturilor asupra fișierelor cu chei. Este recomandat să-l rulați, dar dacă sunteți sănătos mintal și ghiciți că serviciul ar trebui să aibă drepturi asupra fișierelor cheie pe care le utilizează, puteți face fără el. Cu toate acestea, dacă este ceva, este pus astfel:

Instalare-Module -Forțare OpenSSHUtils

Reparație-SshdHostKeyPermission -FilePath

Va necesita NuGet și, în general... vedeți singur:

Estimați nivelul publicului țintă, care pentru aceste acțiuni trebuie să descarce pachetul de module și să ruleze cmdletul - adică. nu porniți creierul și distribuiți drepturile, dar puteți memora singur comanda. Sunt sigur că Microsoft va emite câteva MVP-uri pentru acest modul.

Acum despre schimbul de informații cheie.

Configurarea schimbului de chei / crearea de materiale cheie

Există multe variante de DH sau algoritmul Diffie-Hellman-Merkle. Fără să ne adâncim în materialul algoritmului în sine în acest articol, să vedem cum putem întări frontul din această parte.

Schimbul de chei și cogenerarea de materiale cheie pentru o anumită sesiune este un subiect de securitate foarte serios. Sarcina noastră este să evităm opțiunea când vom avea un scenariu „autentificarea este puternică, dar schimbul de chei nu este”.

Să vedem cum avem acum configurat DH în SSH pe Cisco IOS:

atraining # sh ip ssh | inc Diffie

Dimensiunea minimă așteptată a cheii Diffie Hellman: 1024 de biți

Prost. Trebuie să fie de cel puțin 2048 de biți. Setăm asta cu comanda:

în curs (config) #ip ssh dh min size 2048

Prin urmare, faceți propria alegere - SHA-512, cu suportul său pe toate echipamentele uzate, va fi cea mai bună alegere.

Dar există o subtilitate - modul de utilizare a hashului și a criptării.

În mod implicit, SSH utilizează o variantă numită Encrypt-and-MAC - MAC care a fost citit ca necriptat este atașat la datele criptate. În acest caz, pentru a verifica MAC-ul, trebuie mai întâi să decriptați blocul de informații primit pentru a obține textul simplu, apoi să calculați și să comparați hashurile. Această opțiune face posibilă atacarea algoritmilor de criptare și obținerea de date „intermediare” în cazul compromiterii sistemului țintă.

Cea mai bună opțiune din punct de vedere al securității este Encrypt-Then-MAC. De ce? În cazul în care se utilizează schema „hash from already encrypted”, primul pas este verificarea integrității, iar dacă ceva nu este în regulă, datele sunt imediat aruncate; nu are loc nicio decriptare de probă. Astfel de variante MAC vor avea sufixul -etm. Având în vedere aceste puncte, configurația noastră va arăta astfel:

MAC-uri [email protected],[email protected]

În Cisco IOS, tipul MAC va fi setat astfel:

atragerea (config) algoritmul serverului #ip ssh mac hmac-sha1

Cisco IOS are o opțiune limitată - hmac-sha1 și hmac-sha1-96. A doua opțiune cu tăierea ieșirii SHA-1 de la 160 de biți la 96 (ca în ipsec) nu va funcționa pentru noi, deoarece este considerată la aceeași viteză (totuși trebuie să numărați SHA-1 obișnuit) și economisind trafic - Ei bine, ahem, deloc.

MAC pentru numărarea tastelor de amprentă

În OpenSSH, putem specifica și un algoritm pentru calcularea „amprentei” - amprenta cheii. Valoarea implicită este MD5 - cu toate acestea, ar fi mai bine să indicați în mod explicit că SHA-2/256 este mai bun pentru afișarea și compararea hashurilor cheilor:

FingerprintHash sha256

Acum să trecem de la partea criptografică la partea de rețea.

Setări de rețea SSHv2

Vor exista o mulțime de setări de rețea, dar cele mai multe dintre ele sunt banale - „ce să folosești” și „cum să filtrezi traficul”, așa că nu are rost să creezi o secțiune pentru fiecare.

Blocul va arăta cam așa:

Portul 22
AddressFamily inet
IgnoreRhosts da
UseDNS nr
ListenAddress x.x.x.x
TPCKeepAlive da
#VerifyHostKeyDNS nr
#UseRoaming nr

Unele dintre setări sunt clare - de exemplu, portul 22 leagă serviciul SSH la numărul de port specificat, care poate fi schimbat dacă este necesar - cel puțin pentru ca boții-parola-boții să nu bată, iar ListenAddress indică clar la ce adrese L3 să accepte cereri de conectare (restricția este actuală în cazul mai multor adrese și/sau interfețe de rețea, sau în scenariul „gazda poate avea noi interfețe de rețea din mers, iar asta nu înseamnă că trebuie să așteptați conexiuni SSH pe ei"). Alte setări sunt mai puțin evidente.

AddressFamily inet spune că vom aștepta doar conexiunile IPv4. Dacă utilizați IPv6 și vă puteți conecta la serverul SSH prin intermediul acestuia, adăugați AddressFamily inet, inet6.

TCPKeepAlive da va fi necesar pentru a detecta utilizatorii deconectați la nivel de rețea și pentru a le termina sesiunile. Dezactivarea acestui mecanism, care se recomandă uneori „pentru a economisi traficul” (lacrimi, nu economie) va duce la o situație în care ssh nu va putea în unele cazuri să înțeleagă că utilizatorul nu este doar inactiv, ci nu va mai putea continua niciodată lucrând în această sesiune. Prin urmare, includem.

IgnoreRhosts yes dezactivează mecanismul antic pentru crearea unei liste de gazde (de obicei în fișierul .rhosts) din care sunt posibile autentificări neautentificate.

UseDNS nu va fi necesar pentru a dezactiva verificarea înregistrării PTR a abonatului care se conectează - pe lângă faptul că se află în rețeaua internă, iar atunci când vă conectați din rețele externe, prezența PTR este, de asemenea, complet opțională, această măsură doar încetinește conexiunea și nu ridică nivelul de securitate - maxim este că o face - scrie un avertisment în jurnal despre „utilizatorul care se conectează nu a spus numele său FQDN real”. Deși este posibil ca această verificare să fie activată, iar DNS-ul de pe gazdă să nu funcționeze (de exemplu, indică adresa IP greșită a serverului DNS), în acest caz, este posibil să nu se poată conecta către gazdă. Dar aceasta nu este deloc o „măsură de protecție”, ci mai degrabă un alt motiv pentru a dezactiva această verificare, deoarece din această cauză, se pare, numărul de subsisteme implicate crește și, prin urmare, fiabilitatea generală a sistemului scade.

Este folosit, atunci nu trebuie să îl dezactivați. Aceasta este, prin logica sa, o setare client, dar din anumite motive, uneori există gânduri „activați-o pe server”. L-am adăugat la această listă și l-am comentat pentru a sublinia acest punct - nu trebuie să specificați această opțiune în setările serverului.

UseRoaming nu dezactivează suportul pentru roaming - o extensie experimentală pentru OpenSSH, care trebuia să gestioneze scenarii precum „a început administratorul dintr-un loc, apoi s-a mutat în altul și a continuat de acolo”. De fapt, această funcționalitate s-a dovedit a nu fi de folos nimănui și nu a adăugat inovații inovatoare, dar a adus probleme de securitate - până la vulnerabilități cu PoC. Prin urmare, îl dezactivăm în mod explicit. La fel ca parametrul anterior, este de partea clientului, de exemplu. este dat aici pentru că, din nou, într-un număr de ghiduri scrie „opriți peste tot, atât pe client, cât și pe server”. Nu este cazul, doar la client.

Restricții SSH privind procedura de conectare a sesiunii

Procesul de conectare la sesiune trebuie, de asemenea, elaborat, deoarece că utilizarea unor metode „neobișnuite” de conectare, că furnizarea clientului care se conectează cu informații inutile, că cheltuirea resurselor serverului pentru menținerea unui set de solicitări „paralele” este inutilă.

Blocul setărilor noastre pentru toate acestea va arăta astfel:

RhostsRSAAutentificare nr
PubkeyAuthentication nr
HostbaseAuthentication nr
ChallengeResponseAuthentication nr
KerberosAuthentication nr
Autentificare prin parolă da

LoginGraceTime 15

ClientAliveInterval 1800
ClientAliveCountMax 0

MaxAuthTries 3
MaxSessions 1
PermisTunnel nr

MaxStartups 10:50:20
ShowPatchLevel nr

Să ne dăm seama ce și cum.

Blocul de la RhostsRSAAuthentication nu, PubkeyAuthentication nu, HostbaseAuthentication nu, ChallengeResponseAuthentication nu, KerberosAuthentication nu dezactivează metodele de autentificare neutilizate. Desigur, dacă utilizați, de exemplu, Kerberos pentru a vă conecta la serverul SSH, atunci nu trebuie să dezactivați Kerberos. Dar într-un scenariu tipic, atunci când autentificarea este efectuată în moduri mai comune, excesul trebuie dezactivat în mod explicit.

Parametrul LoginGraceTime indică cât timp poate petrece utilizatorul procedurii de conectare. Valoarea implicită este de 2 minute. Aceasta este mult. Un utilizator foarte lent trebuie să fie astfel încât să-i ia atât de mult să se autentifice. Prin urmare, acest parametru este setat la 15 - puteți introduce în 15 secunde. Dacă aveți nevoie de mai mult timp, îl puteți crește, dar rezonabil. Mai important, serverul va „reseta” rapid sesiunile care au început, dar nu au finalizat încă autentificarea și va economisi resurse.

Omologul Cisco IOS pentru LoginGraceTime este comanda atraining (config) #ip ssh time-out, care setează timpul maxim pentru procedura de conectare. Valoarea implicită este, de asemenea, 2 minute, ceea ce este, de asemenea, puțin prea mult și ar trebui redus. În cazul Cisco NX-OS, acesta ar fi atraining-nx (config) #ssh login-gracetime.

Vor fi necesare câteva setări ClientAliveCountMax și ClientAliveInterval pentru a determina când să deconectați un client inactiv. ClientAliveInterval este timpul de inactivitate în secunde după care clientul va fi deconectat, iar ClientAliveCountMax este numărul de încercări de a „trezi” clientul. În cazul nostru, clientul va fi deconectat după o jumătate de oră de inactivitate.

Parametrul MaxAuthTries indică după câte încercări de autentificare nereușită (de exemplu, introducerea unei parole incorecte) sesiunea va fi deconectată de server. Valoarea implicită este 6, ceea ce este puțin prea mult. De trei ori este suficient.

Analogul MaxAuthTries în Cisco IOS este comanda atraining (config) #ip ssh authentication-retries, cu o valoare implicită de 3 încercări.

Parametrul MaxSessions arată câte sesiuni într-o conexiune SSH poate fi inițializată. Aceasta nu este o limitare a „sesiunilor simultane de la aceeași gazdă”! Acesta este exact „puneți conducta SSH la server și în interiorul acestuia multiplezați multe sesiuni cu redirecționare a datelor”. Dacă nu aveți nevoie de un astfel de scenariu - atunci când vă conectați la serverul X și redirecționați traficul în adâncime în rețea prin intermediul acestuia, atunci doar câteva vor fi suficiente - și trebuie doar să vă conectați la un anumit server și să-l administrați, atunci MaxSessions 1, da. Parametrul PermitTunnel no va finaliza configurarea modului „ssh numai pentru administrarea serverului la care ne conectăm”.

MaxStartups 10:50:20 este un mecanism asemănător WRED, a cărui familie este discutată și logica configurației sale va fi următoarea - prima și ultima valoare sunt numărul de început de conexiuni (vorbim doar despre conexiuni care nu au trecut autentificarea), începând de la care mecanismul numărul maxim de conexiuni posibil în general va începe să funcționeze (în cazul nostru, mecanismul se va porni când există 10 conexiuni la server, iar conexiunea 21e este imposibilă din punct de vedere tehnic) , iar parametrul mediu este probabilitatea în procente. Avem 50, adică vom refuza în jumătate din cazuri când numărul de sesiuni „atârnate în faza de autentificare” va fi de la 10 la 20.

Puteți face acest lucru mai ușor - de exemplu, MaxStartups 10, i.e. setați MaxStartups cu un singur parametru. Aceasta va indica pur și simplu numărul maxim de sesiuni autentificate simultan.

Omologul Cisco IOS pentru MaxStartups N cu un parametru este comanda atraining (config) #ip ssh maxstartups N, unde N este același număr maxim de sesiuni autentificate concomitent.

Folosind comanda ShowPatchLevel no, dezactivăm publicarea informațiilor detaliate despre versiunea SSH către clientul care se conectează.

Acum să trecem la blocul de setări legate de conturi.

Grupuri și utilizatori în configurarea serverului SSH

Este destul de evident că trebuie să indicăm cumva în mod explicit cine se poate conecta la noi și ce cerințe pentru acest cineva vor fi prezentate.

AllowUsers admin admin2
AllowGroups nixadmins
DenyUsers nginx
DenyGroups nginx
PermitEmptyPasswords nr
PermitRootLogin nr
Utilizați cutia de testare PrivilegeSeparation

Nici aici nu este nimic deosebit de surprinzător, toți parametrii sunt denumiți foarte precis - cu excepția faptului că mă voi opri asupra interzicerii explicite de conectare prin ssh pentru conturile și grupurile de servicii (în exemplul meu, nginx). Nu fi leneș să-l notezi în mod explicit, astfel de conturi se schimbă extrem de rar și o plasă de siguranță nu va strica. Da, și nu funcționează sub rădăcină, oricât de banal ar suna.

În varianta cu Cisco IOS, nu are sens să faci astfel de setări local pe dispozitiv, de vreme ce este mai logic să folosiți AAA și să redirecționați cererile de autentificare și autorizare prin RADIUS / TACACS către un server centralizat sau (în noul IOS) să mergeți direct la stocarea LDAP cu solicitări „există un astfel de utilizator”. Este incomod și nesigur să creați baze locale pe fiecare dispozitiv. Tot acest mecanism nu este legat de SSH, ci este o modalitate mai generală de redirecționare a cererilor de autentificare/autorizare, așa că nu este descris aici, astfel încât articolul să rămână despre SSH, și nu „despre tot ce poate fi legat de SSH”.

Cu toate acestea, în ceea ce privește parolele, configurarea nu strica - comanda

atraining (config) #security parola min-length N

va seta lungimea minimă a parolelor pe acest dispozitiv.

Setarea sandbox UsePrivilegeSeparation va spune explicit ssh că pentru fiecare conexiune de intrare va fi creat un proces sshd separat cu privilegii minime - iar după autorizarea cu succes va fi creat unul nou, care va procesa sesiunea unui anumit utilizator conectat. Acest lucru reduce pierderile în cazul unei noi vulnerabilități în mecanismul de conectare sshd - cel care va exploata această vulnerabilitate, chiar dacă procesul ssh este deturnat, va primi un minim de drepturi în sistem.

Rezumat scurt

Sper că veți găsi această mică listă de verificare utilă. SSH este utilizat pe scară largă, astfel încât accesul previzibil și sigur prin intermediul acestuia reprezintă fundamentul unei infrastructuri de rețea de încredere.

Data ultimei editări a textului: