Če upravljate strežnik Linux, ki je izpostavljen internetu, boste prej ali slej v dnevnikih videli na tisoče poskusov prijave SSH z naključnih naslovov IPNe gre za to, da bi te imeli radi: to so avtomatizirani boti, ki se pomikajo po IP-naslovih in iščejo slabo zaščitena vrata.
Na majhnem strežniku se lahko ti poskusi prevedejo v Povečana poraba procesorja, poslabšanje zmogljivosti in celo občasni izpadi storitevDobra novica je, da Linux ponuja arzenal orodij za omejevanje poskusov vnosa gesla, blokiranje agresivnih IP-jev in utrjevanje SSH, kar napadalcu zelo oteži dostop.
Odkrivanje napadov s surovo silo SSH in njihov vpliv na strežnik
Preden začnemo s konfiguracijo česar koli, je koristno razumeti, kako zaznati, ali imamo težave napad z brutalno silo na SSH ali druge storitvein kakšen vpliv ima na stroj.
Zelo tipičen simptom je opazovanje nenadno povečanje porabe procesorja brez kakršne koli spremembe legitimnega prometa ali obremenitve baze podatkovNa primer, lahko pride do nekajminutnega porasta obremenitve procesorja, medtem ko poraba pomnilnika in diska ostane praktično nespremenjena, kar običajno kaže na računsko intenzivne procese (kot je veliko poskusov preverjanja pristnosti) in ne na obsežne poizvedbe.
Za analizo dogajanja v določenem intervalu je zelo uporabno uporabiti revijaOrodje systemd za branje dnevnikov sistema, storitev, jedra in preverjanja pristnosti. Klasični primer poizvedbe bi bil:
journalctl --since "2025-11-16 13:10" --until "2025-11-16 13:16"S tovrstnim poizvedovanjem lahko podrobno pregledate Katera sporočila je sistem registriral v oknu, v katerem je procesor dosegel vrhunec?: storitve, ki se znova zaženejo, napake pri preverjanju pristnosti, napake jedra itd.
V mnogih primerih boste našli ponavljajoče se vrstice, povezane s SSH, kot na primer »Neuspešno geslo za«, kar pomeni neuspešne poskuse prijaveTo je praktično sinonim za bote, ki s surovo silo testirajo poverilnice.
Kvantificirajte neuspešne poskuse v /var/log/auth.log
V sistemih Debian/Ubuntu je ključna datoteka za sledenje vsemu, kar je povezano z overjanjem, /var/log/auth.logTukaj se beležijo uspešne prijave, neuspešni poskusi, dogodki PAM, zaklepanje računov itd.
Če želite vedeti, kolikokrat je bil vzorec posnet »Neuspešno geslo« v trenutnem dnevniku, lahko uporabiš:
sudo grep 'Failed password' /var/log/auth.log | wc -lRezultat je lahko presenetljiv: ni neobičajno videti na tisoče neuspelih poskusov se je nabralo v nekaj urahIn ne pozabite, da je to samo trenutna datoteka.
Ker se dnevniki rotirajo, je pomembno pregledati tudi starejše datoteke. Časovno obdobje trenutni dnevnik pokriva takole:
head -n 1 /var/log/auth.log
tail -n 1 /var/log/auth.logTako boste vedeli, Datum prvega in zadnjega zapisa v datoteki auth.logPreostali prejšnji poskusi bodo v datoteki auth.log.1 in v stisnjenih datotekah auth.log.N.gz.
Za pregled stisnjenih starih dnevnikov in štetje neuspešnih poskusov vnosa gesla lahko uporabite:
zgrep 'Failed password' /var/log/auth.log.*.gz | wc -lČe seštejete, kar vidite v auth.log, auth.log.1 in auth.log.*.gz Dobili boste dobro predstavo o Zgodovinski zapis napadov z grobo silo, pri čemer je treba upoštevati, da so najstarejši zaradi rotacije morda že izginili.
Kako deluje rotacija dnevnika preverjanja pristnosti
Način in pogostost vrtenja dnevnikov sta odvisna od konfiguracije logrotatV Ubuntuju je rotacija datoteke auth.log običajno definirana v datoteki /etc/logrotate.d/rsyslog, kjer boste običajno našli nekaj takega:
weekly
rotate 4
compressTo pomeni, da Dnevnik se tedensko rotira, hranijo se štiri stare kopije, stare pa se stisnejo v datoteke .gz.Dnevno opravilo cron je odgovorno za izvajanje logrotate in uporabo teh pravil.
Zato pri izračunu poskusov surove sile predpostavite, da Vidite samo zgodovinske podatke izpred nekaj tednov.Karkoli se je zgodilo dlje v preteklosti, ne bo več v sistemu.
Prepoznajte napadalce in njihove IP-naslove
Poleg skupnega števila je pomembno vedeti kateri uporabniki so tarča napadov in s katerih IP-naslovov izvirajo napadi?Z malo awk-a na auth.log ga imaš pri roki.
Če si želite ogledati, katera uporabniška imena so bila uporabljena v neuspelih poskusih:
sudo grep 'Failed password' /var/log/auth.log \
| awk '{print $(NF-5)}' \
| sort | uniq -cIn če si želite ogledati IP-je z najbolj sumljivo dejavnostjo:
sudo grep 'Failed password' /var/log/auth.log \
| awk '{print $(NF-3)}' \
| sort | uniq -c | headTo vam bo omogočilo, da hitro ugotovite, ali napadajo. pravi računi iz vašega sistema ali generični uporabniki kot so root, admin, test, user itd., in katere IP-je morate najnujneje blokirati.
Je res tako resno, da je na tisoče poskusov?
Predpostaviti je treba, da če je vaš strežnik dostopen iz interneta in ima SSH poslušanje na vratih 22 ali katerih koli drugihTa strežnik bo tovrstni promet prejemal 24 ur na dan. Normalno je, da se pri daljšem delovanju strežnika zabeleži na tisoče neuspelih poskusov.
Dejanska gravitacija je odvisna od vaših nastavitev:
| konfiguracija | Približno tveganje |
|---|---|
| Šibka gesla + odprt SSH do interneta | Zelo veliko tveganje za kompromis |
| Močna gesla | Zmerno tveganje, vendar poraba virov |
| Pravilno konfiguriran Fail2ban | Napadi z nizkim tveganjem in visoko stopnjo ublažitve |
| Dostop samo s ključi SSH | Tveganje zelo blizu ničle zaradi surove sile |
Z drugimi besedami: avtomatizirani napadi so pogosti, če pa je vaša konfiguracija ohlapna, Samo eno neuspešno geslo je dovolj, da izgubite celoten strežnik.Zato je tako pomembno omejiti poskuse, blokirati IP-naslove in, kjer je mogoče, odpraviti gesla.
Osnovno utrjevanje SSH: ključne možnosti v sshd_config
Prva obrambna linija je v nas samih SSH daemon (sshd) in njegova konfiguracijska datoteka /etc/ssh/sshd_config (in povezane datoteke .d). Nekaj dobro nastavljenih direktiv močno zmanjša površino napada.
Upoštevajte, da v sodobnih distribucijah, kot je Ubuntu 22.04 in novejših, sshd najprej prebere /etc/ssh/sshd_config in nato datoteke v /etc/ssh/sshd_config.d/*.conf po abecednem vrstnem redu. Karkoli se pojavi kasneje, lahko prepiše prej definirane parametre, zato bodite zelo previdni pri spreminjanju.
Onemogočite dostop brez gesla in nepotrebne seje
Čeprav je v večini sodobnih distribucij dobro konfiguriran, ni odveč preveriti, ali je Prijave brez določenega gesla niso dovoljene.Ključna direktiva je:
PermitEmptyPasswords noObičajno je zakomentirano ali izrecno nastavljeno na »ne«. Prav tako se prepričajte, da imate onemogočene funkcije, ki jih ne boste uporabljali, kot na primer ... Posredovanje X11 (X11Forwarding) Če ne izvajate oddaljenih grafičnih sej:
X11Forwarding noGlede protokolov, če iz kakršnega koli razloga upravljate zelo star sistem, preverite, ali so dovoljena le določena dejanja. SSH protokol 2:
Protocol 2Spremenite privzeta vrata in omejite, na katerem vmesniku posluša.
Še en preprost, čeprav ne povsem zanesljiv trik je Premaknite SSH iz vrat 22 na nestandardna vrata.To vas ne zaščiti pred resnim napadalcem, vendar filtrira precejšnjo količino avtomatiziranega šuma, ki skenira le 22.
Port 2222
ListenAddress 192.168.56.8Poleg spreminjanja vrat lahko določite tudi določen naslov, na katerem bo SSH poslušal, na primer vaš notranji IP naslov, če ga želite omejiti na določeno omrežje. Če pa vaša distribucija uporablja systemd-ov ssh.socket, boste morda morali ... Onemogočite vtičnico in se vrnite na klasično storitev ssh.service. da se upošteva konfiguracija vrat:
sudo systemctl disable ssh.socket
sudo systemctl daemon-reload
sudo systemctl enable ssh.service
sudo systemctl start ssh.serviceKadar koli spremenite vrata, pred zaprtjem glavne seje preizkusite povezavo z drugega terminala, da ne boste ostali brez oddaljenega dostopa.
Blokirajte ali omejite dostop do root-a
Uporabnik root je lahek plen za napadalce, zato je to smiselno. prepreči povezovanje prek SSHtudi z gesli. To vedenje nadzorujete z direktivo:
PermitRootLogin noV mnogih sodobnih namestitvah je na voljo v načinu »prohibit-password«, ki preprečuje prijave z geslom, vendar pušča vrata odprta za potrdila. Če želite biti varni, pustite nastavljeno na »ne« in za administracijo uporabite običajni račun s sudo.
Določite, kdo ima dostop: Dovoli uporabnike in Dovoli skupine
Privzeto vsak uporabnik z veljavna lupina in definirano geslo Lahko poskusite vzpostaviti povezavo prek SSH. To običajno ni idealno na produkcijskih strežnikih, kjer bi morala imeti dostop morda le dva ali trije računi.
Za omejitev dovoljenih uporabnikov imate na voljo naslednje direktive. Dovoli uporabnikom y DovoliGroups. Na primer:
AllowUsers harry hermione
AllowGroups gryffindorSeznam je ločen s presledki, semantika pa je enaka kot pri "belem seznamu": Samo navedeni računi in skupine bodo lahko overili podatkeUpoštevajte tudi, da ima AllowUsers prednost pred AllowGroups, zato ju ne mešajte, razen če vam ni jasen vrstni red ocenjevanja.
Dobra praksa je delo predvsem s tipičnimi skupinami. uporabniki ssh ali skrbniki in tam dodajte pooblaščene račune, namesto da bi v datoteki hranili seznam uporabnikov enega za drugim.
Omejite poskuse preverjanja pristnosti in čas izpada
Še ena plast zaščite je v Zmanjšajte dovoljeno število neuspelih poskusov na eni povezavi in kako dolgo je lahko seja neaktivna. Za prvo vprašanje lahko uporabite:
MaxAuthTries 3S tem bo strežnik prekinil povezavo po treh napačnih poskusih, kar Zaradi tega je vsak napad, ki preizkuša več gesel proti isti seji SSH, manj učinkovit..
Kar zadeva čas nedejavnosti, SSH omogoča prekinitev povezav, ki ostanejo odprte brez aktivnosti, ki presega določen prag. Interval aktivnega odjemalca (v sekundah):
ClientAliveInterval 180Po treh minutah brez prometa bo strežnik poslal sporočila keepalive in če se odjemalec ne odzove, Seja se bo samodejno zaprlaTo je način za zmanjšanje tveganj zaradi pozabljenih, odklenjenih terminalov.
Omeji dostop po IP-naslovu: TCP Wrappers and Match
V nekaterih primerih vas bo morda zanimalo Dostop prek SSH je možen le do določenih IP-naslovov ali razponovTo lahko storite na več načinov: od samega požarnega zidu (iptables/nftables), prek TCP Wrapperjev do blokov Match v sshd_config.
Z ovijalci TCP, ki se še vedno uporabljajo v mnogih distribucijah, je dostop nadzorovan z /etc/hosts.allow in /etc/hosts.deny. Postopek je naslednji: Najprej se oceni hosts.allow, nato pa hosts.deny.Omejujoč primer bi bil:
# /etc/hosts.deny
ALL: ALL# /etc/hosts.allow
sshd: 192.168.1.89 192.168.1.55
sshd: ALL: DENYS to konfiguracijo, Samo dva določena gostitelja se bosta lahko povezala prek SSHin ostalo bo zavrnjeno. Je zelo učinkovit v zaprtih okoljih, čeprav manj prilagodljiv kot dober sodoben požarni zid.
Druga možnost, bolj značilna za SSH, je uporaba blokov. Stave znotraj sshd_config za uporabo pravil glede na naslov ali uporabnika. Predstavljajte si, da želite, da se uporabnik "git" lahko prijavi od koder koli, vaš skrbniški uporabnik "greg" pa se lahko prijavi samo iz LAN omrežja 192.168.1.0/24. Pravila AllowUsers lahko kombinirate s pravili Match Address, vendar morate biti zelo previdni ... ne zapirajte se pred samim seboj.
Fail2ban: Samodejne blokade proti surovi sili
Tudi če okrepite SSH, bodo boti še vedno poskušali preverjati poverilnice, kar bo povzročalo porabo procesorja in šum v dnevnikih. Da bi to ublažili, je to pomembno. Fail2ban, sistem za preprečevanje vdorov, ki temelji na dnevnikih ki samodejno blokira IP-je s preveč napakami.
Fail2ban je napisan v Pythonu in se zanaša na "zapore" oz. zapornice, vsaka povezana s storitvijo in eno ali več dnevniškimi datotekamiKo zazna ponavljajoč se vzorec napak (napake pri geslu, prepovedan dostop itd.), sproži dejanja, običajno pravila požarnega zidu, da blokira vir.
Namestitev Fail2bana na običajne distribucije Linuxa
Osnovna namestitev je dokaj preprosta z uporabo upravitelja paketov vaše distribucije. V Ubuntuju ali Debianu bi zadostovalo tole:
sudo apt update
sudo apt install fail2banV sistemih, ki temeljijo na RHEL-u (RHEL, CentOS, AlmaLinux, Rocky itd.), bi bil tipičen ukaz with dnf ali yum, odvisno od različice:
sudo dnf install fail2banPaket običajno vključuje storitev systemd, ki se zažene samodejno, čeprav je vredno preveriti, ali je to potrebno. Fail2ban se zažene ob zagonu in je aktiven:
sudo systemctl enable fail2ban
sudo systemctl start fail2ban
sudo systemctl status fail2banStruktura konfiguracije: jail.conf, jail.local in jail.d
Konfiguracija se nahaja v /etc/fail2ban/Glavna datoteka je jail.conf, vendar njeno neposredno urejanje ni priporočljivo, ker se med posodobitvami prepiše. Namesto tega morate:
- Ustvarite ali uredite /etc/fail2ban/jail.local prepisati privzete vrednosti.
- Ali pa dodajte določene datoteke v /etc/fail2ban/jail.d/*.conf.
Fail2ban naloži konfiguracijo v tem vrstnem redu:
/etc/fail2ban/jail.conf
/etc/fail2ban/jail.d/*.conf
/etc/fail2ban/jail.localVse, kar definirate v jail.local, ima prednost pred vsem, kar je bilo prej, zato Prilagodite lahko, ne da bi se dotaknili datotek paketa..
Pomembni globalni parametri: bantime, maxretry, ignoreip
Znotraj datoteke jail.conf (ali jail.local) boste videli razdelek [DEFAULT] z globalnimi parametri, ki vplivajo na vse zapore, razen če so prepisani. Najpomembnejši so:
- bantime: čas, v katerem bo IP blokiran (v sekundah) po preseganju dovoljenega števila napak.
- maxretry: največje število neuspelih poskusov pred uporabo prepovedi.
- najdi čas: časovno okno, v katerem se ti poskusi štejejo (npr. 10 m za deset minut).
- ignorirajip: seznam IP-jev ali obsegov, ki jih Fail2ban ne sme nikoli blokirati (na primer vaš javni IP-naslov ali vaše upravljalno omrežje).
Na primer, v [DEFAULT] bi lahko imeli nekaj takega:
[DEFAULT]
bantime = 600
findtime = 600
maxretry = 5
ignoreip = 127.0.0.1/8 192.168.1.0/24S to konfiguracijo, Vsak IP-naslov, ki v desetih minutah petkrat ne uspe vzpostaviti povezave, bo deset minut blokiran., razen če je del prezrtih obsegov.
Konfigurirajte jail sshd za zaustavitev napadov SSH
Najpogostejši jail je jail SSH. V mnogih distribucijah je vnaprej konfiguriran v datoteki jail.conf; le aktivirati ga morate ali natančno nastaviti njegove vrednosti v datoteki jail.local. Preprost primer:
[sshd]
enabled = true
filter = sshd
logpath = /var/log/auth.log
maxretry = 3
bantime = 600
findtime = 10mV tem primeru oz. Trije neuspešni poskusi prijave, zabeleženi v datoteki auth.log v desetih minutah, bodo povzročili desetminutno blokado IP-naslova napadalca.Fail2ban v požarni zid vstavi pravila (iptables, nftables ali UFW, odvisno od sistema), tako da povezave s tega IP-ja sploh ne dosežejo sshd-ja.
Če želite uporabiti kakršne koli spremembe konfiguracije, ne pozabite znova zagnati storitve:
sudo systemctl restart fail2banOglejte si stanje zaporov in blokiranih IP-jev
Fail2ban vključuje zelo priročen pripomoček za nadzor, odjemalec fail2banS tem orodjem lahko vidite, kateri zapori so aktivni in kateri IP-naslovi so blokirani. Na primer:
sudo fail2ban-client statusPokazalo bi nekaj podobnega:
Status
|- Number of jail: 1
`- Jail list: sshdZa podrobne informacije o zaporu SSHD:
sudo fail2ban-client status sshdIzhodni podatki med drugim vključujejo število trenutno prepovedanih IP-naslovov in skupno zgodovinsko število naslovov, ki so bili vsaj enkrat blokirani, plus tekoči seznam IP-naslovov.
S temi podatki si lahko ustvarite predstavo o Koliko zlonamernega prometa prejema vaš strežnik in kako učinkovita je trenutna konfiguracija?.
Trajne blokade in postopno zapiranje
Če želite biti še posebej strogi do ponavljajočih se kršiteljev, Fail2ban ponuja dve zanimivi strategiji: trajna prepoved in postopna prepoved.
Če želite trajno prepovedati kateri koli IP-naslov, ki presega prag napake, preprosto vnesite:
bantime = -1S to prilagoditvijo, Sankcionirani IP-ji se nikoli ne odblokirajo samodejnoRočno jih lahko odstranite le, če je to potrebno.
Bolj prilagodljiv je mehanizem postopnega povečanja, pri katerem vsaka ponovitev kaznivega dejanja podaljša čas prepovedi glede na določen faktor:
bantime = 10m
bantime.increment = true
bantime.rndtime = 0
bantime.factor = 4
bantime.maxtime = -1S temi vrednostmi bi napredovanje izgledalo nekako takole:
- 1. blok: 10 minut
- 2. blok: 40 minut
- 3. blok: 160 minut (~2 uri in 40)
- 4. blok: okoli 10,6 ur
- 5. blok: nekaj 42 ur
Ker je bantime.maxtime enak -1, trajanje se lahko še naprej povečuje v nedogled, s čimer so resnično močni odbijalci za vedno izpadli iz igre.
Uporaba Fail2ban onkraj SSH: Apache, WordPress, MySQL, spletne trgovine…
Ko enkrat osvojiš Fail2ban, je logično, da ga razširiš na zaščitite druge občutljive storitve poleg SSH: spletne administratorske plošče, CMS, baze podatkov itd.
Na primer, za spletno trgovino (Magento, PrestaShop, WooCommerce…) je zelo smiselno ustvariti zapor, ki spremlja Dnevniki dostopa Apache ali Nginx iščejo veliko kod 401/403 v /admin ali /loginMinimalna konfiguracija, ki temelji na Apacheju, bi lahko bila:
[apache-auth]
enabled = true
filter = apache-auth
logpath = /var/log/apache2/access.log
maxretry = 5
bantime = 3600V okoljih WordPress je pogosta kombinacija spremljanje /wp-login.php in /xmlrpc.phpTo so klasične vstopne točke za napade z grobo silo in napade z boti. Filter bi lahko namestili v datoteko /etc/fail2ban/filter.d/wordpress.conf:
[Definition]
failregex = .*"POST /wp-login.php HTTP.*" 403
ignoreregex =In ustrezen zapor v jail.local:
[wordpress]
enabled = true
filter = wordpress
logpath = /var/log/apache2/access.log
maxretry = 3
bantime = 3600Ista ideja velja za izpostavljene baze podatkov (kar se je na splošno najbolje izogniti): če želite MySQL zaščititi pred nenehnimi neuspešnimi poskusi dostopa, lahko ustvarite filter za Sporočila »Dostop zavrnjen za uporabnika« v dnevniku napak:
[Definition]
failregex = ^<HOST>.*Access denied for user.*$
ignoreregex =In potem zapor:
[mysqld-auth]
enabled = true
filter = mysql
logpath = /var/log/mysql/error.log
maxretry = 5
bantime = 1800Na gostovanju strežnikov z nadzornimi ploščami, kot so cPanel ali PleskFail2ban se tudi dobro integrira: lahko spremlja poštne storitve, Apache, FTP in celo samo nadzorno ploščo ter blokira IP-je, ki s poskusi prijave presegajo dovoljeno mejo.
Avtentikacija s ključi SSH: konec napadov na gesla
Vse našteto pomaga, a pravi preskok v kakovosti pride, ko se odločite Nehajte uporabljati gesla za SSH in preklopite na javne/zasebne ključeNa tej točki napadi z geslom z grobo silo prenehajo imeti smisel.
Ideja je preprosta: vsak legitimni uporabnik ima par ključev, zasebni ključ, ki ostane v vaši napravi in javni ključ, ki se kopira na strežnik v ustrezni uporabniški datoteki ~/.ssh/authorized_keys.
Ko se odjemalec poveže, ne pošlje zasebnega ključa, temveč javni ključ in nato podpiše izziv strežnika z zasebnim. Strežnik preveri ta podpis z javnim in le, če se ujemata, dovoli dostop.
Zakaj SSH ključi izničijo brutalno silo gesla
V klasični shemi gesel mora napadalec preprosto preizkušati nize besedila, dokler se eden ne ujema s shranjenim geslom (ali njegovim zgoščenim geslom). Čeprav ima dobro geslo veliko možnih kombinacij, Govorimo o velikostnih razredih, kot je 10¹⁰ možnosti za povprečna gesla..
Tipičen 256-bitni SSH ključ (kot tisti v Ed25519) se premika v iskalnih prostorih v vrstnem redu 10⁶¹⁷ kombinacijV praksi je matematično nemogoče, da bi napadalec s sodobnimi računalniki uganil zasebni ključ z uporabo surove sile.
Še več, strežnik sploh ne poskuša ničesar izračunati, če Predstavljeni javni ključ ni v authorized_keysV tem primeru skoraj takoj prekine povezavo, ne da bi sprožil PAM ali tradicionalne postopke preverjanja pristnosti, zato je poraba procesorja med obsežnim napadom minimalna.
Generiranje in preverjanje SSH ključev na odjemalcu
Preden dostopate do strežnika, preverite, ali ima vaš računalnik že generiran par ključev SSH. Preprosto navedite vsebino datoteke ~/.ssh:
ls -l ~/.sshČe vidite datoteke, kot so id_ed25519 in id_ed25519.pub Če imate id_rsa in id_rsa.pub, že imate veljaven par. Ed25519 je sodobnejši in lažji, zato je običajno najboljša možnost v teh dneh.
Če nimate ključev, ustvarite nove z:
ssh-keygen -t ed25519 -C "tu_usuario@tu_equipo"Ukaz bo ustvaril dve datoteki:
- id_ed25519: zasebni ključ, ki ga nikoli ne smete deliti.
- id_ed25519.pub: javni ključ, ki ga lahko kopirate na strežnike.
Vsebino javnega ključa si lahko ogledate z:
cat ~/.ssh/id_ed25519.pubKopirajte javni ključ na strežnik in preizkusite dostop
Na strežniku se prepričajte, da imenik ~/.ssh obstaja za uporabnika, s katerim se boste prijavili (na primer git ali vaš skrbniški uporabnik), in da ima dovoljenja 700:
mkdir -p ~/.ssh
chmod 700 ~/.sshNato dodajte vsebino datoteke id_ed25519.pub vaše stranke v ~/.ssh/authorized_keys (ustvarjanje datoteke, če ne obstaja) in ji dodelitev dovoljenj 600:
echo "TU_PUBLIC_KEY" >> ~/.ssh/authorized_keys
chmod 600 ~/.ssh/authorized_keysNe pozabite zamenjati YOUR_PUBLIC_KEY s celotno vrstico, ki ste jo videli z ukazom `cat` na svojem računalniku. Od tam lahko preizkusite povezavo tako, da po želji izrecno določite ključ.
ssh -i ~/.ssh/id_ed25519 usuario@IP_DEL_SERVIDORČe je vse v redu, Strežnik ne bo zahteval gesla in skočili boste neposredno v lupino.Na tej točki ste pripravljeni razmisliti o onemogočanju preverjanja pristnosti z geslom.
Popolnoma onemogočite preverjanje pristnosti gesla na strežniku
Ko preverite, da lahko do svojega računa dostopate z geslom iz vsaj ene naprave (idealno iz dveh, če eno izgubite), je dobro, da Onemogočite prijavo z geslom za SSHTo že v kali zatre vsak poskus klasične surove sile.
Preden se dotaknemo konfiguracije, je dobro preveriti, katere datoteke definirajo PasswordAuthentication, ker v mnogih sodobnih namestitvah Obstajajo datoteke .d, ki prepišejo vrednost glavne datoteke sshd_config.:
sudo grep -R "PasswordAuthentication" /etc/ssh/Pogosto se najde nekaj takega:
/etc/ssh/sshd_config.d/50-cloud-init.conf:PasswordAuthentication yes
/etc/ssh/sshd_config:PasswordAuthentication noV tem primeru bo učinkovita konfiguracija »da«, ker se datoteka 50-cloud-init.conf naloži pozneje in prepiše vrednost. Končni rezultat, ki ga uporablja sshd, lahko preverite z:
sudo sshd -T | grep passwordauthenticationČe želite onemogočiti prava gesla, uredite odgovorno datoteko (na primer /etc/ssh/sshd_config.d/50-cloud-init.conf) in pustite:
PasswordAuthentication noNato znova zaženite storitev SSH:
sudo systemctl restart sshIn dvakrat preverite z:
sudo sshd -T | grep passwordauthenticationČe vrne "ne", Poskusi prijave z geslom bodo takoj zavrnjeniProgrami, kot je PuTTY, bodo prikazali napako, ker ne morejo zagotoviti poverilnic v obliki gesla, vendar bodo vaše stranke s ključi še naprej delovale brez težav.
Kombiniranje SSH ključev s Fail2ban in drugimi ukrepi
Ko iz enačbe odstranite PasswordAuthentication, postane vrednost Fail2ban za SSH bolj koristna kot kritična, saj Boti sploh nimajo polja za vnos gesla.Kljub temu je priporočljivo, da zapor sshd ostane aktiven, saj služi kot dodatna plast pred nenavadnimi poskusi drugih vrst ali zlorabo ključev.
Če ta kombinacija Samo SSH ključi + Fail2ban + root zaklepanje + natančno nastavljeni seznami AllowUsers/AllowGroups Dodajte omejevalni požarni zid (iptables/nftables, UFW, firewalld) in po potrebi sezname za nadzor dostopa s TCP Wrapperji, s čimer boste verjetnost vdora z grobo silo zmanjšali na zanemarljivo raven.
V še bolj občutljivih okoljih lahko greste še korak dlje in uvedete dvofaktorska avtentikacija (2FA) za SSHuporaba modulov, kot je Google Authenticator ali podobno prek PAM-a, ali celo omejevanje dostopa do vrat SSH z uporabo namenskih VPN-jev.
Z vsemi temi elementi, ki so dobro integrirani – zaznavanje dnevnikov, skrbna konfiguracija sshd, obsežna uporaba Fail2ban, ključi SSH namesto gesel in po potrebi nadzor na osnovi IP – lahko strežnik Linux obvladuje nenehni napadi z grobo silo na SSH in druge izpostavljene storitvehkrati pa ohranja priročen in varen dostop za skrbnike.