Begränsa lösenordsförsök i Linux för att säkra SSH och tjänster

Om du hanterar en Linux-server som är exponerad för internet, kommer du förr eller senare att se i loggarna tusentals SSH-inloggningsförsök från slumpmässiga IP-adresserDet är inte så att de har fått ett ogillande mot dig: de är automatiserade robotar som rör sig runt inom IP-intervall och letar efter dåligt skyddade dörrar.

På en liten server kan dessa försök leda till CPU-användningstoppar, prestandaförsämring och till och med enstaka serviceavbrottDen goda nyheten är att Linux erbjuder en arsenal av verktyg för att begränsa lösenordsförsök, blockera aggressiva IP-adresser och härda SSH för att göra det mycket svårt för en angripare.

Upptäcka SSH brute-force-attacker och deras inverkan på servern

Innan vi börjar konfigurera något är det bra att förstå hur man upptäcker om vi upplever en brute-force-attack mot SSH eller andra tjänsteroch vilka effekter det har på maskinen.

Ett mycket typiskt symptom är att se en en plötslig ökning av CPU-användningen utan någon förändring av legitim trafik eller databasbelastningTill exempel kan du ha en CPU-topp i några minuter medan minnes- och diskanvändningen förblir i stort sett oförändrad, vilket vanligtvis tyder på beräkningsintensiva processer (som många autentiseringsförsök) snarare än tunga frågor.

För att analysera vad som hände under ett specifikt intervall är det mycket användbart att använda journalctlSystemd-verktyget för att läsa system-, tjänst-, kärn- och autentiseringsloggar. Ett klassiskt exempel på en fråga skulle vara:

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

Med den typen av fråga kan du granska i detalj Vilka meddelanden registrerade systemet under det fönster då processorn toppade?tjänster som startar om, autentiseringsfel, kärnfel etc.

I många fall hittar du upprepade rader relaterade till SSH, till exempel "Misslyckat lösenord för" indikerar misslyckade inloggningsförsökDet är praktiskt taget synonymt med robotar som bruteforcevis testar inloggningsuppgifter.

Kvantifiera misslyckade försök i /var/log/auth.log

På Debian/Ubuntu-system är nyckelfilen för att spåra allt som rör autentisering /var/log/auth.logDet är här lyckade inloggningar, misslyckade försök, PAM-händelser, kontoutlåsningar etc. registreras.

Om du vill veta hur många gånger mönstret har spelats in "Misslyckat lösenord" i den aktuella loggen, du kan använda:

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

Resultatet kan vara överraskande: det är inte ovanligt att se tusentals misslyckade försök ackumulerades på några timmarOch kom ihåg att det bara är den aktuella filen.

Eftersom loggarna roteras är det viktigt att även granska de äldre filerna. Du kan se vilket tidsintervall den aktuella loggen täcker med något i stil med:

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

På så sätt vet du Datum för den första och sista posten som finns i auth.logResten av de tidigare försöken kommer att vara i auth.log.1 och i de komprimerade filerna auth.log.N.gz.

För att granska komprimerade gamla loggar och räkna misslyckade lösenordsförsök kan du använda:

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

Om du lägger ihop vad du ser i auth.log, auth.log.1 och auth.log.*.gz Du får en bra uppfattning om Historisk rekord av brute-force-attacker, med hänsyn till att de äldsta redan kan ha försvunnit på grund av rotationen.

Så här fungerar rotation av autentiseringsloggar

Hur och med vilken frekvens stockarna roterar beror på konfigurationen av logrotateI Ubuntu definieras rotationen av auth.log vanligtvis i /etc/logrotate.d/rsyslog, där du vanligtvis hittar något i stil med:

weekly
rotate 4
compress

Det betyder att det Loggen roteras varje vecka, fyra gamla kopior behålls och de gamla komprimeras till .gz-filer.Ett dagligt cron-jobb ansvarar för att köra logrotate och tillämpa dessa regler.

Anta därför att när du beräknar dina brute-force-försök Du ser bara historisk data från flera veckor tillbaka.Allt som hände längre tillbaka i tiden kommer inte längre att finnas i systemet.

Identifiera attackerande användare och IP-adresser

Utöver det totala antalet är det viktigt att veta Vilka användare riktas in och från vilka IP-adresser kommer attackerna?Med lite krångel i auth.log har du det till hands.

För att se vilka användarnamn som testas i de misslyckade försöken:

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

Och för att se IP-adresserna med mest misstänkt aktivitet:

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

Detta gör att du snabbt kan upptäcka om de attackerar. riktiga konton från ditt system eller generiska användare såsom root, admin, test, user, etc., och vilka IP-adresser du bör blockera mest brådskande.

Är det verkligen så allvarligt att det finns tusentals försök?

Det måste antas att om din server är åtkomlig från internet och har SSH-lyssning på port 22 eller någon annanDen här servern tar emot den här typen av trafik dygnet runt. Det är normalt att se tusentals misslyckade försök om servern har varit igång under en längre tid.

Den faktiska gravitationen beror på dina inställningar:

konfiguration	Ungefärlig risk
Svaga lösenord + öppen SSH till internet	Mycket hög risk för kompromiss
Starka lösenord	Måttlig risk, men resursförbrukning
Fail2ban korrekt konfigurerad	Låg risk och mycket mildrade attacker
Åtkomst endast med SSH-nycklar	Risk mycket nära noll med råstyrka

Med andra ord: automatiserade attacker är vanliga, men om din konfiguration är slapp, Bara ett misslyckat lösenord räcker för att du ska förlora hela servern.Därför är det så viktigt att begränsa försök, blockera IP-adresser och, där det är möjligt, eliminera lösenord.

Grundläggande SSH-härdning: viktiga alternativ i sshd_config

Den första försvarslinjen är inom en själv SSH-daemonen (sshd) och dess konfigurationsfil /etc/ssh/sshd_config (och tillhörande .d-filer). Några få väl avstämda direktiv minskar attackytan avsevärt.

Tänk på att i moderna distributioner som Ubuntu 22.04 och senare, sshd läser först /etc/ssh/sshd_config och sedan filerna i /etc/ssh/sshd_config.d/*.conf i alfabetisk ordning. Allt som visas senare kan skriva över tidigare definierade parametrar, så var mycket försiktig med vad du ändrar.

Inaktivera lösenordsfri åtkomst och onödiga sessioner

Även om det är välkonfigurerat i de flesta moderna distributioner, skadar det inte att bekräfta det. Inloggningar utan ett definierat lösenord är inte tillåtna.Det viktigaste direktivet är:

PermitEmptyPasswords no

Det är vanligtvis kommenterat bort eller uttryckligen inställt på "nej". Se också till att du har inaktiverat funktioner som du inte kommer att använda, till exempel... X11-vidarebefordran (X11Forwarding) Om du inte utför grafiksessioner på distans:

X11Forwarding no

Angående protokoll, om du av någon anledning hanterar ett mycket gammalt system, kontrollera att endast vissa åtgärder är tillåtna. SSH-protokoll 2:

Protocol 2

Ändra standardporten och begränsa vilket gränssnitt den lyssnar på.

Ett annat enkelt, men inte idiotsäkert, knep är Flytta SSH från port 22 till en port som inte är standard.Detta skyddar dig inte från en allvarlig angripare, men det filtrerar bort en betydande mängd automatiserat brus som bara skannar 22.

Port 2222
ListenAddress 192.168.56.8

Förutom att ändra porten kan du ange en specifik adress som SSH ska lyssna på, till exempel din interna IP-adress om du vill begränsa den till ett specifikt nätverk. Men om din distribution använder systemds ssh.socket kan du behöva... Inaktivera socketen och återgå till den klassiska ssh.service-tjänsten. för att respektera portkonfigurationen:

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

När du byter port, testa anslutningen från en annan terminal innan du stänger huvudsessionen, så att du inte fastnar utan fjärråtkomst.

Blockera eller begränsa root-åtkomst

Root-användaren är ett lätt offer för angripare, så det är logiskt. förhindra anslutning via SSHäven med lösenord. Du styr detta beteende med direktivet:

PermitRootLogin no

I många moderna installationer finns det ett läge som "prohibit-password", vilket förhindrar lösenordsinloggningar men lämnar dörren öppen för certifikat. Om du vill vara på den säkra sidan, låt det vara inställt på "no" och använd ett vanligt konto med sudo för administration.

Definiera vem som har åtkomst: AllowUsers och AllowGroups

Som standard är alla användare med giltigt skal och definierat lösenord Du kan prova att ansluta via SSH. Det är vanligtvis inte idealiskt på produktionsservrar, där kanske bara två eller tre konton ska ha åtkomst.

För att begränsa antalet tillåtna användare har du följande direktiv. Tillåt användare y Tillåt grupper. Till exempel:

AllowUsers harry hermione
AllowGroups gryffindor

Listan är separerad med mellanslag och semantiken är densamma som för en "vitlista": Endast listade konton och grupper kommer att kunna autentiseraTänk också på att AllowUsers har företräde framför AllowGroups, så blanda dem inte om du inte är tydlig med utvärderingsordningen.

En bra vana är att främst arbeta med typiska grupper. användare eller administratörer och lägg till de auktoriserade kontona där, istället för att ha en lista över användare en efter en i filen.

Begränsa autentiseringsförsök och driftstopp

Ytterligare ett skyddslager finns i Minska antalet misslyckade försök som tillåts på en enda anslutning och hur länge en session kan vara inaktiv. För den första frågan kan du använda:

MaxAuthTries 3

Med detta kommer servern att stänga anslutningen efter tre felaktiga försök, vilket Detta gör alla attacker som försöker använda många lösenord mot samma SSH-session mindre effektiva..

När det gäller inaktiv tid låter SSH dig avsluta anslutningar som förblir öppna utan aktivitet utöver ett definierat tröskelvärde. KlientLiveIntervall (i sekunder):

ClientAliveInterval 180

Efter tre minuter utan trafik skickar servern keepalive-meddelanden och om klienten inte svarar, Sessionen avslutas automatisktDet är ett sätt att minska riskerna med bortglömda, olåsta terminaler.

Begränsa åtkomst via IP-adress: TCP-omslag och matchning

I vissa fall kan du vara intresserad av Endast vissa IP-adresser eller intervall kan komma åt via SSHDu har flera sätt att göra det: från själva brandväggen (iptables/nftables), via TCP Wrappers, till Match-blocken i sshd_config.

Med TCP-omslag, som fortfarande används i många distributioner, styrs åtkomst med /etc/hosts.allow och /etc/hosts.deny. Flödet är: Först utvärderas hosts.allow och sedan hosts.deny.Ett restriktivt exempel skulle vara:

# /etc/hosts.deny
ALL: ALL

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

Med den konfigurationen, Endast två specifika värdar kommer att kunna ansluta via SSHoch resten kommer att nekas. Den är mycket effektiv i slutna miljöer, även om den är mindre flexibel än en bra modern brandvägg.

Ett annat alternativ, mer typiskt för SSH, är att använda block Match i sshd_config för att tillämpa regler baserade på adress eller användare. Tänk dig att du vill att användaren "git" ska kunna logga in var som helst, men din administratörsanvändare "greg" kan bara logga in från LAN 192.168.1.0/24. Du kan kombinera AllowUsers med Match Address-regler, men du måste vara mycket försiktig med att... stäng inte av dig själv.

Fail2ban: Automatiska blockeringar kontra brute force

Även om du förstärker SSH kommer bottar fortfarande att försöka få inloggningsuppgifter, vilket orsakar CPU-användning och loggbrus. För att mildra detta spelar detta in. Fail2ban, ett loggbaserat intrångsskyddssystem vilket automatiskt blockerar IP-adresser med för många fel.

Fail2ban är skrivet i Python och förlitar sig på "fängelser" eller jails, var och en associerad med en tjänst och en eller flera loggfilerNär den upptäcker ett upprepat felmönster (lösenordsfel, otillåten åtkomst etc.) utlöser den åtgärder, vanligtvis brandväggsregler, för att blockera källan.

Installera Fail2ban på vanliga Linuxdistributioner

Grundinstallationen är ganska enkel med hjälp av din distributions pakethanterare. På Ubuntu eller Debian räcker detta:

sudo apt update
sudo apt install fail2ban

I RHEL-baserade system (RHEL, CentOS, AlmaLinux, Rocky, etc.) skulle det typiska kommandot vara med dnf eller yum, beroende på version:

sudo dnf install fail2ban

Paketet innehåller vanligtvis en systemd-tjänst som startar automatiskt, även om det är värt att kontrollera att Fail2ban startar vid uppstart och är aktiv:

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

Konfigurationsstruktur: jail.conf, jail.local och jail.d

Konfigurationen finns i /etc/fail2ban/Huvudfilen är jail.conf, men det rekommenderas inte att redigera den direkt eftersom den skrivs över under uppdateringar. Istället bör du:

• Skapa eller redigera /etc/fail2ban/jail.local för att skriva över standardvärdena.
• Eller lägg till specifika filer i /etc/fail2ban/jail.d/*.conf.

Fail2ban laddar konfigurationen i denna ordning:

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

Allt du definierar i jail.local har företräde framför allt som kom före, så Du kan anpassa utan att röra paketfilerna..

Viktiga globala parametrar: bantime, maxretry, ignoreip

Inuti jail.conf (eller jail.local) ser du en [DEFAULT]-sektion med globala parametrar som påverkar alla jailer om de inte åsidosätts. De viktigaste är:

• bantime: tid under vilken en IP-adress blockeras (i sekunder) efter att antalet tillåtna fel har överskridits.
• maxretry: maximalt antal misslyckade försök innan avstängningen tillämpas.
• hitta tid: tidsfönster där dessa försök räknas (t.ex. 10 m i tio minuter).
• ignoreralista över IP-adresser eller intervall som Fail2ban aldrig ska blockera (till exempel din egen publika IP-adress eller ditt hanteringsnätverk).

Till exempel kan du ha något liknande detta i [STANDARD]:

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

Med den konfigurationen, Varje IP-adress som misslyckas fem gånger under tio minuter kommer att blockeras i tio minuter., såvida det inte är en del av de ignorerade intervallen.

Konfigurera jail sshd för att stoppa SSH-attacker

Den vanligaste jailen är SSH-jailen. I många distributioner är den förkonfigurerad i jail.conf; du behöver bara aktivera den eller finjustera dess värden i jail.local. Ett enkelt exempel:

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

I detta fall, Tre misslyckade inloggningsförsök som loggas i auth.log inom tio minuter kommer att resultera i en tiominutersblockering av angriparens IP-adress.Fail2ban injicerar reglerna i brandväggen (iptables, nftables eller UFW, beroende på systemet) så att anslutningar från den IP-adressen inte ens når sshd.

För att tillämpa eventuella konfigurationsändringar, kom ihåg att starta om tjänsten:

sudo systemctl restart fail2ban

Visa status för fängelser och blockerade IP-adresser

Fail2ban innehåller ett mycket praktiskt kontrollverktyg, fail2ban-klientMed det här verktyget kan du se vilka fängelser som är aktiva och vilka IP-adresser som har blockerats. Till exempel:

sudo fail2ban-client status

Det skulle visa något liknande:

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

För detaljerad information om SSHD-fängelset:

sudo fail2ban-client status sshd

Utdata inkluderar bland annat antalet för närvarande avstängda IP-adresser och totalt historiskt antal adresser som har blockerats minst en gång, plus den pågående IP-listan.

Med dessa uppgifter kan du få en uppfattning om Hur mycket skadlig trafik tar din server emot och hur effektiv är den nuvarande konfigurationen?.

Permanenta lås och stegvis förbudstid

Om du vill vara särskilt hård mot återfallsförbrytare erbjuder Fail2ban två intressanta strategier: permanent förbud och stegvis förbud.

För att permanent avstänga en IP-adress som överskrider felgränsen, ange helt enkelt:

bantime = -1

Med den justeringen, Sanktionerade IP-adresser avblockeras aldrig automatisktDu kan bara ta bort dem manuellt om det behövs.

Mer flexibel är den stegvisa mekanismen, där varje återfall ökar förbudstiden enligt en faktor:

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

Med dessa värden skulle progressionen se ut ungefär så här:

• 1:e blocket: 10 minuter
• 2:a blocket: 40 minuter
• 3:e blocket: 160 minuter (~2 timmar och 40)
• 4:e blocket: runt 10,6 timmar
• 5:e blocket: några 42 timmar

Eftersom bantime.maxtime är -1, varaktigheten kan fortsätta att växa i all oändlighet, vilket lämnar de riktigt tunga slagmännen utanför spelet för alltid.

Använda Fail2ban utöver SSH: Apache, WordPress, MySQL, webbutiker…

När du väl fått kläm på Fail2ban är det logiska att utöka det till skydda andra känsliga tjänster förutom SSHwebbadministrationspaneler, CMS, databaser etc.

Till exempel, för en webbutik (Magento, PrestaShop, WooCommerce…) är det mycket vettigt att skapa en jailback som övervakar Apache- eller Nginx-åtkomstloggar som letar efter många 401/403-koder i /admin eller /loginEn minimal Apache-baserad konfiguration skulle kunna vara:

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

I WordPress-miljöer är en vanlig kombination att övervaka /wp-login.php och /xmlrpc.phpDessa är de klassiska ingångspunkterna för brute-force- och botattacker. Filtret kan placeras i /etc/fail2ban/filter.d/wordpress.conf:

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

Och motsvarande fängelse i jail.local:

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

Samma idé gäller för exponerade databaser (något som generellt sett bäst undviks): om du vill skydda MySQL från kontinuerliga misslyckade åtkomstförsök kan du skapa ett filter för Meddelanden ”Åtkomst nekad för användare” i felloggen:

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

Och sedan fängelse:

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

På servrar med kontrollpaneler cPanel eller PleskFail2ban integreras också bra: det kan övervaka e-posttjänster, Apache, FTP och till och med själva kontrollpanelen, och blockera IP-adresser som överskrider gränsen vid inloggningsförsök.

Autentisering med SSH-nycklar: slutet på lösenordsattacker

Allt ovanstående hjälper, men det verkliga kvalitetssprånget kommer när du bestämmer dig Sluta använda lösenord för SSH och byt till publika/privata nycklarVid den tidpunkten upphör brute-force lösenordsattacker att vara meningsfulla.

Idén är enkel: varje legitim användare har ett nyckelpar, en privat nyckel som finns kvar på din enhet och en den publika nyckeln som kopieras till servern i motsvarande användares ~/.ssh/authorized_keys-fil.

När klienten ansluter skickar den inte den privata nyckeln; den skickar offentlig nyckel och signerar sedan en serverutmaning med den privata. Servern kontrollerar den signaturen mot den publika, och endast om de matchar tillåter den åtkomst.

Varför SSH-nycklar omintetgör lösenord med brute force

I ett klassiskt lösenordssystem behöver angriparen helt enkelt prova textsträngar tills en matchar det lagrade lösenordet (eller dess hash). Även om ett bra lösenord har många möjliga kombinationer, Vi pratar om storleksordningar som 10¹⁰ möjligheter för genomsnittliga lösenord..

En typisk 256-bitars SSH-nyckel (som de i Ed25519) rör sig i sökutrymmen i storleksordningen 10⁶¹⁷ kombinationerI praktiken är det matematiskt omöjligt för en angripare att gissa en privat nyckel med råstyrka med moderna datorer.

Men dessutom försöker servern inte ens beräkna någonting om Den presenterade publika nyckeln finns inte i authorized_keysI så fall avbryts anslutningen nästan omedelbart, utan att PAM eller traditionella autentiseringsprocesser anropas, så CPU-förbrukningen under en massiv attack är minimal.

Generera och verifiera SSH-nycklar på klienten

Innan du använder servern, kontrollera om din maskin redan har ett genererat SSH-nyckelpar. Lista helt enkelt innehållet i ~/.ssh:

ls -l ~/.ssh

Om du ser filer som id_ed25519 och id_ed25519.pub Om du använder id_rsa och id_rsa.pub har du redan ett giltigt par. Ed25519 är modernare och lättare, så det är oftast det bästa alternativet nuförtiden.

Om du inte har några nycklar, generera nya med:

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

Kommandot skapar två filer:

• id_ed25519: den privata nyckeln, som du aldrig bör dela.
• id_ed25519.pub: den publika nyckeln, som du kan kopiera till servrarna.

Du kan se innehållet i den publika nyckeln med:

cat ~/.ssh/id_ed25519.pub

Kopiera den publika nyckeln till servern och testa åtkomsten

På servern, se till att katalogen ~/.ssh finns för den användare du kommer att logga in som (till exempel git eller din administratörsanvändare) och att den har tillstånd 700:

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

Lägg sedan till innehållet i din klients id_ed25519.pub till ~/.ssh/authorized_keys (skapar filen om den inte finns) och ger den behörighet 600:

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

Kom ihåg att ersätta YOUR_PUBLIC_KEY med hela raden du såg med `cat` på din maskin. Därifrån kan du testa anslutningen genom att explicit ange nyckeln om du vill.

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

Om allt är bra, Servern kommer inte att fråga efter ett lösenord och du hoppar direkt till skalet.Vid den tidpunkten är du redo att överväga att inaktivera lösenordsautentisering.

Inaktivera lösenordsautentisering helt på servern

När du har verifierat att du kan komma åt ditt konto med ditt lösenord från minst en enhet (helst två, ifall du skulle tappa bort en), är det en bra idé Inaktivera lösenordsinloggning för SSHDetta kväver alla försök till klassisk råstyrka i sin linda.

Innan du vidrör konfigurationen är det en bra idé att se vilka filer som definierar PasswordAuthentication, eftersom det i många moderna installationer Det finns .d-filer som skriver över värdet för huvudfilen sshd_config.:

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

Det är vanligt att hitta något i stil med:

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

I så fall blir den effektiva konfigurationen "ja" eftersom filen 50-cloud-init.conf laddas efteråt och skriver över värdet. Du kan verifiera det slutliga resultatet som sshd tillämpar med:

sudo sshd -T | grep passwordauthentication

För att inaktivera riktiga lösenord, redigera den ansvariga filen (till exempel /etc/ssh/sshd_config.d/50-cloud-init.conf) och lämna:

PasswordAuthentication no

Starta sedan om SSH-tjänsten:

sudo systemctl restart ssh

Och dubbelkolla med:

sudo sshd -T | grep passwordauthentication

Om den returnerar "nej", Lösenordsinloggningsförsök kommer att avvisas omedelbartProgram som PuTTY kommer att visa ett fel eftersom de inte kan tillhandahålla lösenordsbaserade inloggningsuppgifter, men dina klienter med nycklar kommer att fortsätta fungera utan problem.

Kombinera SSH-nycklar med Fail2ban och andra åtgärder

När du tar bort PasswordAuthentication från ekvationen blir värdet för Fail2ban för SSH mer användbart än kritiskt, eftersom Botarna har inte ens ett fält att ange lösenordet i.Ändå är det lämpligt att hålla sshd-jailen aktiv eftersom den fungerar som ett extra lager mot ovanliga försök av andra typer eller missbruk av nycklar.

Om denna kombination av Endast SSH-nycklar + Fail2ban + root lock + finjusterade AllowUsers/AllowGroups-listor Lägg till en restriktiv brandvägg (iptables/nftables, UFW, firewalld) och, om lämpligt, åtkomstkontrolllistor med TCP-wrappers, så har du minskat sannolikheten för brute-force-intrång till en försumbar nivå.

I ännu känsligare miljöer kan man gå ett steg längre och introducera tvåfaktorsautentisering (2FA) för SSHanvända moduler som Google Authenticator eller liknande via PAM, eller till och med begränsa vem som kan komma åt SSH-porten med hjälp av dedikerade VPN-tjänster.

Med alla dessa element väl integrerade – loggdetektering, noggrann sshd-konfiguration, omfattande användning av Fail2ban, SSH-nycklar istället för lösenord och, vid behov, IP-baserade kontroller – kan en Linux-server hantera kontinuerliga brute-force-attacker mot SSH och andra exponerade tjänstersamtidigt som administratörer bibehåller bekväm och säker åtkomst.