Zabezpečení SSH v roce 2026: Klíče, Fail2Ban, posílení zabezpečení – kompletní průvodce

Bezpečnost SSH je v roce 2026 stále kritická

Dovolte nám vysvětlit, proč tento článek začínáme právě těmito slovy: průměrný Linux server dostává stovky pokusů o brute-force SSH denně. Ne týdně — denně. A během aktivních útoků může toto číslo vzrůst na tisíce.

Pokud jste se někdy podívali do /var/log/auth.log na čerstvém VPS (Cloud), víte, o čem mluvíme. Během několika hodin po spuštění je váš server již pod palbou. Automatizovaní boti neustále skenují IP rozsahy a hledají servery se slabými hesly, standardními porty a povoleným root přihlášením. Nemusí být sofistikovaní — příliš mnoho serverů stále funguje s úrovní zabezpečení „dveře bez zámku".

Dobrá zpráva: SSH je jeden z nejbezpečnějších protokolů, jaké kdy byly vytvořeny.

Špatná zpráva: většina lidí ho nikdy správně nenakonfiguruje.

Autentizace heslem: čas jít dál

Buďme upřímní — hesla jsou pohodlná. Můžete si je zapamatovat (někdy), zadat z jakéhokoli zařízení a nevyžadují speciální nastavení. Ale v roce 2026 spoléhat na autentizaci heslem pro SSH je jako zabezpečit bankovní trezor visacím zámkem.

Matematika je nemilosrdná. I „silné" 12znakové heslo se smíšenými velkými a malými písmeny, čísly a symboly má asi 72 bitů entropie. SSH klíč? 4096 bitů kryptografické náhodnosti. To není jen lepší — to je úplně jiný vesmír bezpečnosti.

Kromě brute force mají hesla další problémy: mohou být vylákána phishingem, odpozorována přes rameno, náhodně commitnuta do git repozitáře (ano, to se děje neustále) nebo vytažena ze špatně zabezpečeného správce hesel. SSH klíče eliminují téměř všechny tyto vektory útoku.

Výhoda klíčů

Autentizace SSH klíčem funguje na jednoduchém, ale elegantním principu: váš privátní klíč nikdy neopustí váš počítač. Když se připojujete k serveru, ten vás vyzve — dokažte, že máte privátní klíč odpovídající veřejnému klíči na serveru. To se děje prostřednictvím kryptografické matematiky — žádné tajemství se nepřenáší po síti.

I kdyby někdo zachytil celou vaši SSH relaci, nemůže extrahovat privátní klíč. I kdyby někdo kompromitoval server a ukradl soubor authorized_keys — stále se nemůže přihlásit jako vy bez privátního klíče. To je síla asymetrické kryptografie.

Generování SSH klíčů: jak na to správně

Ne všechny SSH klíče jsou stejné. V roce 2026 máte několik možností a volba má větší význam, než se zdá.

*256bitový klíč Ed25519 poskytuje bezpečnost ekvivalentní ~3000bitovému RSA díky efektivitě eliptických křivek.

Vytvoření klíče Ed25519 (doporučeno)

Na vašem lokálním počítači (ne na serveru) otevřete terminál a spusťte:

ssh-keygen -t ed25519 -C "your_email@example.com"

Budete požádáni o umístění souboru a passphrase. Vždy používejte silnou passphrase. Ano, to znamená zadávat ji při každém připojení — ale ssh-agent ji může bezpečně cachovat a samotná passphrase poskytuje kritickou ochranu, pokud někdo získá váš soubor privátního klíče.

Pro starší systémy: RSA 4096

Některé starší systémy nepodporují Ed25519. V takových případech použijte RSA s maximální velikostí klíče:

ssh-keygen -t rsa -b 4096 -C "your_email@example.com"

Parametr -b 4096 je kritický. Výchozí RSA klíče jsou často 2048 bitů — technicky stále bezpečné, ale s menší rezervou do budoucna. Pokud vytváříte klíče dnes, není důvod nepoužít 4096.

Nasazení klíčů na server

Vygenerovali jste klíče. Nyní je potřeba doručit je na server — konkrétně veřejný klíč. Privátní klíč zůstává na vašem počítači. Tečka.

Jednoduchý způsob: ssh-copy-id

Pokud se stále můžete přihlásit heslem, toto je nejrychlejší metoda:

ssh-copy-id -i ~/.ssh/id_ed25519.pub user@your-server-ip

Tento příkaz automaticky vytvoří adresář ~/.ssh na serveru, pokud je potřeba, přidá váš veřejný klíč do authorized_keys a nastaví správná oprávnění. Hotovo.

Manuální metoda

Někdy ssh-copy-id není dostupný nebo potřebujete větší kontrolu. Zde je manuální postup:

# Na lokálním počítači — zobrazte veřejný klíč
cat ~/.ssh/id_ed25519.pub
# Na serveru — vytvořte SSH adresář a soubor
mkdir -p ~/.ssh
chmod 700 ~/.ssh
nano ~/.ssh/authorized_keys
# Vložte veřejný klíč, uložte, pak nastavte oprávnění
chmod 600 ~/.ssh/authorized_keys

Správa více klíčů

Zkušení uživatelé často mají různé klíče pro různé servery — jeden pro práci, jeden pro osobní projekty, jeden pro ten vedlejší projekt, který se určitě nestane hlavní prací. Spravovat to je jednodušší, než se zdá.

Vytvořte ~/.ssh/config na lokálním počítači:

Host work-server
    HostName 192.168.1.100
    User admin
    IdentityFile ~/.ssh/id_work_ed25519
Host personal-vps
    HostName 203.0.113.50
    User deploy
    IdentityFile ~/.ssh/id_personal_ed25519
    Port 2222

Nyní můžete jednoduše napsat ssh work-server místo pamatování IP adres, uživatelských jmen a umístění klíčů.

Zpevnění konfigurace SSH

Autentizace klíčem je obrovské zlepšení bezpečnosti, ale je to jen začátek. Samotný SSH démon má četná nastavení, která mohou dramaticky zvýšit vaši ochranu.

Upravte /etc/ssh/sshd_config na serveru. Zde je to nejdůležitější:

Zakažte přihlášení jako root

PermitRootLogin no

Tohle je bez diskuse. I s autentizací klíčem je povolení přímého root přihlášení zbytečné riziko. Vytvořte běžného uživatele, přidejte ho do skupiny sudo a připojujte se jako on. Útočník nyní musí kompromitovat dvě věci: váš SSH klíč a sudo heslo.

Zakažte autentizaci heslem

PasswordAuthentication no
PubkeyAuthentication yes

Jakmile potvrdíte, že autentizace klíčem funguje — úplně zakažte hesla. Tato jediná změna eliminuje 99 % automatizovaných útoků na váš server. Boti mohou bušit do vašeho přihlášení celý den — bez platného klíče se nikam nedostanou.

Změňte výchozí port

Port 2222

Tohle je security through obscurity — nezastaví to cíleného útočníka, ale eliminuje to šum od automatických skenerů bombardujících port 22. Váš auth.log vám poděkuje. Zvolte jakýkoli port nad 1024 a pod 65535.

Omezte přístup uživatelů

AllowUsers deploy admin
# nebo
AllowGroups sshusers

Vytvořte whitelist těch, kdo se mohou připojit přes SSH. I kdyby útočník nějakým způsobem vytvořil uživatele v systému, nemůže se připojit přes SSH, pokud není na tomto seznamu.

Zpevnění protokolu a šifer

# Používat pouze SSH protokol 2
Protocol 2
# Pouze silné šifry
Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com
# Silné algoritmy výměny klíčů
KexAlgorithms curve25519-sha256,curve25519-sha256@libssh.org
# Silné MAC
MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com

Tato nastavení vypínají zastaralé, potenciálně zranitelné algoritmy. Kompromis je, že velmi staří SSH klienti se nemusí připojit — ale pokud něco běží na SSH z roku 2010, má větší problémy.

Bezpečnost relace

# Odpojit neaktivní relace po 15 minutách
ClientAliveInterval 300
ClientAliveCountMax 3
# Omezit pokusy o autentizaci
MaxAuthTries 3
# Zakázat prázdná hesla (samozřejmě)
PermitEmptyPasswords no

Po provedení změn vždy otestujte konfiguraci před restartem:

sudo sshd -t

Pokud nejsou žádné chyby, restartujte SSH službu:

sudo systemctl restart sshd

Za hranice základní konfigurace

Zpevněný sshd_config je skvělý, ale defense in depth znamená přidávání dalších vrstev. Zde jsou nejúčinnější další opatření.

Fail2Ban: váš automatický strážce

Fail2Ban monitoruje logy a automaticky banuje IP adresy vykazující škodlivé chování. Pro SSH sleduje neúspěšné pokusy o přihlášení a blokuje provinilce.

sudo apt install fail2ban
sudo systemctl enable fail2ban

Výchozí konfigurace je přijatelná, ale můžete ji upravit v /etc/fail2ban/jail.local:

[sshd]
enabled = true
port = 2222
filter = sshd
logpath = /var/log/auth.log
maxretry = 3
bantime = 3600
findtime = 600

Toto zabanuje jakoukoli IP se 3 neúspěšnými pokusy během 10 minut na 1 hodinu. Ano, poměrně agresivní, ale automatizované útoky vyžadují agresivní odpověď.

Pravidla firewallu

Použijte UFW k omezení SSH přístupu:

# Povolit SSH pouze z vaší IP nebo rozsahu
sudo ufw allow from 192.168.1.0/24 to any port 2222
# Nebo pokud je potřeba globální přístup
sudo ufw allow 2222/tcp
sudo ufw enable

Pokud máte statickou IP, omezení SSH přístupu pouze na ni je neuvěřitelně efektivní. Útočníci se ani nedostanou k vašemu SSH portu.

Dvoufaktorová autentizace

Pro maximální bezpečnost kombinujte SSH klíče s TOTP (Time-based One-Time Password):

sudo apt install libpam-google-authenticator

Toto přidává druhý faktor — i kdyby někdo ukradl váš privátní klíč a passphrase, stále potřebuje kód z authenticator aplikace.

SSH Jump Hosts (Bastion)

V produkčních prostředích nikdy nevystavujte SSH kritických serverů přímo do internetu. Použijte bastion host — zpevněný minimální server, který slouží jako jediný vstupní bod do vaší sítě.

# V lokálním ~/.ssh/config
Host production-db
    HostName 10.0.1.50
    User dbadmin
    ProxyJump bastion
Host bastion
    HostName 203.0.113.10
    User jump
    IdentityFile ~/.ssh/id_bastion

Nyní ssh production-db automaticky připojuje přes bastion. SSH port databázového serveru nikdy nemusí být veřejně vystaven.

Monitoring bezpečnosti SSH

Bezpečnost není jednorázové nastavení, ale kontinuální proces. Zde je návod, jak sledovat, co se děje s SSH na vašem serveru.

Sledujte logy

Váš auth.log vypráví příběh každého pokusu o autentizaci:

# Nedávné neúspěšné pokusy
grep "Failed password" /var/log/auth.log | tail -20
# Úspěšná přihlášení
grep "Accepted" /var/log/auth.log | tail -20
# Kdo je právě přihlášen
who
w

Sledujte použití klíčů

Přidávejte komentáře k záznamům v authorized_keys pro sledování:

ssh-ed25519 AAAAC3... laptop-2026
ssh-ed25519 AAAAC3... work-desktop
ssh-ed25519 AAAAC3... emergency-backup

Pravidelně kontrolujte tento soubor. Pokud vidíte klíč, který nepoznáváte — to je problém.

Nastavte upozornění

Pro kritické servery nakonfigurujte alerty při úspěšných přihlášeních. Jednoduchý přístup pomocí PAM skriptu:

# /etc/pam.d/sshd — přidejte řádek
session optional pam_exec.so /usr/local/bin/ssh-login-alert.sh

Skript může posílat email, zprávy do Slacku nebo Telegramu při každém přihlášení. Pokud dostanete alert a nejste to vy, kdo se přihlašuje — dozvíte se to okamžitě.

Časté chyby, kterým se vyhnout

Za roky práce se servery jsme viděli stovky SSH konfigurací. Některé chyby se opakují tak často, že stojí za to je rozebrat zvlášť.

Často kladené otázky