Omezení pokusů o zadání hesla v Linuxu pro zabezpečení SSH a služeb

  • Analyzujte protokoly ověřování a upravte sshd_config tak, aby omezil uživatele, porty, protokoly a pokusy, a tím snížil plochu pro útok.
  • Nasaďte Fail2ban pro monitorování klíčových služeb (SSH, web, databáze) a automatické blokování IP adres s mnoha selháními.
  • Použijte SSH klíče místo hesel a zakažte ověřování heslem (PasswordAuthentication), abyste zcela neutralizovali útoky hrubou silou.
  • Posilte ochranu pomocí firewallů, TCP wrapperů a v případě potřeby i 2FA, kombinací více vrstev obrany pro ochranu vašich exponovaných Linuxových serverů.
Lorena Figueredo

17 minut

Omezení pokusů o zadání hesla v Linuxu pro ochranu SSH a služeb

Pokud spravujete linuxový server vystavený internetu, dříve či později uvidíte v logech tisíce pokusů o přihlášení přes SSH z náhodných IP adresNejde o to, že by si vás nenechali v lásce: jsou to automatičtí boti, kteří obcházejí rozsahy IP adres a hledají špatně chráněné dveře.

Na malém serveru se tyto pokusy mohou promítnout do Špičky využití CPU, snížení výkonu a dokonce i občasné výpadky služebDobrou zprávou je, že Linux nabízí arzenál nástrojů pro omezení pokusů o zadání hesla, blokování agresivních IP adres a posílení SSH, což útočníkovi značně ztíží přístup.

Detekce útoků hrubou silou přes SSH a jejich dopad na server

Než začneme s konfigurací čehokoli, je užitečné pochopit, jak zjistit, zda se u nás vyskytl problém útok hrubou silou proti SSH nebo jiným službáma jaké to má účinky na stroj.

Velmi typickým příznakem je pozorování náhlé zvýšení využití CPU bez jakékoli změny legitimního provozu nebo zatížení databázeNapříklad se může stát, že po dobu několika minut dojde k prudkému nárůstu využití CPU, zatímco využití paměti a disku zůstane prakticky beze změny, což obvykle ukazuje na výpočetně náročné procesy (například mnoho pokusů o ověření) spíše než na náročné dotazy.

Pro analýzu toho, co se dělo v určitém intervalu, je velmi užitečné použít journalctlNástroj systemd pro čtení systémových, servisních, kernelových a autentizačních protokolů. Klasický příklad dotazu by byl:

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

S tímto typem dotazu si můžete podrobně prohlédnout Jaké zprávy systém zaznamenal během okna, ve kterém došlo k prudkému nárůstu zatížení CPU?: služby, které se restartují, selhání ověřování, chyby jádra atd.

V mnoha případech najdete opakující se řádky týkající se SSH, například „Neúspěšné heslo pro“ označuje neúspěšné pokusy o přihlášeníTo je prakticky synonymum pro testování přihlašovacích údajů boty hrubou silou.

Kvantifikace neúspěšných pokusů v souboru /var/log/auth.log

V systémech Debian/Ubuntu je klíčový soubor pro sledování čehokoli souvisejícího s ověřováním /var/log/auth.logZde se zaznamenávají úspěšná přihlášení, neúspěšné pokusy, události PAM, zablokování účtů atd.

Pokud chcete vědět, kolikrát byl vzor zaznamenán „Chybné heslo“ v aktuálním protokolu, Můžeš použít:

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

Výsledek může být překvapivý: není neobvyklé vidět tisíce neúspěšných pokusů se nahromadily během několika hodinA nezapomeňte, že se jedná pouze o aktuální soubor.

Protože se protokoly rotují, je důležité zkontrolovat i starší soubory. Časové období aktuální protokol pokrývá můžete zjistit například takto:

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

Takhle budete vědět, Datum prvního a posledního záznamu v souboru auth.logZbytek předchozích pokusů bude v souboru auth.log.1 a v komprimovaných souborech auth.log.N.gz.

Chcete-li zkontrolovat komprimované staré protokoly a spočítat neúspěšné pokusy o zadání hesla, můžete použít:

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

Pokud sečtete, co vidíte v auth.log, auth.log.1 a auth.log.*.gz Získáte dobrou představu o tom, Historický záznam útoků hrubou silou, s přihlédnutím k tomu, že ty nejstarší mohly v důsledku rotace již zmizet.

Jak funguje rotace ověřovacích protokolů

Způsob a frekvence rotace protokolů závisí na konfiguraci logrotateV Ubuntu je rotace souboru auth.log obvykle definována v souboru /etc/logrotate.d/rsyslog, kde obvykle najdete něco jako:

weekly
rotate 4
compress

To znamená, že Protokol se rotuje každý týden, uchovávají se čtyři staré kopie a ty staré se komprimují do souborů .gz.Denní úloha cron je zodpovědná za spuštění logrotate a aplikaci těchto pravidel.

Proto při výpočtu počtu pokusů o hrubou sílu předpokládejte, že Vidíte historická data pouze z doby před několika týdny.Všechno, co se stalo později v čase, už v systému nebude.

Identifikace útočících uživatelů a IP adres

Kromě celkového počtu je důležité vědět Kteří uživatelé jsou cílem a z jakých IP adres útoky pocházejí?S trochou awk na auth.log to máte po ruce.

Chcete-li zobrazit, která uživatelská jména se v neúspěšných pokusech používají:

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

A zobrazení IP adres s nejpodezřelejší aktivitou:

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

Díky tomu budete moci rychle zjistit, zda útočí. skutečné účty z vašeho systému nebo generičtí uživatelé například root, admin, test, user atd. a které IP adresy byste měli nejnaléhavěji zablokovat.

Je to opravdu tak vážné, že se jedná o tisíce pokusů?

Je třeba předpokládat, že pokud je váš server přístupný z internetu a má SSH naslouchá na portu 22 nebo jakémkoli jinémTento server bude přijímat tento typ provozu 24 hodin denně. Je normální vidět tisíce neúspěšných pokusů, pokud server běží delší dobu.

Skutečná gravitace závisí na vašem nastavení:

konfigurace Přibližné riziko
Slabá hesla + otevřené SSH připojení k internetu Velmi vysoké riziko kompromitace
Silná hesla Mírné riziko, ale spotřeba zdrojů
Fail2ban správně nakonfigurován Nízké riziko a vysoce zmírněné útoky
Přístup pouze s SSH klíči Riziko hrubou silou velmi blízké nule

Jinými slovy: automatizované útoky jsou běžné, ale pokud je vaše konfigurace laxní, Stačí jen jedno neúspěšné heslo a přijdete o celý server.Proto je tak důležité omezit pokusy, blokovat IP adresy a pokud možno eliminovat hesla.

Základní zabezpečení SSH: kritické možnosti v sshd_config

Omezení pokusů o zadání hesla v Linuxu pro ochranu SSH a služeb

První obranná linie je uvnitř nás samotných SSH démon (sshd) a jeho konfigurační soubor /etc/ssh/sshd_config (a související soubory .d). Několik dobře vyladěných direktiv výrazně snižuje plochu pro útok.

Mějte na paměti, že v moderních distribucích, jako je Ubuntu 22.04 a novější, sshd nejprve načte /etc/ssh/sshd_config a poté soubory v /etc/ssh/sshd_config.d/*.conf v abecedním pořadí. Cokoli, co se objeví později, může přepsat dříve definované parametry, proto buďte velmi opatrní při změnách.

Zakažte přístup bez hesla a nepotřebné relace

I když je ve většině moderních distribucí dobře nakonfigurovaný, neuškodí si to ověřit. Přihlášení bez definovaného hesla není povoleno.Klíčová směrnice je:

PermitEmptyPasswords no

Obvykle je to zakomentováno nebo explicitně nastaveno na „ne“. Také se ujistěte, že máte vypnuté funkce, které nebudete používat, například... Přesměrování X11 (X11Forwarding) Pokud nepoužíváte vzdálené grafické konzultace:

X11Forwarding no

Pokud jde o protokoly, pokud z jakéhokoli důvodu spravujete velmi starý systém, zkontrolujte, zda jsou povoleny pouze určité akce. SSH protokol 2:

Protocol 2

Změňte výchozí port a omezte, na kterém rozhraní naslouchá.

Další jednoduchý, i když ne zcela spolehlivý trik je Přesuň SSH z portu 22 na nestandardní port.To vás sice neochrání před vážným útočníkem, ale odfiltruje to značné množství automatizovaného šumu, který skenuje pouze 22.

Port 2222
ListenAddress 192.168.56.8

Kromě změny portu můžete zadat konkrétní adresu, na které bude SSH naslouchat, například vaši interní IP adresu, pokud chcete SSH omezit na konkrétní síť. Pokud však vaše distribuce používá ssh.socket od systemd, možná budete muset... Zakažte socket a vraťte se ke klasické službě ssh.service. respektovat konfiguraci portu:

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

Kdykoli změníte port, před zavřením hlavní relace otestujte připojení z jiného terminálu, abyste nezůstali bez vzdáleného přístupu.

Blokovat nebo omezit přístup root

Uživatel root je pro útočníky snadnou kořistí, takže to dává smysl. zabránit připojení přes SSHi s hesly. Toto chování ovládáte direktivou:

PermitRootLogin no

V mnoha moderních instalacích je k dispozici režim „prohibit-password“, který zabraňuje přihlášení heslem, ale ponechává dveře otevřené pro certifikáty. Pokud chcete být v bezpečí, nechte tuto možnost nastavenou na „no“ a pro správu používejte běžný účet se sudo.

Definujte, kdo má přístup: AllowUsers a AllowGroups

Ve výchozím nastavení každý uživatel s platný shell a definované heslo Můžete zkusit připojení přes SSH. To obvykle není ideální na produkčních serverech, kde by měly mít přístup možná jen dva nebo tři účty.

Pro omezení povolených uživatelů máte k dispozici následující direktivy. Povolit uživatelům y PovolitGroups. Například:

AllowUsers harry hermione
AllowGroups gryffindor

Seznam je oddělen mezerami a sémantika je stejná jako u „whitelistu“: Ověřovat se budou moci pouze uvedené účty a skupiny.Také mějte na paměti, že AllowUsers má přednost před AllowGroups, takže je nemíchejte, pokud nemáte jasno v pořadí vyhodnocování.

Dobrou praxí je pracovat primárně s typickými skupinami. sshuséři nebo administrátoři a přidejte tam autorizované účty, místo abyste v souboru uchovávali seznam uživatelů jeden po druhém.

Omezení pokusů o ověření a prostojů

Další vrstva ochrany je uvnitř Snižte počet neúspěšných pokusů o připojení a jak dlouho může relace zůstat neaktivní. Pro první otázku můžete použít:

MaxAuthTries 3

V takovém případě server ukončí spojení po třech neúspěšných pokusech, což Díky tomu je jakýkoli útok, který zkouší mnoho hesel proti stejné SSH relaci, méně efektivní..

Pokud jde o dobu nečinnosti, SSH umožňuje ukončit připojení, která zůstávají otevřená bez aktivity nad definovanou prahovou hodnotu. Interval živého klienta (v sekundách):

ClientAliveInterval 180

Po třech minutách bez provozu server odešle zprávy keepalive a pokud klient neodpoví, Relace se automaticky ukončíJe to způsob, jak snížit rizika spojená se zapomenutými, odemčenými terminály.

Omezení přístupu podle IP adresy: TCP Wrappers a Match

V některých případech by vás mohlo zajímat Pouze určité IP adresy nebo rozsahy mají přístup přes SSHMáte několik způsobů, jak to udělat: od samotného firewallu (iptables/nftables), přes TCP Wrappery, až po bloky Match v sshd_config.

S TCP Wrappery, které se stále používají v mnoha distribucích, je přístup řízen pomocí /etc/hosts.allow a /etc/hosts.deny. Postup je následující: Nejprve se vyhodnotí hosts.allow a poté hosts.deny.Omezujícím příkladem by bylo:

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

S touto konfigurací, Pouze dva konkrétní hostitelé se budou moci připojit přes SSH.a zbytek bude odepřen. Je velmi účinný v uzavřených prostředích, i když méně flexibilní než dobrý moderní firewall.

Další možností, typičtější pro SSH, je použití bloků. Zápas v sshd_config pro použití pravidel na základě adresy nebo uživatele. Představte si, že chcete, aby se uživatel „git“ mohl přihlásit odkudkoli, ale váš administrátorský uživatel „greg“ se může přihlásit pouze z LAN 192.168.1.0/24. Můžete kombinovat pravidla AllowUsers s Match Address, i když musíte být velmi opatrní... neuzavírej se sám před sebou.

Fail2ban: Automatické bloky versus hrubá síla

I když posílíte SSH, boti budou stále zkoušet přihlašovací údaje, což způsobí zatížení CPU a šum v protokolech. Aby se to zmírnilo, je k dispozici toto. Fail2ban, systém prevence narušení založený na protokolech který automaticky blokuje IP adresy s příliš velkým počtem chyb.

Fail2ban je napsán v Pythonu a spoléhá se na „věznice“ neboli věznice, každá přidružená ke službě a jeden nebo více souborů protokoluKdyž detekuje opakovaný vzorec chyb (selhání hesla, zakázaný přístup atd.), spustí akce, obvykle pravidla firewallu, k zablokování zdroje.

Instalace Fail2banu na běžné linuxové distribuce

Základní instalace je poměrně jednoduchá a provádí se pomocí správce balíčků vaší distribuce. V Ubuntu nebo Debianu by stačilo toto:

sudo apt update
sudo apt install fail2ban

V systémech založených na RHEL (RHEL, CentOS, AlmaLinux, Rocky atd.) by typický příkaz byl with dnf nebo yum, v závislosti na verzi:

sudo dnf install fail2ban

Balíček obvykle obsahuje službu systemd, která se spouští automaticky, i když stojí za to ji ověřit. Fail2ban se spouští při bootování a je aktivní:

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

Struktura konfigurace: jail.conf, jail.local a jail.d

Konfigurace se nachází v /etc/fail2ban/Hlavní soubor je jail.conf, ale jeho přímá úprava se nedoporučuje, protože se během aktualizací přepíše. Místo toho byste měli:

  • Vytvořte nebo upravte soubor /etc/fail2ban/jail.local přepsat výchozí hodnoty.
  • Nebo přidejte konkrétní soubory do /etc/fail2ban/jail.d/*.conf.

Fail2ban načte konfiguraci v tomto pořadí:

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

Všechno, co definujete v jail.local, má přednost před vším, co bylo předtím, takže Můžete si to přizpůsobit, aniž byste se dotkli souborů balíčku..

Důležité globální parametry: bantime, maxretry, ignoreip

Uvnitř souboru jail.conf (nebo jail.local) najdete sekci [DEFAULT] s globálními parametry, které ovlivňují všechny jaily, pokud nejsou přepsány. Nejdůležitější jsou:

  • bantime: doba, během které bude IP adresa blokována (v sekundách) po překročení povoleného počtu selhání.
  • maxretry: maximální počet neúspěšných pokusů před uplatněním zákazu.
  • najít čas: časové okno, ve kterém se tyto pokusy počítají (např. 10 m po dobu deseti minut).
  • ignorovatseznam IP adres nebo rozsahů, které by Fail2ban nikdy neměl blokovat (například vaše vlastní veřejná IP adresa nebo vaše síť pro správu).

Například v [VÝCHOZÍ] můžete mít něco takového:

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

S touto konfigurací, Jakákoli IP adresa, která se během deseti minut pětkrát nezdaří, bude na deset minut zablokována., pokud není součástí ignorovaných rozsahů.

Konfigurace jail sshd pro zastavení SSH útoků

Nejběžnějším vězením je SSH. V mnoha distribucích je předkonfigurované v souboru jail.conf; stačí ho jen aktivovat nebo doladit jeho hodnoty v souboru jail.local. Jednoduchý příklad:

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

V tomto případě Tři neúspěšné pokusy o přihlášení zaznamenané v souboru auth.log během deseti minut povedou k desetiminutovému zablokování IP adresy útočníka.Fail2ban vkládá do firewallu pravidla (iptables, nftables nebo UFW, v závislosti na systému), takže připojení z dané IP adresy se ani nedostanou k sshd.

Chcete-li použít jakékoli změny konfigurace, nezapomeňte restartovat službu:

sudo systemctl restart fail2ban

Zobrazit stav věznic a blokovaných IP adres

Fail2ban obsahuje velmi šikovný ovládací nástroj, fail2ban-clientPomocí tohoto nástroje můžete vidět, které věznice jsou aktivní a které IP adresy byly blokovány. Například:

sudo fail2ban-client status

Ukázalo by to něco podobného jako:

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

Podrobné informace o věznici SSHD:

sudo fail2ban-client status sshd

Výstup zahrnuje mimo jiné počet aktuálně zakázaných IP adres a celkový historický počet adres, které byly alespoň jednou zablokovány, plus průběžný seznam IP adres.

S těmito údaji si můžete udělat představu o Kolik škodlivého provozu váš server přijímá a jak efektivní je aktuální konfigurace?.

Trvalé zámky a postupné zákazy

Pokud chcete být obzvláště přísní k recidivistům, Fail2ban nabízí dvě zajímavé strategie: trvalý zákaz a postupný zákaz.

Chcete-li trvale zablokovat jakoukoli IP adresu, která překročí prahovou hodnotu selhání, jednoduše zadejte:

bantime = -1

S tou úpravou, Sankcionované IP adresy se nikdy automaticky neodblokují.Ručně je můžete odstranit pouze v případě potřeby.

Flexibilnější je inkrementální mechanismus, ve kterém každá recidiva prodlužuje dobu zákazu podle určitého faktoru:

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

S těmito hodnotami by postup vypadal nějak takto:

  • 1. blok: 10 minut
  • 2. blok: 40 minut
  • 3. blok: 160 minut (~2 hodiny a 40)
  • 4. blok: kolem 10,6 hodin
  • 5. blok: nějaký 42 hodin

Protože bantime.maxtime je -1, trvání může dále růst donekonečna, čímž ty opravdu silné pálkaře navždy vyřadí ze hry.

Používání Fail2ban mimo SSH: Apache, WordPress, MySQL, internetové obchody…

Jakmile si zvyknete na Fail2ban, logickým krokem je rozšířit ho na... chránit další citlivé služby kromě SSH: webové administrační panely, CMS, databáze atd.

Například pro internetový obchod (Magento, PrestaShop, WooCommerce…) má velký smysl vytvořit vězení, které monitoruje Přístupové protokoly Apache nebo Nginx hledající mnoho kódů 401/403 v /admin nebo /loginMinimální konfigurace založená na Apache by mohla vypadat takto:

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

V prostředí WordPressu je běžnou kombinací sledování /wp-login.php a /xmlrpc.phpToto jsou klasické vstupní body pro útoky hrubou silou a útoky botů. Filtr by mohl být umístěn v souboru /etc/fail2ban/filter.d/wordpress.conf:

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

A odpovídající vězení v souboru jail.local:

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

Stejná myšlenka platí pro exponované databáze (čemuž se obecně nejlépe vyhnout): pokud chcete MySQL chránit před neustálými neúspěšnými pokusy o přístup, můžete pro něj vytvořit filtr. Zprávy „Přístup pro uživatele byl odepřen“ v protokolu chyb:

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

A pak vězení:

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

Na hostingových serverech s ovládacími panely cPanel nebo PleskFail2ban se také dobře integruje: dokáže monitorovat poštovní služby, Apache, FTP a dokonce i samotný ovládací panel a blokovat IP adresy, které překračují povolený počet pokusů o přihlášení.

Autentizace pomocí SSH klíčů: konec útoků na hesla

Všechno výše uvedené pomáhá, ale skutečný skok v kvalitě přichází, když se rozhodnete Přestaňte používat hesla pro SSH a přejděte na veřejné/soukromé klíčeV tom okamžiku útoky hrubou silou na heslo přestávají dávat smysl.

Myšlenka je jednoduchá: každý legitimní uživatel má pár klíčů, soukromý klíč, který zůstává ve vašem zařízení a veřejný klíč, který je zkopírován na server v souboru ~/.ssh/authorized_keys odpovídajícího uživatele.

Když se klient připojí, neodesílá soukromý klíč; odesílá veřejný klíč a poté podepíše výzvu serveru se soukromým. Server porovná tento podpis s veřejným a přístup povolí pouze v případě shody.

Proč SSH klíče ruší hrubou silou hesla

V klasickém schématu s heslem musí útočník jednoduše zkoušet řetězce textu, dokud se jeden neshoduje s uloženým heslem (nebo jeho hašem). I když dobré heslo má mnoho možných kombinací, Mluvíme o řádech, jako je 10¹⁰ možností pro průměrná hesla..

Typický 256bitový SSH klíč (jako ty v Ed25519) se pohybuje ve vyhledávacích prostorech v pořadí 10⁶¹⁷ kombinacíV praxi je pro útočníka matematicky nemožné uhodnout soukromý klíč hrubou silou s moderními počítači.

Ale co víc, server se ani nepokouší nic vypočítat, pokud Předložený veřejný klíč není v authorized_keys.V takovém případě téměř okamžitě ukončí připojení, bez vyvolání PAM nebo tradičních autentizačních procesů, takže spotřeba CPU během masivního útoku je minimální.

Generování a ověření SSH klíčů na klientovi

Před přístupem k serveru zkontrolujte, zda váš počítač již má vygenerovaný pár SSH klíčů. Jednoduše vypište obsah souboru ~/.ssh:

ls -l ~/.ssh

Pokud vidíte soubory jako id_ed25519 a id_ed25519.pub Pokud máte id_rsa a id_rsa.pub, už máte platný pár. Ed25519 je modernější a lehčí, takže je v dnešní době obvykle nejlepší volbou.

Pokud nemáte klíče, vygenerujte si nové pomocí:

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

Příkaz vytvoří dva soubory:

  • id_ed25519: soukromý klíč, který byste nikdy neměli sdílet.
  • id_ed25519.pub: veřejný klíč, který můžete zkopírovat na servery.

Obsah veřejného klíče si můžete prohlédnout pomocí:

cat ~/.ssh/id_ed25519.pub

Zkopírujte veřejný klíč na server a otestujte přístup

Na serveru se ujistěte, že adresář ~/.ssh existuje pro uživatele, pod kterým se budete přihlašovat (například git nebo váš administrátorský uživatel), a že má povolení 700:

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

Pak přidejte obsah souboru id_ed25519.pub vašeho klienta do ~/.ssh/authorized_keys (vytvoření souboru, pokud neexistuje) a udělení oprávnění 600:

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

Nezapomeňte nahradit YOUR_PUBLIC_KEY celým řádkem, který jste viděli při použití příkazu `cat` na vašem počítači. Odtud můžete otestovat připojení explicitním zadáním klíče, pokud chcete.

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

Pokud je vše v pořádku, Server se vás nebude ptát na heslo a přejdete přímo do shellu.V tomto okamžiku jste připraveni zvážit vypnutí ověřování heslem.

Úplně zakažte ověřování heslem na serveru

Jakmile si ověříte, že se k účtu můžete přihlásit pomocí hesla alespoň z jednoho zařízení (ideálně ze dvou, pro případ, že jedno ztratíte), je dobré Zakázat přihlašování heslem pro SSHTo v zárodku potlačí jakýkoli pokus o klasickou hrubou sílu.

Než se dotkneme konfigurace, je dobré zjistit, které soubory definují PasswordAuthentication, protože v mnoha moderních instalacích Existují soubory .d, které přepisují hodnotu hlavního souboru sshd_config.:

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

Je běžné najít něco jako:

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

V takovém případě bude efektivní konfigurace „ano“, protože soubor 50-cloud-init.conf se načte následně a přepíše hodnotu. Konečný výsledek, který sshd používá, si můžete ověřit pomocí:

sudo sshd -T | grep passwordauthentication

Chcete-li zakázat skutečná hesla, upravte příslušný soubor (například /etc/ssh/sshd_config.d/50-cloud-init.conf) a ponechte:

PasswordAuthentication no

Poté restartujte službu SSH:

sudo systemctl restart ssh

A dvakrát zkontrolujte s:

sudo sshd -T | grep passwordauthentication

Pokud se vrátí „ne“, Pokusy o přihlášení heslem budou okamžitě odmítnutyProgramy jako PuTTY zobrazí chybu, protože nemohou poskytnout přihlašovací údaje typu heslo, ale vaši klienti s klíči budou i nadále fungovat bez problémů.

Kombinace SSH klíčů s Fail2banem a dalšími opatřeními

Když z rovnice odstraníte PasswordAuthentication, hodnota Fail2ban pro SSH se stává spíše užitečnou než kritickou, protože Boti ani nemají pole pro zadání hesla.I tak je vhodné ponechat jail sshd aktivní, protože slouží jako další vrstva proti neobvyklým pokusům o použití jiných typů nebo zneužití klíčů.

Pokud tato kombinace Pouze SSH klíče + Fail2ban + root lock + jemně vyladěné seznamy AllowUsers/AllowGroups Přidejte restriktivní firewall (iptables/nftables, UFW, firewalld) a případně seznamy pro řízení přístupu s TCP Wrappery a snížíte pravděpodobnost útoku hrubou silou na zanedbatelnou úroveň.

V ještě citlivějších prostředích můžete jít ještě o krok dál a zavést dvoufaktorové ověřování (2FA) pro SSHpoužívání modulů jako Google Authenticator nebo podobných přes PAM, nebo dokonce omezení přístupu k SSH portu pomocí vyhrazených VPN.

Díky dobře integrovaným všem těmto prvkům – detekci protokolů, pečlivé konfiguraci sshd, rozsáhlému používání Fail2ban, SSH klíčům místo hesel a v případě potřeby i ovládacím prvkům založeným na IP adrese – dokáže linuxový server zvládnout… Neustálé útoky hrubou silou na SSH a další exponované službya zároveň zachovat pohodlný a bezpečný přístup pro administrátory.