Restricționați încercările de introducere a parolei în Linux pentru a securiza SSH și serviciile

Dacă gestionați un server Linux expus la internet, mai devreme sau mai târziu veți vedea în jurnalele mii de încercări de conectare SSH de la adrese IP aleatoriiNu e că le-ar fi plăcut: sunt roboți automati care se plimbă prin intervale de IP-uri în căutare de uși prost protejate.

Pe un server mic, aceste încercări se pot traduce în Vârfuri mari de utilizare a procesorului, degradarea performanței și chiar întreruperi ocazionale ale serviciilorVestea bună este că Linux oferă un arsenal de instrumente pentru a limita încercările de introducere a parolei, a bloca IP-urile agresive și a consolida SSH-ul pentru a îngreuna foarte mult accesul unui atacator.

Detectarea atacurilor SSH brute-force și impactul acestora asupra serverului

Înainte de a începe să configurăm orice, este util să înțelegem cum putem detecta dacă întâmpinăm o atac de forță brută împotriva SSH sau a altor serviciiși ce efecte are asupra mașinii.

Un simptom foarte tipic este observarea unui o creștere bruscă a utilizării procesorului fără nicio modificare a traficului legitim sau a încărcării bazei de dateDe exemplu, este posibil să aveți o creștere bruscă a utilizării procesorului timp de câteva minute, în timp ce utilizarea memoriei și a discului rămâne practic constantă, ceea ce indică de obicei procese care necesită multă putere de calcul (cum ar fi numeroase încercări de autentificare), mai degrabă decât interogări complexe.

Pentru a analiza ce s-a întâmplat într-un anumit interval, este foarte util să folosim jurnalctlInstrumentul systemd pentru citirea jurnalelor de sistem, servicii, kernel și autentificare. Un exemplu clasic de interogare ar fi:

journalctl --since "2025-11-16 13:10" --until "2025-11-16 13:16"

Cu acest tip de interogare puteți analiza în detaliu Ce mesaje a înregistrat sistemul în fereastra în care CPU a înregistrat un vârf de performanță?: servicii care repornesc, erori de autentificare, erori de kernel etc.

În multe cazuri veți găsi linii repetate legate de SSH, cum ar fi „Parolă eșuată pentru” indică încercări de conectare eșuateAsta e practic sinonim cu testarea acreditărilor prin forță brută de către roboți.

Cuantificarea încercărilor eșuate în /var/log/auth.log

Pe sistemele Debian/Ubuntu, fișierul cheie pentru urmărirea oricărui lucru legat de autentificare este /var/log/auth.logAici se înregistrează conectările reușite, încercările eșuate, evenimentele PAM, blocările contului etc.

Dacă vrei să știi de câte ori a fost înregistrat modelul „Parolă eșuată” în jurnalul curent, poți să folosești:

sudo grep 'Failed password' /var/log/auth.log | wc -l

Rezultatul poate fi surprinzător: nu este neobișnuit să vezi mii de încercări eșuate acumulate în doar câteva oreȘi nu uitați că acesta este doar fișierul curent.

Întrucât jurnalele sunt rotite, este important să verificați și fișierele mai vechi. Puteți vedea ce interval de timp acoperă jurnalul curent cu ceva de genul:

head -n 1 /var/log/auth.log
tail -n 1 /var/log/auth.log

În felul acesta vei ști Data primei și ultimei înregistrări prezente în auth.logRestul încercărilor anterioare vor fi în auth.log.1 și în fișierele comprimate auth.log.N.gz.

Pentru a revizui jurnalele vechi comprimate și a număra încercările eșuate de introducere a parolei, puteți utiliza:

zgrep 'Failed password' /var/log/auth.log.*.gz | wc -l

Dacă aduni ceea ce vezi în auth.log, auth.log.1 și auth.log.*.gz Îți vei face o idee bună despre Înregistrarea istorică a atacurilor prin forță brută, ținând cont de faptul că cele mai vechi ar fi putut deja dispărut din cauza rotației.

Cum funcționează rotația jurnalului de autentificare

Modul și frecvența cu care se rotesc buștenii depind de configurația realizatÎn Ubuntu, rotația fișierului auth.log este de obicei definită în /etc/logrotate.d/rsyslog, unde veți găsi de obicei ceva de genul:

weekly
rotate 4
compress

Asta înseamnă că Jurnalul este rotit săptămânal, se păstrează patru copii vechi, iar cele vechi sunt comprimate în fișiere .gz.O lucrare cron zilnică este responsabilă pentru rularea comenzii logrotate și aplicarea acestor reguli.

Prin urmare, atunci când calculați încercările de forță brută, presupuneți că Vedeți doar datele istorice de acum câteva săptămâni.Orice s-a întâmplat mai departe în timp nu va mai exista în sistem.

Identificați utilizatorii și IP-urile atacatoare

Dincolo de numărul total, este important să știm Ce utilizatori sunt vizați și de la ce adrese IP provin atacurile?Cu puțin awk pe auth.log, îl ai la îndemână.

Pentru a vedea ce nume de utilizator sunt încercate în încercările eșuate:

sudo grep 'Failed password' /var/log/auth.log \
  | awk '{print $(NF-5)}' \
  | sort | uniq -c

Și pentru a vedea IP-urile cu cea mai suspectă activitate:

sudo grep 'Failed password' /var/log/auth.log \
  | awk '{print $(NF-3)}' \
  | sort | uniq -c | head

Acest lucru vă va permite să detectați rapid dacă vă atacă. conturi reale din sistemul dvs. sau utilizatori generici cum ar fi root, admin, test, user etc. și ce IP-uri ar trebui să blochezi cel mai urgent.

Chiar este atât de grav încât există mii de încercări?

Trebuie presupus că, dacă serverul dumneavoastră este accesibil de pe internet și are SSH ascultă pe portul 22 sau pe oricare altulAcest server va primi acest tip de trafic 24 de ore pe zi. Este normal să vedeți mii de încercări eșuate dacă serverul a funcționat o perioadă de timp.

Gravitatea reală depinde de setările dvs.:

configurație	Risc aproximativ
Parole slabe + SSH deschis la internet	Risc foarte mare de compromitere
Parole puternice	Risc moderat, dar consum de resurse
Fail2ban configurat corect	Atacuri cu risc scăzut și extrem de atenuate
Acces doar cu chei SSH	Risc foarte aproape de zero prin forță brută

Cu alte cuvinte: atacurile automate sunt frecvente, dar dacă configurația este laxă, O singură parolă eșuată este suficientă pentru a pierde întregul server.De aceea este atât de important să limităm încercările, să blocăm IP-urile și, acolo unde este posibil, să eliminăm parolele.

Securizare SSH de bază: opțiuni critice în sshd_config

Prima linie de apărare este în interiorul tău Daemonul SSH (sshd) și fișierul său de configurare /etc/ssh/sshd_config (și fișierele .d asociate). Câteva directive bine ajustate reduc considerabil suprafața de atac.

Rețineți că în distribuțiile moderne precum Ubuntu 22.04 și versiunile ulterioare, sshd citește mai întâi /etc/ssh/sshd_config și apoi fișierele din /etc/ssh/sshd_config.d/*.conf în ordine alfabetică. Orice element care apare ulterior poate suprascrie parametrii definiți anterior, așa că fiți foarte atenți la ce modificați.

Dezactivați accesul fără parolă și sesiunile inutile

Deși vine bine configurat în majoritatea distribuțiilor moderne, nu strică să confirmăm că Nu sunt permise autentificări fără o parolă definită.Directiva cheie este:

PermitEmptyPasswords no

De obicei, este comentat sau setat explicit la „nu”. De asemenea, asigură-te că ai dezactivate funcțiile pe care nu le vei folosi, cum ar fi... Redirecționare X11 (X11Forwarding) Dacă nu faci sesiuni grafice la distanță:

X11Forwarding no

În ceea ce privește protocoalele, dacă, din orice motiv, gestionați un sistem foarte vechi, verificați dacă sunt permise doar anumite acțiuni. Protocolul SSH 2:

Protocol 2

Schimbă portul implicit și limitează interfața pe care ascultă.

Un alt truc simplu, deși nu infailibil, este Mută SSH-ul de pe portul 22 pe un port non-standard.Acest lucru nu te protejează de un atacator serios, dar filtrează o cantitate semnificativă de zgomot automat care scanează doar cele 22.

Port 2222
ListenAddress 192.168.56.8

Pe lângă schimbarea portului, puteți specifica o adresă specifică la care SSH va asculta, de exemplu, adresa IP internă dacă doriți să o limitați la o anumită rețea. Totuși, dacă distribuția dvs. folosește ssh.socket-ul systemd, este posibil să fie nevoie să... Dezactivați socket-ul și reveniți la serviciul ssh.service clasic. pentru a respecta configurația portului:

sudo systemctl disable ssh.socket
sudo systemctl daemon-reload
sudo systemctl enable ssh.service
sudo systemctl start ssh.service

Ori de câte ori schimbați portul, testați conexiunea de la un alt terminal înainte de a închide sesiunea principală, pentru a nu rămâne blocați fără acces de la distanță.

Blocarea sau limitarea accesului root

Utilizatorul root este o pradă ușoară pentru atacatori, deci are sens. împiedică conectarea prin SSHchiar și cu parole. Controlați acest comportament cu directiva:

PermitRootLogin no

În multe instalări moderne, vine în modul „prohibit-password”, care previne autentificările cu parolă, dar lasă ușa deschisă pentru certificate. Dacă vrei să fii în siguranță, lasă-l setat pe „no” și folosește un cont obișnuit cu sudo pentru administrare.

Definiți cine poate accesa: AllowUsers și AllowGroups

În mod implicit, orice utilizator cu shell valid și parolă definită Poți încerca să te conectezi prin SSH. De obicei, acest lucru nu este ideal pe serverele de producție, unde poate doar două sau trei conturi ar trebui să aibă acces.

Pentru a limita utilizatorii permiși, aveți următoarele directive. AllowUsers y AllowGroups. De exemplu:

AllowUsers harry hermione
AllowGroups gryffindor

Lista este separată prin spații, iar semantica este cea a unei „liste albe”: Doar conturile și grupurile listate se vor putea autentificaDe asemenea, rețineți că AllowUsers are prioritate față de AllowGroups, așa că nu le amestecați decât dacă sunteți clar în ordinea evaluării.

O bună practică este să lucrați în principal cu grupuri tipice. utilizatori sshus sau administratori și adăugați conturile autorizate acolo, în loc să păstrați o listă de utilizatori unul câte unul în fișier.

Limitați încercările de autentificare și timpul de nefuncționare

Un alt strat de protecție se află în Reduceți numărul de încercări eșuate permise pe o singură conexiune și cât timp poate rămâne inactivă o sesiune. Pentru prima întrebare, puteți folosi:

MaxAuthTries 3

Cu aceasta, serverul va închide conexiunea după trei încercări greșite, ceea ce Acest lucru face ca orice atac care încearcă mai multe parole împotriva aceleiași sesiuni SSH să fie mai puțin eficient..

În ceea ce privește timpul de inactivitate, SSH vă permite să terminați conexiunile care rămân deschise fără activitate dincolo de un prag definit. ClientAliveInterval (în secunde):

ClientAliveInterval 180

După trei minute fără trafic, serverul va trimite mesaje keepalive și, dacă clientul nu răspunde, Sesiunea se va închide automatEste o modalitate de a reduce riscurile cauzate de terminalele uitate și deblocate.

Restricționare acces prin adresa IP: TCP Wrappers și Match

În anumite situații, s-ar putea să fiți interesat de Doar anumite IP-uri sau intervale pot fi accesate prin SSHAi mai multe modalități de a face asta: de la firewall-ul în sine (iptables/nftables), prin TCP Wrappers, până la blocurile Match din sshd_config.

Cu TCP Wrappers, încă utilizate în multe distribuții, accesul este controlat cu /etc/hosts.allow și /etc/hosts.deny. Fluxul este: Mai întâi se evaluează hosts.allow, apoi hosts.deny.Un exemplu restrictiv ar fi:

# /etc/hosts.deny
ALL: ALL

# /etc/hosts.allow
sshd: 192.168.1.89 192.168.1.55
sshd: ALL: DENY

Cu acea configurație, Doar două gazde specifice se vor putea conecta prin SSHiar restul vor fi refuzate. Este foarte eficient în medii închise, deși mai puțin flexibil decât un firewall modern bun.

O altă opțiune, mai tipică pentru SSH, este utilizarea blocurilor Match în cadrul sshd_config pentru a aplica reguli bazate pe adresă sau utilizator. Imaginați-vă că doriți ca un utilizator „git” să se poată conecta de oriunde, dar utilizatorul dvs. de administrator „greg” se poate conecta doar din LAN 192.168.1.0/24. Ați putea combina regulile AllowUsers cu regulile Match Address, deși trebuie să fiți foarte atenți să... nu te închide în tine însuți.

Fail2ban: Blocări automate versus forță brută

Chiar dacă întărești SSH-ul, boții vor încerca în continuare acreditările, cauzând utilizarea procesorului și zgomot în jurnal. Pentru a atenua acest lucru, intră în joc acest aspect. Fail2ban, un sistem de prevenire a intruziunilor bazat pe jurnal care blochează automat IP-urile cu prea multe erori.

Fail2ban este scris în Python și se bazează pe „închisori” sau închisori, fiecare asociat cu un serviciu și unul sau mai multe fișiere jurnalCând detectează un model de eroare repetat (erori de parolă, acces interzis etc.), declanșează acțiuni, de obicei reguli de firewall, pentru a bloca sursa.

Instalați Fail2ban pe distribuțiile Linux comune

Instalarea de bază este destul de simplă folosind managerul de pachete al distribuției tale. Pe Ubuntu sau Debian, acest lucru ar fi suficient:

sudo apt update
sudo apt install fail2ban

În sistemele bazate pe RHEL (RHEL, CentOS, AlmaLinux, Rocky etc.), comanda tipică ar fi cu dnf sau yum, în funcție de versiune:

sudo dnf install fail2ban

Pachetul include de obicei un serviciu systemd care pornește automat, deși merită să verificați dacă Fail2ban pornește la bootare și este activ:

sudo systemctl enable fail2ban
sudo systemctl start fail2ban
sudo systemctl status fail2ban

Structura de configurare: jail.conf, jail.local și jail.d

Configurația se află în /etc/fail2ban/Fișierul principal este jail.conf, dar editarea lui directă nu este recomandată deoarece este suprascris în timpul actualizărilor. În schimb, ar trebui:

Creați sau editați /etc/fail2ban/jail.local pentru a suprascrie valorile implicite.
Sau adăugați fișiere specifice în /etc/fail2ban/jail.d/*.conf.

Fail2ban încarcă configurația în această ordine:

/etc/fail2ban/jail.conf
/etc/fail2ban/jail.d/*.conf
/etc/fail2ban/jail.local

Tot ce definești în jail.local are prioritate față de tot ce a fost înainte, deci Puteți personaliza fără a atinge fișierele pachetului..

Parametri globali importanți: bantime, maxretry, ignoreip

În jail.conf (sau jail.local) veți vedea o secțiune [DEFAULT] cu parametri globali care afectează toate jail-urile, cu excepția cazului în care sunt suprascriși. Cei mai importanți sunt:

bantime: timpul în care un IP va fi blocat (în secunde) după depășirea numărului de eșecuri permise.
maxretry: numărul maxim de încercări eșuate înainte de aplicarea interdicției.
găsește timp: intervalul de timp în care sunt numărate acele încercări (de exemplu, 10 min timp de zece minute).
ignoreip: listă de IP-uri sau intervale pe care Fail2ban nu ar trebui să le blocheze niciodată (de exemplu, propria adresă IP publică sau rețeaua de administrare).

De exemplu, ați putea avea ceva de genul acesta în [DEFAULT]:

[DEFAULT]
bantime  = 600
findtime = 600
maxretry = 5
ignoreip = 127.0.0.1/8 192.168.1.0/24

Cu acea configurație, Orice adresă IP care eșuează de cinci ori în zece minute va fi blocată timp de zece minute., cu excepția cazului în care face parte din intervalele ignorate.

Configurați jail sshd pentru a opri atacurile SSH

Cea mai comună jail este jail-ul SSH. În multe distribuții, acesta vine preconfigurat în jail.conf; trebuie doar să îl activați sau să îi reglați fin valorile în jail.local. Un exemplu simplu:

[sshd]
enabled  = true
filter   = sshd
logpath  = /var/log/auth.log
maxretry = 3
bantime  = 600
findtime = 10m

În acest caz, Trei încercări eșuate de conectare în auth.log în decurs de zece minute vor duce la blocarea adresei IP a atacatorului timp de zece minute.Fail2ban injectează regulile în firewall (iptables, nftables sau UFW, în funcție de sistem) astfel încât conexiunile de la acel IP să nu ajungă nici măcar la sshd.

Pentru a aplica orice modificări de configurație, nu uitați să reporniți serviciul:

sudo systemctl restart fail2ban

Vizualizați starea închisorilor și a IP-urilor blocate

Fail2ban include un utilitar de control foarte util, fail2ban-clientCu acest instrument, puteți vedea ce închisori sunt active și ce IP-uri au fost blocate. De exemplu:

sudo fail2ban-client status

Ar arăta ceva similar cu:

Status
|- Number of jail: 1
`- Jail list: sshd

Pentru informații detaliate despre închisoarea SSHD:

sudo fail2ban-client status sshd

Rezultatul include, printre alte câmpuri, numărul de IP-uri interzise în prezent și numărul total istoric de adrese care au fost blocate cel puțin o dată, plus lista IP-urilor curente.

Cu aceste date vă puteți face o idee despre Cât trafic malițios primește serverul tău și cât de eficientă este configurația actuală?.

Blocări permanente și bantime incremental

Dacă vrei să fii deosebit de dur cu recidiviștii, Fail2ban oferă două strategii interesante: interdicție permanentă și interdicție incrementală.

Pentru a interzice permanent orice adresă IP care depășește pragul de eșec, introduceți pur și simplu:

bantime = -1

Cu acea ajustare, IP-urile sancționate nu sunt niciodată deblocate automatLe poți elimina manual doar dacă este nevoie.

Mai flexibil este mecanismul incremental, în care fiecare recidivă crește durata interdicției în funcție de un factor:

bantime           = 10m
bantime.increment = true
bantime.rndtime   = 0
bantime.factor    = 4
bantime.maxtime   = -1

Cu aceste valori, progresia ar arăta cam așa:

Al treilea bloc: Minute 10
Al doilea bloc: Minute 40
Al treilea bloc: Minute 160 (~2 ore și 40)
Al 4-lea bloc: în jurul Horas 10,6
Al 5-lea bloc: unele Horas 42

Deoarece bantime.maxtime este -1, durata poate continua să crească la nesfârșit, lăsându-i pe jucătorii cu adevărat grei în afara jocului pentru totdeauna.

Utilizarea Fail2ban dincolo de SSH: Apache, WordPress, MySQL, magazine online…

Odată ce te obișnuiești cu Fail2ban, lucrul logic de făcut este să-l extinzi la protejați alte servicii sensibile în afară de SSHpanouri de administrare web, CMS, baze de date etc.

De exemplu, pentru un magazin online (Magento, PrestaShop, WooCommerce…) este foarte logic să creezi un jail care monitorizează Jurnalele de acces Apache sau Nginx caută multe coduri 401/403 în /admin sau /loginO configurație minimă bazată pe Apache ar putea fi:

[apache-auth]
enabled  = true
filter   = apache-auth
logpath  = /var/log/apache2/access.log
maxretry = 5
bantime  = 3600

În mediile WordPress, o combinație comună este monitorizarea /wp-login.php și /xmlrpc.phpAcestea sunt punctele clasice de intrare pentru atacurile brute-force și atacurile de tip bot. Filtrul ar putea fi plasat în /etc/fail2ban/filter.d/wordpress.conf:

[Definition]
failregex = .*"POST /wp-login.php HTTP.*" 403
ignoreregex =

Și jail-ul corespunzător din jail.local:

[wordpress]
enabled  = true
filter   = wordpress
logpath  = /var/log/apache2/access.log
maxretry = 3
bantime  = 3600

Aceeași idee se aplică bazelor de date expuse (ceva ce, în general, este mai bine să se evite): dacă doriți să protejați MySQL de încercările continue de acces eșuat, puteți crea un filtru pentru Mesajele „Acces refuzat pentru utilizator” în jurnalul de erori:

[Definition]
failregex = ^<HOST>.*Access denied for user.*$
ignoreregex =

Și apoi închisoarea:

[mysqld-auth]
enabled  = true
filter   = mysql
logpath  = /var/log/mysql/error.log
maxretry = 5
bantime  = 1800

Pe servere de găzduire cu panouri de control precum cPanel sau PleskFail2ban se integrează bine și el: poate monitoriza serviciile de mail, Apache, FTP și chiar panoul de control, blocând IP-urile care depășesc limitele în încercările de autentificare.

Autentificare cu chei SSH: sfârșitul atacurilor prin parolă

Toate cele de mai sus ajută, dar adevăratul salt calitativ vine atunci când te decizi Nu mai folosi parole pentru SSH și trece la chei publice/privateÎn acel moment, atacurile prin forță brută asupra parolelor încetează să mai aibă sens.

Ideea este simplă: fiecare utilizator legitim are o pereche de chei, o cheie privată care rămâne pe dispozitivul dvs. și o cheia publică care este copiată pe server în fișierul ~/.ssh/authorized_keys al utilizatorului corespunzător.

Când clientul se conectează, nu trimite cheia privată; trimite cheie publică și apoi semnează o provocare a serverului cu cea privată. Serverul verifică semnătura respectivă cu cea publică și numai dacă se potrivesc permite accesul.

De ce cheile SSH anulează forța brută a parolei

Într-o schemă clasică de parolă, atacatorul trebuie pur și simplu să încerce șiruri de text până când unul se potrivește cu parola stocată (sau cu hash-ul acesteia). Deși o parolă bună are multe combinații posibile, Vorbim despre ordine de mărime, cum ar fi 10¹⁰ posibilități pentru parole obișnuite..

O cheie SSH tipică de 256 de biți (precum cele din Ed25519) se mișcă în spațiile de căutare de ordinul a 10⁶¹⁷ combinațiiÎn practică, este matematic imposibil pentru un atacator să ghicească o cheie privată prin forță brută cu ajutorul computerelor moderne.

Dar, mai mult, serverul nici măcar nu încearcă să calculeze nimic dacă Cheia publică prezentată nu se află în authorized_keysÎn acest caz, elimină conexiunea aproape imediat, fără a invoca PAM sau procesele tradiționale de autentificare, astfel încât consumul de CPU în timpul unui atac masiv este minim.

Generați și verificați cheile SSH pe client

Înainte de a accesa serverul, verificați dacă mașina dvs. are deja o pereche de chei SSH generată. Pur și simplu listați conținutul fișierului ~/.ssh:

ls -l ~/.ssh

Dacă vedeți fișiere precum id_ed25519 și id_ed25519.pub Dacă aveți id_rsa și id_rsa.pub, aveți deja o pereche validă. Ed25519 este mai modern și mai ușor, așa că este de obicei cea mai bună opțiune în zilele noastre.

Dacă nu aveți chei, generați altele noi cu:

ssh-keygen -t ed25519 -C "tu_usuario@tu_equipo"

Comanda va crea două fișiere:

id_ed25519cheia privată, pe care nu ar trebui să o partajați niciodată.
id_ed25519.pubcheia publică, pe care o puteți copia pe servere.

Puteți vizualiza conținutul cheii publice cu:

cat ~/.ssh/id_ed25519.pub

Copiați cheia publică pe server și testați accesul

Pe server, asigurați-vă că există directorul ~/.ssh pentru utilizatorul cu care vă veți conecta (de exemplu, git sau utilizatorul dvs. de administrator) și că are permise 700:

mkdir -p ~/.ssh
chmod 700 ~/.ssh

Apoi adăugați conținutul fișierului id_ed25519.pub al clientului dvs. la ~/.ssh/authorized_keys (creând fișierul dacă acesta nu există) și acordându-i permisiunile 600:

echo "TU_PUBLIC_KEY" >> ~/.ssh/authorized_keys
chmod 600 ~/.ssh/authorized_keys

Nu uita să înlocuiești YOUR_PUBLIC_KEY cu linia completă pe care ai văzut-o folosind `cat` pe mașina ta. De acolo, poți testa conexiunea specificând explicit cheia, dacă dorești.

ssh -i ~/.ssh/id_ed25519 usuario@IP_DEL_SERVIDOR

Dacă totul este bine, Serverul nu va cere o parolă și veți accesa direct shell-ul.În acel moment, ești gata să iei în considerare dezactivarea autentificării prin parolă.

Dezactivați complet autentificarea prin parolă pe server

După ce ați verificat că vă puteți accesa contul cu parola de pe cel puțin un dispozitiv (în mod ideal, două, în cazul în care pierdeți unul), este o idee bună Dezactivați autentificarea cu parolă pentru SSHAsta spulberă din fașă orice încercare de forță brută clasică.

Înainte de a atinge configurația, este o idee bună să vedeți ce fișiere definesc PasswordAuthentication, deoarece în multe instalări moderne Există fișiere .d care suprascriu valoarea fișierului principal sshd_config:

sudo grep -R "PasswordAuthentication" /etc/ssh/

Este obișnuit să găsești ceva de genul:

/etc/ssh/sshd_config.d/50-cloud-init.conf:PasswordAuthentication yes
/etc/ssh/sshd_config:PasswordAuthentication no

În acest caz, configurația efectivă va fi „da”, deoarece fișierul 50-cloud-init.conf este încărcat ulterior și suprascrie valoarea. Puteți verifica rezultatul final aplicat de sshd cu:

sudo sshd -T | grep passwordauthentication

Pentru a dezactiva parolele reale, editați fișierul responsabil (de exemplu /etc/ssh/sshd_config.d/50-cloud-init.conf) și lăsați:

PasswordAuthentication no

Apoi reporniți serviciul SSH:

sudo systemctl restart ssh

Și verificați de două ori cu:

sudo sshd -T | grep passwordauthentication

Dacă returnează „nu”, Încercările de conectare cu parola vor fi respinse imediat.Programe precum PuTTY vor afișa o eroare deoarece nu pot furniza acreditări de tip parolă, dar clienții dvs. cu chei vor continua să funcționeze fără probleme.

Combinarea cheilor SSH cu Fail2ban și alte măsuri

Când eliminați PasswordAuthentication din ecuație, valoarea lui Fail2ban pentru SSH devine mai utilă decât critică, deoarece Boții nici măcar nu au un câmp în care să introduci parola.Chiar și așa, este recomandabil să păstrați jail-ul sshd activ, deoarece servește ca un strat suplimentar împotriva încercărilor neobișnuite de alte tipuri sau a utilizării greșite a cheilor.

Dacă această combinație de Numai chei SSH + Fail2ban + blocare root + liste AllowUsers/AllowGroups optimizate Adăugați un firewall restrictiv (iptables/nftables, UFW, firewalld) și, dacă este cazul, liste de control al accesului cu TCP Wrappers și veți reduce probabilitatea unei intruziuni prin forță brută la un nivel neglijabil.

În medii și mai sensibile, puteți merge mai departe și introduce autentificare cu doi factori (2FA) pentru SSHfolosind module precum Google Authenticator sau similare prin PAM sau chiar restricționând cine poate accesa portul SSH folosind VPN-uri dedicate.

Cu toate aceste elemente bine integrate — detectarea jurnalelor, configurarea atentă a sshd-ului, utilizarea extensivă a Fail2ban, chei SSH în loc de parole și, atunci când este necesar, controale bazate pe IP — un server Linux poate gestiona atacuri continue de tip brute-force asupra SSH și a altor servicii expusemenținând în același timp accesul convenabil și sigur pentru administratori.