Kompletný sprievodca zabezpečením SSH v roku 2026: Od základov po post-kvantovú kryptografiu

Úvod: Prečo by ste mali brať SSH bezpečnosť vážne (a prečo to väčšina nerobí)

SSH je niečo, čo ako Linux administrátor používate každý deň. Pripojíte sa na server, spustíte pár príkazov, odpojíte sa. Rutina. Ale ruku na srdce — kedy ste naposledy skutočne skontrolovali, ako je váš SSH nakonfigurovaný?

Čísla z roku 2025 hovoria jasnou rečou: kompromitované prihlasovacie údaje boli počiatočným vektorom útoku v 22 % všetkých narušení bezpečnosti analyzovaných v správe Verizon Data Breach Investigations Report. A veľká časť z nich začala práve cez nedostatočne zabezpečený SSH.

Úprimne, je to dosť znepokojujúce. V štvrtom štvrťroku 2025 tvorili útoky červa P2PInfect 80,4 % všetkých útokov cielených na Linuxové SSH servery. Útočníci systematicky skenujú port 22, nájdu systém so zapnutou SSH službou a spúšťajú slovníkové útoky. V roku 2025 uniklo na verejnosť približne 16 miliárd prihlasovacích údajov z rôznych platforiem — a tieto kombinácie sa okamžite stávajú palivom pre automatizované nástroje.

Tak poďme na to. V tomto sprievodcovi si prejdeme kompletný proces zabezpečenia SSH — od základov cez post-kvantovú kryptografiu, certifikátovú autentifikáciu, až po aktívnu obranu pomocou Fail2Ban a CrowdSec. Všetko s praktickými príkladmi, ktoré môžete nasadiť hneď dnes.

Východiskový stav: Najprv si zistime, na čom sme

Pred akoukoľvek zmenou musíte vedieť, kde presne stojíte. Prvým krokom je audit vášho existujúceho SSH servera.

Zistenie verzie OpenSSH

Verzia OpenSSH je kľúčová informácia, pretože určuje, aké bezpečnostné funkcie máte k dispozícii:

ssh -V
# OpenSSH_10.0p1, OpenSSL 3.2.1 30 Jan 2024

V apríli 2025 bola vydaná verzia OpenSSH 10.0 a priniesla niekoľko zásadných zmien. Kompletne odstránila podporu zastaraného DSA algoritmu, predvolene zakázala výmenu kľúčov pomocou Diffieho-Hellmana v sshd a oddelila autentifikačný kód do samostatného binárneho súboru sshd-auth. Ak ešte používate verziu staršiu ako 9.0, aktualizáciu by ste mali plánovať ako prioritu — takmer tri štvrtiny OpenSSH serverov na internete stále beží na verziách 7.0 až 8.9, čo je, povedzme si to rovno, dosť alarmujúce.

Skenovanie pomocou ssh-audit

Nástroj ssh-audit vám okamžite ukáže, aké algoritmy váš server ponúka a ktoré z nich sú slabé:

# Inštalácia ssh-audit
sudo apt install ssh-audit    # Debian/Ubuntu
sudo dnf install ssh-audit    # RHEL/Fedora

# Skenovanie lokálneho servera
ssh-audit localhost

# Skenovanie vzdialeného servera
ssh-audit vas-server.example.com

Výstup vám farebne označí bezpečné (zelené), akceptovateľné (žlté) a nebezpečné (červené) algoritmy. Cieľom je vidieť iba zelené položky. Červené? Presne tie budeme opravovať v ďalších sekciách.

Pre automatizované testovanie v CI/CD pipeline môžete použiť JSON výstup:

# JSON výstup pre automatizované spracovanie
ssh-audit --json localhost | jq '.grade'

# Kontrola konkrétnych algoritmov
ssh-audit --json localhost | jq '.kex[] | select(.warn == true)'

Kontrola aktívnych nastavení sshd

Pre overenie aktuálne aktívnych nastavení SSH démona použite:

# Zobrazenie všetkých aktívnych nastavení
sudo sshd -T

# Filtrovanie konkrétnych nastavení
sudo sshd -T | grep -i passwordauthentication
sudo sshd -T | grep -i permitrootlogin
sudo sshd -T | grep -i pubkeyauthentication

Výstup sshd -T ukazuje skutočnú konfiguráciu po spracovaní všetkých konfiguračných súborov vrátane sshd_config.d/ adresára. To je dôležité, pretože moderné distribúcie často rozdeľujú konfiguráciu do viacerých súborov — a občas vás prekvapí, čo tam nájdete.

Základné zabezpečenie: Povinné zmeny v sshd_config

Začneme zmenami, ktoré by mali byť na každom serveri bez výnimky. Toto je ten základ, bez ktorého nemá zmysel ísť ďalej.

Zakázanie prihlásenia ako root

Účet root je prvým cieľom každého útočníka — jeho meno je známe a práva neobmedzené:

# /etc/ssh/sshd_config
PermitRootLogin no

Namiesto priameho prihlásenia ako root vždy používajte bežný účet a potom sudo. Ak absolútne potrebujete vzdialený prístup root (napríklad pre automatizované zálohovanie), použite PermitRootLogin forced-commands-only s konkrétnym príkazom v authorized_keys:

# V /root/.ssh/authorized_keys na serveri
command="/usr/local/bin/backup.sh",no-port-forwarding,no-X11-forwarding,no-agent-forwarding ssh-ed25519 AAAAC3... [email protected]

Toto nastavenie umožní prihlásenie ako root výhradne s konkrétnym kľúčom a vykoná len definovaný príkaz. Bez ohľadu na to, čo sa klient pokúsi spustiť. Je to bezpečný kompromis pre automatizované úlohy.

Prechod na autentifikáciu kľúčom

Heslovú autentifikáciu je potrebné zakázať, ale — a toto je dôležité — až po tom, čo ste nastavili a overili funkčnosť kľúčovej autentifikácie:

# Najprv vygenerujte kľúčový pár (na klientskom stroji)
ssh-keygen -t ed25519 -C "[email protected]"

# Skopírujte verejný kľúč na server
ssh-copy-id -i ~/.ssh/id_ed25519.pub uzivatel@server

# Overte, že sa viete prihlásiť kľúčom
ssh -i ~/.ssh/id_ed25519 uzivatel@server

# Až potom zakážte heslovú autentifikáciu na serveri
# /etc/ssh/sshd_config
PubkeyAuthentication yes
PasswordAuthentication no
KbdInteractiveAuthentication no
AuthenticationMethods publickey

Upozornenie: Pred zakázaním hesiel sa uistite, že máte funkčný prístup cez kľúč a tiež záložný prístup k serveru (konzola poskytovateľa hostingu, IPMI/iLO). Zažil som to párkrát — kolegovia si zakázali heslá bez toho, aby si overili, že kľúč funguje. Výsledok? Cesta do datacentra v piatok večer.

Zmena portu a obmedzenie prístupu

Zmena predvoleného portu nie je bezpečnostným opatrením v pravom zmysle slova, ale výrazne znižuje šum od automatizovaných skenerov. Vaše logy budú oveľa čistejšie:

# /etc/ssh/sshd_config
Port 2222

# Obmedzenie na konkrétne sieťové rozhranie
ListenAddress 10.0.1.5

# Povolenie prístupu len konkrétnym používateľom
AllowUsers admin deploy
# alebo konkrétnym skupinám
AllowGroups ssh-users admins

Ak zmeníte port, nezabudnite upraviť pravidlá firewallu a SELinux:

# Firewall (firewalld)
sudo firewall-cmd --permanent --remove-service=ssh
sudo firewall-cmd --permanent --add-port=2222/tcp
sudo firewall-cmd --reload

# SELinux
sudo semanage port -a -t ssh_port_t -p tcp 2222

Ďalšie základné nastavenia

# /etc/ssh/sshd_config

# Maximálny počet pokusov o autentifikáciu
MaxAuthTries 3

# Časový limit na prihlásenie
LoginGraceTime 30

# Zakázanie prázdnych hesiel
PermitEmptyPasswords no

# Zakázanie X11 forwardingu (ak ho nepotrebujete)
X11Forwarding no

# Zakázanie SSH agenta forwardingu (ak ho nepotrebujete)
AllowAgentForwarding no

# Zakázanie TCP forwardingu (ak ho nepotrebujete)
AllowTcpForwarding no

# Odpájanie neaktívnych relácií po 15 minútach
ClientAliveInterval 300
ClientAliveCountMax 3

# Zobrazenie varovného banneru
Banner /etc/ssh/banner

# Zakázanie tunelového režimu
PermitTunnel no

# Zakázanie prístupu cez gateway porty
GatewayPorts no

Po každej zmene konfigurácie nezabudnite overiť syntax a reštartovať službu:

# Overenie syntaxe konfigurácie
sudo sshd -t

# Reštart služby
sudo systemctl restart sshd

# Alebo reload (bez prerušenia existujúcich spojení)
sudo systemctl reload sshd

Pokročilá kryptografia: Šifry, MAC a výmena kľúčov

Predvolená konfigurácia OpenSSH povoľuje široké spektrum kryptografických algoritmov kvôli spätnej kompatibilite. Pre bezpečné nasadenie musíme toto spektrum výrazne zúžiť. Tu to začína byť naozaj zaujímavé.

Odporúčané šifrovacie algoritmy

V roku 2026 by ste mali používať výhradne AEAD (Authenticated Encryption with Associated Data) šifry:

# /etc/ssh/sshd_config
Ciphers [email protected],[email protected],[email protected]

ChaCha20-Poly1305 je preferovaná voľba — rýchla, bezpečná a odolná voči timing attacks. Na hardvéri s podporou AES-NI (čo je dnes väčšina serverov) sú AES-GCM varianty rovnako rýchle.

Algoritmy výmeny kľúčov (Key Exchange)

A tu prichádza najzaujímavejšia zmena roku 2026 — post-kvantová kryptografia:

# /etc/ssh/sshd_config
KexAlgorithms mlkem768x25519-sha256,[email protected],curve25519-sha256,[email protected]

Algoritmus mlkem768x25519-sha256 je hybridný post-kvantový algoritmus, ktorý kombinuje ML-KEM (štandard NIST) s klasickým X25519. Od verzie OpenSSH 10.0 je predvolený. Jeho adopcia vzrástla o 554 % medzi októbrom 2024 a marcom 2025, čo je pomerne impozantné tempo.

Prečo hybridný prístup? Aj keby sa post-kvantový algoritmus ukázal ako slabší, bezpečnosť zostáva garantovaná klasickým X25519. A naopak — ak kvantový počítač prelomí X25519, post-kvantový komponent chráni komunikáciu. A výkonnostný dopad? Podľa výskumu Cisco je hybridný handshake pomalší len o približne 1 milisekundu. To si ani nevšimnete.

Autentifikačné kódy správ (MACs)

# /etc/ssh/sshd_config
MACs [email protected],[email protected]

Prípona -etm (encrypt-then-MAC) je dôležitá. Tento režim najprv šifruje a až potom počíta autentifikačný kód, čo je bezpečnejšie ako predvolený MAC-then-encrypt. Varianty bez -etm sú zraniteľné voči niektorým teoretickým útokom.

Algoritmy hostiteľských kľúčov

# /etc/ssh/sshd_config
HostKeyAlgorithms ssh-ed25519,rsa-sha2-512,rsa-sha2-256

# Vygenerujte silné hostiteľské kľúče
sudo ssh-keygen -t ed25519 -f /etc/ssh/ssh_host_ed25519_key -N ""
sudo ssh-keygen -t rsa -b 4096 -f /etc/ssh/ssh_host_rsa_key -N ""

# Odstráňte staré DSA a ECDSA kľúče (ak existujú)
sudo rm -f /etc/ssh/ssh_host_dsa_key*
sudo rm -f /etc/ssh/ssh_host_ecdsa_key*

Ed25519 je jednoznačne preferovaný algoritmus — rovnaká bezpečnosť ako RSA-3072, ale s výrazne kratšími kľúčmi (256 bitov oproti 3072) a rýchlejšími operáciami. Na overenie podpisu potrebuje približne 8-krát menej výpočtového času ako RSA-4096. Pri tisíckach autentifikácií denne je to merateľný rozdiel.

RSA kľúče by mali mať minimálne 4096 bitov. RSA-2048 sú síce stále bezpečné voči klasickým počítačom, ale s blížiacimi sa kvantovými hrozbami je lepšie zvoliť väčšiu veľkosť.

Kompletný kryptografický profil

Tu je kompletná kryptografická konfigurácia pre maximálnu bezpečnosť:

# /etc/ssh/sshd_config.d/crypto-hardening.conf

# Kryptografické algoritmy - striktná konfigurácia 2026
KexAlgorithms mlkem768x25519-sha256,[email protected],curve25519-sha256,[email protected]
Ciphers [email protected],[email protected],[email protected]
MACs [email protected],[email protected]
HostKeyAlgorithms ssh-ed25519,rsa-sha2-512,rsa-sha2-256
PubkeyAcceptedAlgorithms ssh-ed25519,rsa-sha2-512,rsa-sha2-256

Dôležité: Táto konfigurácia vyžaduje OpenSSH 9.0+ na serveri aj na všetkých klientoch. Ak spravujete heterogénne prostredie so staršími klientmi, možno budete musieť pridať niektoré staršie algoritmy. Vždy testujte na neprodukčnom prostredí — nechcete sa dozvedieť, že niečo nefunguje, keď je celý tím odpojený.

Certifikátová autentifikácia SSH: Koniec éry authorized_keys

Tradičná autentifikácia pomocou verejných kľúčov má zásadný problém so škálovateľnosťou. Pri desiatich serveroch a piatich administrátoroch to je 50 záznamov v súboroch authorized_keys. Pri stovkách serverov? Nočná mora. SSH certifikáty tento problém elegantne riešia.

Ako SSH certifikáty fungujú

Princíp je podobný TLS certifikátom: existuje certifikačná autorita (CA), ktorá podpisuje kľúče používateľov a hostiteľov. Server dôveruje CA a akceptuje každý kľúč, ktorý CA podpísala — žiadne manuálne distribuovanie verejných kľúčov.

Vytvorenie certifikačnej autority

Osvedčeným postupom je vytvoriť dve oddelené CA — jednu pre hostiteľské certifikáty a druhú pre používateľské:

# CA pre hostiteľov
ssh-keygen -t ed25519 -f /etc/ssh/ca/host_ca -C "Host CA"

# CA pre používateľov
ssh-keygen -t ed25519 -f /etc/ssh/ca/user_ca -C "User CA"

# Zabezpečenie súkromných kľúčov CA
chmod 600 /etc/ssh/ca/host_ca /etc/ssh/ca/user_ca
chmod 644 /etc/ssh/ca/host_ca.pub /etc/ssh/ca/user_ca.pub

Prečo dve oddelené CA? Ak by bol odcudzený súkromný kľúč hostiteľskej CA, útočník by mohol vytvárať falošné servery, ale nemohol by vytvárať používateľské certifikáty. A naopak. Jednoduchá, ale účinná izolácia.

Podpisovanie hostiteľských certifikátov

# Na každom serveri podpíšte jeho hostiteľský kľúč
ssh-keygen -s /etc/ssh/ca/host_ca \
    -I "webserver01.firma.sk" \
    -h \
    -n "webserver01.firma.sk,webserver01,10.0.1.10" \
    -V +52w \
    /etc/ssh/ssh_host_ed25519_key.pub

# Konfigurácia sshd na používanie certifikátu
# /etc/ssh/sshd_config
HostCertificate /etc/ssh/ssh_host_ed25519_key-cert.pub

Parameter -n definuje hostiteľské mená, pre ktoré je certifikát platný, a -V +52w nastavuje platnosť na 52 týždňov (1 rok).

Podpisovanie používateľských certifikátov

# Podpísanie verejného kľúča používateľa
ssh-keygen -s /etc/ssh/ca/user_ca \
    -I "[email protected]" \
    -n "admin,deploy" \
    -V +8h \
    /home/jan/.ssh/id_ed25519.pub

# Na serveri povolte CA pre overovanie používateľov
# /etc/ssh/sshd_config
TrustedUserCAKeys /etc/ssh/ca/user_ca.pub

Všimnite si -V +8h — certifikát platí len 8 hodín. Krátkodobé certifikáty sú osvedčeným postupom, pretože aj v prípade kompromitácie rýchlo expirujú. Osobne odporúčam práve túto dobu — pokryje pracovný deň a večer automaticky vyprší.

Konfigurácia klienta na dôveru hostiteľskej CA

Na klientskej strane pridajte dôveru voči hostiteľskej CA, čím sa zbavíte otravného „Are you sure you want to continue connecting?" a modelu TOFU (Trust On First Use):

# ~/.ssh/known_hosts alebo /etc/ssh/ssh_known_hosts
@cert-authority *.firma.sk ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAA... Host CA

Odteraz bude každý server s certifikátom podpísaným vašou hostiteľskou CA automaticky dôveryhodný. Žiadne manuálne potvrdzovanie odtlačkov.

Automatizácia certifikátov cez HashiCorp Vault

Pre väčšie organizácie je manuálne podpisovanie nepraktické. HashiCorp Vault poskytuje plne automatizovanú SSH CA infraštruktúru:

# Povolenie SSH secrets engine vo Vault
vault secrets enable -path=ssh-client-signer ssh

# Konfigurácia CA
vault write ssh-client-signer/config/ca generate_signing_key=true

# Vytvorenie role pre administrátorov
vault write ssh-client-signer/roles/admin -<<"EOH"
{
  "algorithm_signer": "rsa-sha2-256",
  "allow_user_certificates": true,
  "allowed_users": "admin,deploy",
  "allowed_extensions": "permit-pty",
  "default_extensions": {"permit-pty": ""},
  "key_type": "ca",
  "default_user": "admin",
  "ttl": "8h",
  "max_ttl": "24h"
}
EOH

# Podpísanie verejného kľúča používateľa
vault write ssh-client-signer/sign/admin \
    public_key=@/home/admin/.ssh/id_ed25519.pub

Vault automaticky generuje krátkodobé certifikáty, čím eliminuje problém dlhodobých prístupových kľúčov. Administrátor si pred každou reláciou vyžiada nový certifikát — proces trvá milisekundy a certifikát automaticky expiruje po 8 hodinách. Jednoducho elegantné riešenie.

Aktívna obrana: Fail2Ban a CrowdSec

Aj pri najlepšej konfigurácii SSH budete čeliť automatizovaným útokom. To je realita. Aktívna obrana automaticky blokuje útočníkov ešte počas ich pokusu.

Fail2Ban: Osvedčená klasika

Fail2Ban monitoruje logy a automaticky blokuje IP adresy s neúspešnými pokusmi o prihlásenie:

# Inštalácia
sudo apt install fail2ban    # Debian/Ubuntu
sudo dnf install fail2ban    # RHEL/Fedora

# Vytvorenie lokálnej konfigurácie
sudo cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local

Nikdy neupravujte súbor jail.conf priamo — aktualizácie ho prepíšu. Vždy pracujte s jail.local alebo vytvorte súbor v jail.d/:

# /etc/fail2ban/jail.d/ssh-hardened.conf
[sshd]
enabled = true
mode = aggressive
port = 2222
logpath = %(sshd_log)s
backend = systemd

# Po 3 neúspešných pokusoch zakázať na 1 hodinu
maxretry = 3
findtime = 600
bantime = 3600

# Progresívne zvyšovanie doby zákazu
bantime.increment = true
bantime.factor = 2
bantime.maxtime = 604800

# Whitelist dôveryhodných IP adries
ignoreip = 127.0.0.1/8 ::1 10.0.0.0/8

Kľúčovou funkciou je bantime.increment. Pri opakovaných útokoch sa doba blokácie exponenciálne zvyšuje — prvý zákaz hodinu, druhý dve, tretí štyri, až do maxima jedného týždňa. Dosť efektívne odradí aj tých najtvrdohlavejších botov.

Monitorovanie Fail2Ban

# Stav všetkých jailov
sudo fail2ban-client status

# Detail SSH jailu
sudo fail2ban-client status sshd

# Manuálne odblokovanie IP
sudo fail2ban-client set sshd unbanip 192.168.1.100

# Sledovanie logov v reálnom čase
sudo tail -f /var/log/fail2ban.log

CrowdSec: Moderná alternatíva s komunitnou inteligenciou

CrowdSec je modernejšia alternatíva k Fail2Ban, navrhnutá pre distribuovanú realitu. Kým Fail2Ban je reaktívny (reaguje až po útoku), CrowdSec využíva kolektívnu inteligenciu komunity. Ak útočník zaútočí na jeden server chránený CrowdSec, jeho IP adresa sa pridá do komunitnej databázy a ostatné servery ho zablokujú preventívne. Je to v podstate crowdsourcovaná obrana.

# Inštalácia CrowdSec (Debian/Ubuntu)
curl -s https://install.crowdsec.net | sudo bash
sudo apt install crowdsec
sudo apt install crowdsec-firewall-bouncer-iptables

# Inštalácia na RHEL/Fedora
curl -s https://install.crowdsec.net | sudo bash
sudo dnf install crowdsec
sudo dnf install crowdsec-firewall-bouncer-iptables

Konfigurácia CrowdSec pre SSH:

# Overenie, že SSH kolekcia je nainštalovaná
sudo cscli collections list | grep ssh

# Ak nie, nainštalujte ju
sudo cscli collections install crowdsecurity/sshd

# Kontrola aktuálnych rozhodnutí (blokovaných IP)
sudo cscli decisions list

# Zobrazenie metrík
sudo cscli metrics

# Registrácia do komunitnej konzoly (voliteľné, ale odporúčané)
sudo cscli console enroll VÁŠE_TOKEN

Kedy Fail2Ban a kedy CrowdSec?

Pre jednoduchšie nasadenia (jeden server, jasné pravidlá) je Fail2Ban spoľahlivá voľba s minimálnymi nárokmi. CrowdSec vyniká v prostrediach s viacerými servermi, kde oceníte komunitnú inteligenciu. Pre typické produkčné nasadenie v roku 2026 je ideálne kombinovať oboje — CrowdSec pre globálnu reputáciu IP adries a Fail2Ban pre rýchle lokálne blokácie.

Ďalšou alternatívou je SSHGuard, špeciálne navrhnutý pre ochranu SSH. Je ľahší ako Fail2Ban a vhodný pre servery s obmedzenými zdrojmi. Pre Debian/Ubuntu je k dispozícii ako balík sshguard.

Dvojfaktorová autentifikácia (2FA) pre SSH

Pre dodatočnú vrstvu ochrany môžete k autentifikácii kľúčom pridať druhý faktor — časovo založené jednorazové heslo (TOTP):

# Inštalácia PAM modulu pre Google Authenticator
sudo apt install libpam-google-authenticator    # Debian/Ubuntu
sudo dnf install google-authenticator           # RHEL/Fedora

# Konfigurácia pre používateľa
google-authenticator -t -d -f -r 3 -R 30 -w 3

Parametre príkazu:

• -t — časovo založené tokeny (TOTP)
• -d — zakázanie opakovaného použitia tokenu
• -f — vynútenie prepísania existujúcej konfigurácie
• -r 3 -R 30 — maximálne 3 pokusy za 30 sekúnd
• -w 3 — okno 3 tokenov (kompenzácia časového posunu)

Konfigurácia PAM a sshd pre 2FA s kľúčom:

# /etc/pam.d/sshd — pridajte na koniec
auth required pam_google_authenticator.so nullok

# /etc/ssh/sshd_config
ChallengeResponseAuthentication yes
AuthenticationMethods publickey,keyboard-interactive
# To znamená: najprv kľúč, potom TOTP kód

Voľba nullok v PAM konfigurácii umožňuje prihlásenie používateľom, ktorí ešte nemajú nakonfigurovaný 2FA. Keď si ho nastavia všetci, nullok odstráňte.

Sieťová izolácia: SSH Jump Hosty a bastiónové servery

V produkčnom prostredí by SSH port nemal byť priamo prístupný z internetu na žiadnom aplikačnom serveri. Namiesto toho použite bastiónový (jump) server ako jediný vstupný bod:

# Architektúra:
# Internet → [Firewall] → [Bastión] → [Interné servery]
#
# Len bastión má otvorený SSH port z internetu
# Interné servery akceptujú SSH len z bastiónového servera

Konfigurácia klienta pre jump host

# ~/.ssh/config

# Bastiónový server
Host bastion
    HostName bastion.firma.sk
    Port 2222
    User admin
    IdentityFile ~/.ssh/id_ed25519

# Interné servery cez bastión
Host web-*.internal
    ProxyJump bastion
    User deploy
    IdentityFile ~/.ssh/id_ed25519_deploy

Host db-*.internal
    ProxyJump bastion
    User dbadmin
    IdentityFile ~/.ssh/id_ed25519_db

S touto konfiguráciou stačí napísať ssh web-01.internal a SSH automaticky vytvorí tunel cez bastión. Na bastiónových serveroch je vhodné zakázať všetky forwardingové funkcie a alokovanie PTY:

# /etc/ssh/sshd_config na bastiónových serveroch
AllowTcpForwarding yes    # Potrebné pre ProxyJump
AllowAgentForwarding no
X11Forwarding no
PermitTTY no              # Žiadny shell na bastiónovi (len presmerovanie)
ForceCommand /usr/sbin/nologin

Firewall pravidlá pre bastiónový server

Na bastióne nastavte prísne pravidlá firewallu — prichádzajúce spojenia len na SSH, odchádzajúce len na interné servery:

# nftables konfigurácia pre bastión
#!/usr/sbin/nft -f
flush ruleset

table inet filter {
    chain input {
        type filter hook input priority 0; policy drop;

        # Povolenie loopback
        iif "lo" accept

        # Povolenie existujúcich spojení
        ct state established,related accept

        # SSH z internetu (len na port 2222)
        tcp dport 2222 accept

        # Odmietnutie všetkého ostatného s ICMP správou
        reject with icmpx type admin-prohibited
    }

    chain output {
        type filter hook output priority 0; policy drop;

        # Povolenie loopback a existujúcich spojení
        oif "lo" accept
        ct state established,related accept

        # SSH na interné servery
        ip daddr 10.0.0.0/8 tcp dport 22 accept

        # DNS a NTP
        tcp dport { 53, 123 } accept
        udp dport { 53, 123 } accept
    }
}

Táto konfigurácia zabezpečuje, že bastión slúži výhradne ako presmerovací bod. Žiadny útočník, ktorý by sa naň dostal, nemôže komunikovať s externým svetom na výstupe, čo výrazne obmedzuje možnosť exfiltrácie dát.

Monitorovanie a auditovanie SSH prístupov

Zabezpečenie bez monitorovania je ako zámok bez kamery. Viete, že dvere sú zamknuté, ale neviete, kto sa pokúšal vojsť.

Konfigurácia logovania SSH

# /etc/ssh/sshd_config
LogLevel VERBOSE

# Pre ešte detailnejšie logy (debugging)
# LogLevel DEBUG3

VERBOSE úroveň loguje kľúčovú identifikáciu (fingerprint) použitú pri prihlásení. Pri forenznom vyšetrovaní je to neoceniteľné — presne viete, ktorý kľúč bol použitý a kedy.

Auditovanie pomocou auditd

# /etc/audit/rules.d/ssh.rules

# Monitorovanie zmien konfigurácie SSH
-w /etc/ssh/sshd_config -p wa -k sshd_config
-w /etc/ssh/sshd_config.d/ -p wa -k sshd_config

# Monitorovanie prístupu k súkromným kľúčom
-w /etc/ssh/ssh_host_ed25519_key -p r -k ssh_host_key
-w /etc/ssh/ssh_host_rsa_key -p r -k ssh_host_key

# Monitorovanie authorized_keys
-w /home/ -p wa -k authorized_keys -F path=*/.ssh/authorized_keys

# Načítanie pravidiel
sudo augenrules --load

Centralizácia logov

Pre prostredie s viacerými servermi centralizujte SSH logy do SIEM systému. Minimálne nastavte rsyslog na presmerovanie:

# /etc/rsyslog.d/ssh-forward.conf
if $programname == 'sshd' then {
    action(type="omfwd"
           target="siem.firma.sk"
           port="514"
           protocol="tcp"
           action.resumeRetryCount="-1"
           queue.type="LinkedList"
           queue.fileName="ssh_forward"
           queue.maxDiskSpace="1g"
           queue.saveOnShutdown="on")
}

Automatické upozornenia na prihlásenia

Pre kritické servery je vhodné nastaviť okamžité upozornenia na úspešné prihlásenia:

# /etc/ssh/sshrc — spúšťa sa po každom úspešnom prihlásení
#!/bin/bash
TIMESTAMP=$(date '+%Y-%m-%d %H:%M:%S')
IP=$(echo $SSH_CONNECTION | awk '{print $1}')
HOSTNAME=$(hostname)
USER=$(whoami)

logger -p auth.info "SSH prihlásenie: $USER z $IP na $HOSTNAME v $TIMESTAMP"

# Voliteľné: odoslanie notifikácie (napríklad cez webhook)
# curl -s -X POST "https://hooks.firma.sk/ssh" \
#     -H "Content-Type: application/json" \
#     -d "{\"user\":\"$USER\",\"ip\":\"$IP\",\"host\":\"$HOSTNAME\",\"time\":\"$TIMESTAMP\"}"

Pre produkčné prostredia odporúčam namiesto vlastných skriptov integráciu s existujúcim SIEM systémom. Nástroje ako Wazuh, OSSEC alebo Elastic Security dokážu SSH logy spracovať v reálnom čase a generovať sofistikované upozornenia — napríklad prihlásenie z nezvyčajnej lokality alebo v neobvyklom čase.

Kompletný konfiguračný súbor: Všetko na jednom mieste

Tu je kompletná konfigurácia sshd_config, ktorá kombinuje všetky vyššie uvedené odporúčania. Uložte ju ako /etc/ssh/sshd_config.d/hardening.conf:

# =============================================================
# SSH Hardening Configuration 2026
# Súbor: /etc/ssh/sshd_config.d/hardening.conf
# =============================================================

# --- Sieťové nastavenia ---
Port 2222
AddressFamily inet
ListenAddress 0.0.0.0

# --- Autentifikácia ---
PermitRootLogin no
PubkeyAuthentication yes
PasswordAuthentication no
KbdInteractiveAuthentication no
PermitEmptyPasswords no
AuthenticationMethods publickey
MaxAuthTries 3
LoginGraceTime 30

# --- Kryptografia ---
KexAlgorithms mlkem768x25519-sha256,[email protected],curve25519-sha256,[email protected]
Ciphers [email protected],[email protected],[email protected]
MACs [email protected],[email protected]
HostKeyAlgorithms ssh-ed25519,rsa-sha2-512,rsa-sha2-256

# --- Relácie ---
ClientAliveInterval 300
ClientAliveCountMax 3
MaxSessions 3
MaxStartups 10:30:60

# --- Funkcie ---
X11Forwarding no
AllowAgentForwarding no
AllowTcpForwarding no
PermitTunnel no
GatewayPorts no
DisableForwarding yes

# --- Logovanie ---
LogLevel VERBOSE
SyslogFacility AUTH

# --- Rôzne ---
PermitUserEnvironment no
StrictModes yes
Banner /etc/ssh/banner
VersionAddendum none

# --- Prístupové kontroly ---
# Odkomentujte a prispôsobte:
# AllowUsers admin deploy
# AllowGroups ssh-users

Automatizácia nasadzovania: Ansible playbook

Pre konzistentné nasadzovanie SSH konfigurácie naprieč celou infraštruktúrou využite Ansible. Tu je hotový playbook, ktorý môžete prispôsobiť:

# ssh-hardening.yml
---
- name: SSH Hardening
  hosts: all
  become: true
  tasks:
    - name: Nasadenie hardened SSH konfigurácie
      ansible.builtin.template:
        src: templates/sshd_hardening.conf.j2
        dest: /etc/ssh/sshd_config.d/hardening.conf
        owner: root
        group: root
        mode: '0600'
        validate: '/usr/sbin/sshd -t -f %s'
      notify: Restart sshd

    - name: Odstránenie slabých hostiteľských kľúčov
      ansible.builtin.file:
        path: "{{ item }}"
        state: absent
      loop:
        - /etc/ssh/ssh_host_dsa_key
        - /etc/ssh/ssh_host_dsa_key.pub
        - /etc/ssh/ssh_host_ecdsa_key
        - /etc/ssh/ssh_host_ecdsa_key.pub
      notify: Restart sshd

    - name: Vygenerovanie Ed25519 hostiteľského kľúča
      ansible.builtin.command:
        cmd: ssh-keygen -t ed25519 -f /etc/ssh/ssh_host_ed25519_key -N ""
        creates: /etc/ssh/ssh_host_ed25519_key

    - name: Inštalácia a konfigurácia Fail2Ban
      ansible.builtin.package:
        name: fail2ban
        state: present

    - name: Nasadenie Fail2Ban SSH konfigurácie
      ansible.builtin.template:
        src: templates/fail2ban-ssh.conf.j2
        dest: /etc/fail2ban/jail.d/ssh-hardened.conf
      notify: Restart fail2ban

  handlers:
    - name: Restart sshd
      ansible.builtin.service:
        name: sshd
        state: restarted

    - name: Restart fail2ban
      ansible.builtin.service:
        name: fail2ban
        state: restarted

Po nasadení konfigurácie spustite automatizovaný test:

# Testovací skript pre CI/CD pipeline
#!/bin/bash
set -euo pipefail

SERVER=$1
EXPECTED_GRADE="A+"

RESULT=$(ssh-audit --json "$SERVER" 2>/dev/null)
GRADE=$(echo "$RESULT" | jq -r '.grade // "FAIL"')

if [ "$GRADE" != "$EXPECTED_GRADE" ]; then
    echo "ZLYHANIE: Server $SERVER dostal hodnotenie $GRADE (očakávané $EXPECTED_GRADE)"
    echo "$RESULT" | jq '.recommendations[]'
    exit 1
fi

echo "ÚSPECH: Server $SERVER dostal hodnotenie $GRADE"

Aktuálne zraniteľnosti OpenSSH, na ktoré si dať pozor

Pravidelná aktualizácia OpenSSH je jedným z najdôležitejších opatrení. V roku 2025 boli objavené dve významné zraniteľnosti, ktoré vyžadujú okamžitú pozornosť:

CVE-2025-26465 — Podvrhnutie identity servera

Postihuje OpenSSH verzie 6.8p1 až 9.9p1. Logická chyba v SSH klientovi umožňovala útočníkovi (man-in-the-middle) vydávať sa za akýkoľvek server, keď bola povolená voľba VerifyHostKeyDNS. Riešenie: aktualizujte na OpenSSH 9.9p2+ a skontrolujte, či máte VerifyHostKeyDNS nastavenú na no.

CVE-2025-26466 — Denial of Service

Zraniteľnosť v sshd verziách 9.5p1 až 9.9p1 umožňovala útočníkovi vyvolať nadmernú spotrebu pamäte a CPU cez manipuláciu s SSH2_MSG_PING paketmi. Riešenie: aktualizácia na 9.9p2+ a nastavenie reštrikcií:

# /etc/ssh/sshd_config
# Formát: start:rate:full
# Pri 10 neautentifikovaných spojeniach začni odmietať 30% nových
# Pri 60 neautentifikovaných spojeniach odmietaj všetky
MaxStartups 10:30:60

# Nastavenie per-source rate limitu
PerSourceMaxStartups 2
PerSourceNetBlockSize 32:128

Nastavenie PerSourceMaxStartups obmedzuje počet súbežných neautentifikovaných spojení z jednej zdrojovej siete. Táto funkcia bola pridaná v OpenSSH 8.5 ako odpoveď na narastajúce DDoS útoky na SSH službu.

Pre systematické sledovanie zraniteľností odporúčam predplatiť bezpečnostný mailing list OpenSSH a nastaviť automatické upozornenia cez vuls alebo trivy.

Kontrolný zoznam: Zabezpečenie SSH v 15 krokoch

Na záver — kompletný kontrolný zoznam, ktorý si môžete vytlačiť a použiť pri zabezpečovaní každého nového servera:

1. Aktualizujte OpenSSH na najnovšiu verziu (ideálne 10.0+)
2. Vygenerujte Ed25519 kľúče pre používateľov aj hostiteľov
3. Zakážte prihlásenie ako root (PermitRootLogin no)
4. Zakážte heslovú autentifikáciu (PasswordAuthentication no)
5. Nakonfigurujte silné kryptografické algoritmy (šifry, MAC, KEX)
6. Zapnite post-kvantovú výmenu kľúčov (mlkem768x25519-sha256)
7. Odstráňte staré DSA a ECDSA hostiteľské kľúče
8. Nastavte MaxAuthTries 3 a LoginGraceTime 30
9. Zakážte nepotrebné funkcie (X11, agent forwarding, tunneling)
10. Nainštalujte a nakonfigurujte Fail2Ban alebo CrowdSec
11. Zvážte implementáciu SSH certifikátovej autentifikácie
12. Zvážte pridanie 2FA (Google Authenticator / TOTP)
13. Nastavte SSH logovacie úrovne na VERBOSE
14. Nakonfigurujte auditd pravidlá pre SSH
15. Spustite ssh-audit a overte hodnotenie A+

Záver: Bezpečnosť SSH nie je jednorazová záležitosť

Zabezpečenie SSH nie je niečo, čo urobíte raz a zabudnete. Kryptografické štandardy sa vyvíjajú, objavujú sa nové zraniteľnosti a útočníci neustále zdokonaľujú svoje metódy. Pravidelne kontrolujte aktualizácie OpenSSH, sledujte bezpečnostné upozornenia a periodicky opakujte audit.

Najdôležitejšie je začať. Aj implementácia len základných odporúčaní z tohto sprievodcu — zakázanie hesiel, zakázanie root prihlásenia, silné kryptografické algoritmy — dramaticky zníži váš útočný povrch. Post-kvantová kryptografia, certifikátová autentifikácia a CrowdSec sú potom ďalšie kroky, ktoré vašu bezpečnostnú pozíciu posunú na úplne inú úroveň.

Celá implementácia vám nezaberie viac ako jedno popoludnie, no výrazne zvýši odolnosť vašej infraštruktúry. A pamätajte — najlepší čas na zabezpečenie SSH bol včera. Druhý najlepší čas je teraz.