Zabezpečení OpenSSH 10.x: Post-kvantová kryptografie, FIDO2 a SSH CA — kompletní průvodce

Úvod: SSH v éře kvantových počítačů

Secure Shell (SSH) je páteří správy prakticky každého linuxového serveru na světě. Denně se přes SSH přihlásí miliony administrátorů, DevOps inženýrů a vývojářů ke svým serverům — nasazují kód, spravují infrastrukturu, přenášejí citlivá data. Jenže bezpečnostní prostředí kolem SSH se dramaticky mění. A rok 2025? Ten přinesl opravdu zásadní zlom.

Vydání OpenSSH 10.0 v dubnu 2025 a následně OpenSSH 10.1 v říjnu 2025 představuje bezprecedentní posun v kryptografické architektuře SSH. Poprvé v historii se post-kvantový algoritmus pro výměnu klíčů stal výchozím nastavením, podpora zastaralého DSA byla kompletně odstraněna a nový binární soubor sshd-auth odděluje autentizační kód od zbytku démona. Přidejte k tomu hardwarové bezpečnostní klíče FIDO2 a certifikátovou autentizaci přes SSH CA — moderní SSH je prostě komplexní bezpečnostní ekosystém.

V tomto článku vás provedu kompletním zabezpečením SSH od základů až po pokročilé techniky. Zaměříme se na konfiguraci post-kvantové kryptografie, hardwarovou autentizaci pomocí FIDO2, nasazení SSH certifikátové autority a celkový hardening serveru i klienta. Všechno s praktickými příklady, které můžete rovnou nasadit.

OpenSSH 10.0: Architektonický a kryptografický milník

OpenSSH 10.0, vydaný 9. dubna 2025, rozhodně není pouhá rutinní aktualizace. Je to zásadní architektonický a kryptografický přelom, který mění způsob, jakým SSH chrání komunikaci mezi klientem a serverem.

Post-kvantová výměna klíčů jako výchozí nastavení

Nejvýznamnější změnou je zavedení hybridního algoritmu mlkem768x25519-sha256 jako výchozího algoritmu pro výměnu klíčů. Tento algoritmus kombinuje dva přístupy:

• ML-KEM (mlkem768) — standardizovaný post-kvantový mechanismus zapouzdření klíčů podle NIST FIPS 203, navržený tak, aby odolal útokům kvantových počítačů
• X25519 — osvědčený algoritmus eliptických křivek, který zajišťuje kompatibilitu a vysoký výkon na současných klasických systémech

Hybridní přístup je tady naprosto klíčový. I kdyby se v budoucnu ukázalo, že post-kvantová složka má slabinu, spojení zůstane minimálně stejně bezpečné jako při použití samotného X25519. A naopak — pokud klasická kryptografie padne pod tlakem kvantových počítačů, ML-KEM poskytne ochranu. Prostě strategie „nejlepší z obou světů".

Proč je to důležité právě teď?

Koncept „store now, decrypt later" (ulož nyní, dešifruj později) není žádná teorie z učebnic — je to reálná hrozba. Zpravodajské služby a pokročilí útočníci mohou zachytávat šifrovanou SSH komunikaci už dnes s tím, že ji dešifrují, až budou mít k dispozici dostatečně výkonný kvantový počítač.

Podle odhadů bezpečnostní komunity by se funkční kryptograficky relevantní kvantové počítače mohly objevit kolem roku 2030–2035. Data přenášená dnes tedy mohou být zranitelná za pouhých 5–10 let. To není zrovna uklidňující vyhlídka.

Kompletní odstranění DSA

OpenSSH 10.0 dokončuje dlouhodobý proces vyřazení algoritmu DSA. Ten byl ve výchozím nastavení zakázán už v roce 2015, v OpenSSH 9.9 zakázán při kompilaci a v 10.0 odstraněn zcela. Důvody? DSA je omezen na 1024bitové klíče a využívá hash SHA-1, což poskytuje bezpečnostní úroveň ekvivalentní pouhým 80 bitům symetrické kryptografie. Pro moderní hrozby naprosto nedostatečné.

Nový binární soubor sshd-auth

OpenSSH 10.0 zavádí modulární přístup oddělením fáze autentizace do nového binárního souboru sshd-auth. Kritický pre-autentizační kód tak běží v zcela odděleném adresním prostoru od kódu používaného pro zbytek připojení. Po úspěšné autentizaci se autentizační kód uvolní z paměti — útočná plocha se výrazně zmenší.

Tohle je přesně ten typ architektonického rozhodnutí, které na první pohled nevypadá dramaticky, ale v praxi může zabránit celé kategorii útoků.

Další významné změny

• Finite-field Diffie-Hellman zakázán — tradiční metody výměny klíčů modp jsou na serveru ve výchozím nastavení zakázány, nahrazeny eliptickými křivkami (ECDH)
• Preference šifer — OpenSSH nyní upřednostňuje AES-GCM před AES-CTR, přičemž ChaCha20/Poly1305 zůstává šifrou s nejvyšší prioritou
• Vylepšená kompatibilita s FIDO2 — lepší podpora novějších tokenů FIDO, včetně těch, které nevracejí atestační data
• Integrace s systemd — ssh-agent nyní podporuje aktivaci socketů ve stylu systemd

OpenSSH 10.1: Varování a budoucí směr

OpenSSH 10.1, vydaný 6. října 2025, jde ještě dál — zavádí varování při použití ne-post-kvantové výměny klíčů. Pokud se klient připojí k serveru, který nenabízí algoritmus mlkem768x25519-sha256 nebo sntrup761x25519-sha512, zobrazí se varování o potenciálním riziku.

Toto varování řídí nová volba WarnWeakCrypto v konfiguraci klienta ssh_config, která je ve výchozím stavu zapnuta. Pokud server nelze aktualizovat (a věřte mi, takové servery v každé infrastruktuře jsou), varování lze potlačit:

# ~/.ssh/config
Host legacy-server.example.com
    WarnWeakCrypto no

Mezi další novinky verze 10.1 patří:

• Podpora Ed25519 klíčů v PKCS#11 tokenech — rozšíření kompatibility s hardwarovými bezpečnostními moduly
• Automatická expirace certifikátů v ssh-agent — agent automaticky odstraňuje certifikáty po jejich vypršení (plus 5minutová ochranná lhůta)
• Přesun socketů agenta — z /tmp do ~/.ssh/agent pro lepší bezpečnost
• Varování před budoucím vyřazením SHA-1 SSHFP — DNS záznamy SSHFP používající SHA-1 budou v příštích verzích ignorovány
• Odstranění experimentální podpory XMSS klíčů — s výhledem na implementaci nového post-kvantového podpisového schématu

Praktická konfigurace: Post-kvantový sshd_config

Tak, dost teorie. Pojďme se podívat na to, co nás živí — praktickou konfiguraci. Následující nastavení serveru představuje doporučenou konfiguraci pro rok 2026, která zahrnuje post-kvantovou kryptografii, silné šifry a moderní autentizační metody.

Kompletní hardening sshd_config

# /etc/ssh/sshd_config — Hardened konfigurace pro OpenSSH 10.x
# Aktualizováno: 2026

# === Síťové nastavení ===
Port 22
AddressFamily inet
ListenAddress 0.0.0.0

# === Post-kvantová výměna klíčů ===
# ML-KEM hybrid na prvním místě, SNTRUP jako záloha, klasický curve25519 jako fallback
KexAlgorithms mlkem768x25519-sha256,sntrup761x25519-sha512,curve25519-sha256

# === Šifry ===
# ChaCha20 pro výkon, AES-GCM pro kompatibilitu
Ciphers [email protected],[email protected],[email protected]

# === MAC (Message Authentication Codes) ===
MACs [email protected],[email protected]

# === Klíče hostitele ===
HostKey /etc/ssh/ssh_host_ed25519_key
HostKeyAlgorithms ssh-ed25519,rsa-sha2-512,rsa-sha2-256

# === Autentizace ===
PubkeyAuthentication yes
PasswordAuthentication no
KbdInteractiveAuthentication no
ChallengeResponseAuthentication no
UsePAM yes

# Povolené typy klíčů (včetně FIDO2)
PubkeyAcceptedAlgorithms ssh-ed25519,[email protected],rsa-sha2-512,rsa-sha2-256

# === Omezení přístupu ===
PermitRootLogin prohibit-password
MaxAuthTries 3
LoginGraceTime 30
MaxSessions 5
MaxStartups 10:30:60

# === Ochrana proti brute-force ===
PerSourcePenalties crash:90s,authfail:5s,noauth:2s,grace-exceeded:20s

# === Zabezpečení relace ===
ClientAliveInterval 300
ClientAliveCountMax 2
X11Forwarding no
AllowTcpForwarding no
AllowAgentForwarding no
PermitTunnel no

# === Logování ===
LogLevel VERBOSE
SyslogFacility AUTH

# === Certifikátová autentizace (volitelně) ===
# TrustedUserCAKeys /etc/ssh/ca_user_key.pub
# AuthorizedPrincipalsFile /etc/ssh/auth_principals/%u

Konfigurace klienta ssh_config

Na straně klienta je stejně důležité nakonfigurovat silné výchozí hodnoty. Často se na to zapomíná, ale bezpečnost SSH je vždycky o obou stranách spojení:

# ~/.ssh/config — Hardened konfigurace klienta

Host *
    # Post-kvantová výměna klíčů
    KexAlgorithms mlkem768x25519-sha256,sntrup761x25519-sha512,curve25519-sha256

    # Silné šifry
    Ciphers [email protected],[email protected],[email protected]

    # Silné MAC
    MACs [email protected],[email protected]

    # Preferované typy klíčů
    HostKeyAlgorithms ssh-ed25519,rsa-sha2-512,rsa-sha2-256

    # Preference identity klíčů
    IdentityFile ~/.ssh/id_ed25519_sk
    IdentityFile ~/.ssh/id_ed25519

    # Bezpečnostní nastavení
    HashKnownHosts yes
    VisualHostKey yes
    StrictHostKeyChecking ask
    UpdateHostKeys ask
    VerifyHostKeyDNS yes

    # Varování o slabé kryptografii (výchozí v 10.1+)
    WarnWeakCrypto yes

Ověření konfigurace

Po úpravě konfigurace si ji nezapomeňte ověřit. Jednou jsem přepsal sshd_config na produkčním serveru, restartoval sshd a... zamknul se. Od té doby vždy nejdřív validuji syntaxi:

# Kontrola syntaxe konfigurace
sudo sshd -t

# Zobrazení podporovaných algoritmů
ssh -Q kex        # Výměna klíčů
ssh -Q cipher     # Šifry
ssh -Q mac        # MAC algoritmy
ssh -Q key        # Typy klíčů

# Restart služby
sudo systemctl restart sshd

# Ověření aktivního připojení
ssh -vvv user@server 2>&1 | grep "kex:"

Hardwarová autentizace s FIDO2

Hesla jsou mrtvá — alespoň pro SSH by měla být. Hardwarové bezpečnostní klíče FIDO2 (YubiKey, Nitrokey, SoloKeys a další) představují nejsilnější formu autentizace dostupnou pro SSH. Soukromý klíč nikdy neopouští hardware, pro každou autentizaci je vyžadován fyzický dotyk a volitelně PIN jako druhý faktor.

Upřímně, jakmile si zvyknete na FIDO2 klíč, cesta zpět k softwarovým klíčům vás ani nenapadne.

Generování klíče ed25519-sk

Typ klíče ed25519-sk (kde -sk znamená „security key") kombinuje moderní kryptografii Ed25519 s hardwarovou ochranou FIDO2:

# Generování rezidentního FIDO2 klíče
# -O resident: klíč je uložen přímo v hardwarovém tokenu
# -O verify-required: vyžaduje PIN při každém použití
ssh-keygen -t ed25519-sk -O resident -O verify-required -C "admin@server-2026"

# Budete vyzváni k:
# 1. Zadání FIDO2 PIN
# 2. Fyzickému dotyku bezpečnostního klíče
# 3. Volbě umístění pro soubor handle klíče

Důležitý detail: soubor id_ed25519_sk na disku neobsahuje soukromý klíč — obsahuje pouze referenční handle. Skutečný soukromý klíč existuje výhradně uvnitř hardwarového tokenu a nelze jej exportovat. To je ta krása celého konceptu.

Rezidentní vs. nerezidentní klíče

Rezidentní klíče (discoverable credentials) jsou uloženy přímo v paměti bezpečnostního klíče. Můžete je obnovit na jakémkoli počítači bez nutnosti mít původní soubor handle:

# Obnovení rezidentních klíčů z bezpečnostního tokenu na novém počítači
ssh-keygen -K

# Nebo přidání přímo do ssh-agent bez zápisu na disk
ssh-add -K

Nerezidentní klíče vyžadují jak hardwarový token, tak soubor handle na disku. Jsou bezpečnější v tom smyslu, že ztracený hardware sám o sobě nestačí k autentizaci, ale méně praktické při práci na více zařízeních. Záleží na vašem threat modelu — pro většinu administrátorů jsou rezidentní klíče lepší volbou.

Nasazení na server

# Kopírování veřejného klíče na server
ssh-copy-id -i ~/.ssh/id_ed25519_sk.pub user@server

# Ruční přidání (alternativa)
cat ~/.ssh/id_ed25519_sk.pub | ssh user@server "mkdir -p ~/.ssh && cat >> ~/.ssh/authorized_keys"

# Konfigurace serveru pro přijetí FIDO2 klíčů
# V /etc/ssh/sshd_config přidejte:
PubkeyAcceptedAlgorithms ssh-ed25519,[email protected],[email protected]

Doporučení pro produkční nasazení

• Vždy registrujte dva fyzické klíče — primární a záložní. Ztracený nebo poškozený klíč bez zálohy znamená zamčené dveře
• Nastavte silný FIDO2 PIN — to je váš druhý faktor. Bez PINu stačí ukradený hardware
• Používejte verify-required — volba -O verify-required při generování klíče vynutí zadání PIN při každé autentizaci
• Uchovávejte zálohu veřejných klíčů — veřejné klíče obou tokenů by měly být na všech serverech, ke kterým potřebujete přístup
• Kombinujte s certifikáty SSH CA — pro enterprise prostředí je ideální kombinace FIDO2 s certifikátovou autentizací (viz další kapitola)

SSH certifikátová autorita (SSH CA)

Tradiční správa SSH klíčů — ruční distribuce veřejných klíčů do authorized_keys na každém serveru — se při jakémkoli větším rozsahu stává noční můrou. Kdo někdy spravoval víc než 20 serverů, ví přesně, o čem mluvím. SSH certifikátová autorita (CA) tento problém řeší elegantně: místo důvěry jednotlivým klíčům důvěřujete certifikační autoritě, která podepisuje klíče uživatelů a hostitelů.

Princip fungování

SSH certifikáty se liší od X.509 certifikátů používaných v TLS/SSL — jsou jednodušší a specifické pro OpenSSH. Certifikát obsahuje:

• Veřejný klíč uživatele nebo hostitele
• Identifikační řetězec (certificate ID)
• Seznam povolených principálů (uživatelská jména nebo hostnames)
• Dobu platnosti (validity period)
• Volitelná omezení a rozšíření
• Podpis CA klíče

Krok 1: Vytvoření klíčů CA

# Vytvoření CA klíče pro podepisování uživatelských certifikátů
ssh-keygen -t ed25519 -f /etc/ssh/ca_user_key -C "SSH User CA 2026"

# Vytvoření CA klíče pro podepisování certifikátů hostitelů
ssh-keygen -t ed25519 -f /etc/ssh/ca_host_key -C "SSH Host CA 2026"

# Nastavení oprávnění
chmod 600 /etc/ssh/ca_user_key /etc/ssh/ca_host_key
chmod 644 /etc/ssh/ca_user_key.pub /etc/ssh/ca_host_key.pub

Tohle je kritické: CA klíče jsou nejcitlivějším aktivem celé vaší infrastruktury. Měly by být uloženy na offline stroji nebo ideálně v HSM (Hardware Security Module). Kompromitace CA klíče = kompromitace celé infrastruktury. Žádný prostor pro kompromisy.

Krok 2: Podepsání uživatelského certifikátu

# Podepsání veřejného klíče uživatele
# -s: CA klíč pro podpis
# -I: identifikátor certifikátu (logovaný při použití)
# -n: povolení principálové (uživatelská jména)
# -V: doba platnosti
ssh-keygen -s /etc/ssh/ca_user_key \
    -I "[email protected]" \
    -n jan.novak,deployer \
    -V +8h \
    /home/jan.novak/.ssh/id_ed25519.pub

# Výsledek: /home/jan.novak/.ssh/id_ed25519-cert.pub

# Zobrazení obsahu certifikátu
ssh-keygen -L -f /home/jan.novak/.ssh/id_ed25519-cert.pub

Všimněte si parametru -V +8h — certifikát je platný pouze 8 hodin. Krátkodobé certifikáty jsou osvědčená praxe, protože minimalizují okno zranitelnosti v případě kompromitace. Ano, znamená to každodenní obnovování, ale to se dá snadno automatizovat (k tomu se dostaneme za chvíli).

Krok 3: Podepsání certifikátu hostitele

# Podepsání klíče hostitele (příznak -h označuje certifikát hostitele)
ssh-keygen -s /etc/ssh/ca_host_key \
    -I "webserver01.firma.cz" \
    -h \
    -n webserver01.firma.cz,webserver01,192.168.1.10 \
    -V -5m:+52w \
    /etc/ssh/ssh_host_ed25519_key.pub

# Výsledek: /etc/ssh/ssh_host_ed25519_key-cert.pub

Krok 4: Konfigurace serveru pro certifikáty

# /etc/ssh/sshd_config — přidání certifikátové autentizace

# Certifikát hostitele
HostCertificate /etc/ssh/ssh_host_ed25519_key-cert.pub

# Důvěřovaný CA klíč pro uživatelské certifikáty
TrustedUserCAKeys /etc/ssh/ca_user_key.pub

# Soubor s povolenými principály pro každého uživatele
AuthorizedPrincipalsFile /etc/ssh/auth_principals/%u

# Revokační seznam (Key Revocation List)
RevokedKeys /etc/ssh/revoked_keys

# Vytvoření souboru principálů pro uživatele
mkdir -p /etc/ssh/auth_principals

# Uživatel jan.novak se může přihlásit s principálem "jan.novak" nebo "deployer"
echo -e "jan.novak\ndeployer" > /etc/ssh/auth_principals/jan.novak

# Inicializace prázdného revokačního seznamu
ssh-keygen -k -f /etc/ssh/revoked_keys

Krok 5: Konfigurace klienta pro důvěru hostitelským certifikátům

# Globální důvěra CA hostitele — eliminuje TOFU (Trust On First Use)
echo "@cert-authority *.firma.cz $(cat /etc/ssh/ca_host_key.pub)" >> /etc/ssh/ssh_known_hosts

# Alternativně per-uživatel
echo "@cert-authority *.firma.cz $(cat /etc/ssh/ca_host_key.pub)" >> ~/.ssh/known_hosts

Eliminace TOFU je mimochodem obrovská výhra. Žádné otravné „The authenticity of host can't be established" při prvním připojení — a hlavně žádný prostor pro man-in-the-middle útok při úplně prvním připojení k serveru.

Revokace kompromitovaných klíčů

# Přidání kompromitovaného klíče do revokačního seznamu
ssh-keygen -k -f /etc/ssh/revoked_keys -u kompromitovany_klic.pub

# Revokace celého certifikátu podle sériového čísla
ssh-keygen -k -f /etc/ssh/revoked_keys -u -s ca_user_key \
    kompromitovany_certifikat-cert.pub

Automatizace certifikátů: Integrace s Vault a CI/CD

Ruční podepisování certifikátů je fajn pro malé prostředí, ale jakmile máte víc než pár serverů a vývojářů, potřebujete automatizaci. HashiCorp Vault je jedním z nejpopulárnějších nástrojů pro tento účel — a z dobrého důvodu.

Konfigurace Vault SSH secrets engine

# Zapnutí SSH secrets engine
vault secrets enable -path=ssh-client-signer ssh

# Nahrání CA klíče do Vault
vault write ssh-client-signer/config/ca \
    private_key=@ca_user_key \
    public_key=@ca_user_key.pub

# Vytvoření role pro podepisování
vault write ssh-client-signer/roles/admin \
    algorithm_signer="rsa-sha2-256" \
    key_type="ca" \
    default_user="admin" \
    allowed_users="admin,deployer,jan.novak" \
    ttl="8h" \
    max_ttl="24h" \
    allow_user_certificates=true

Podepisování certifikátů přes Vault

# Podepsání veřejného klíče přes Vault API
vault write ssh-client-signer/sign/admin \
    public_key=@$HOME/.ssh/id_ed25519.pub \
    valid_principals="jan.novak" \
    ttl="8h"

# Integrace do CI/CD pipeline (příklad pro GitLab CI)
# .gitlab-ci.yml
deploy:
  script:
    - export VAULT_TOKEN=$(vault write -field=token auth/jwt/login role=deploy jwt=$CI_JOB_JWT)
    - vault write -field=signed_key ssh-client-signer/sign/deploy
        public_key=@/root/.ssh/id_ed25519.pub
        valid_principals="deployer" > /root/.ssh/id_ed25519-cert.pub
    - ssh [email protected] "cd /app && git pull && systemctl restart app"

Pokročilé techniky hardeningu

Kromě kryptografické konfigurace existuje celá řada dalších technik, které bezpečnost SSH výrazně posouvají. Pojďme se na ně podívat.

PerSourcePenalties: Inteligentní ochrana proti útokům

OpenSSH 9.8 zavedl (a další verze rozšířily) mechanismus PerSourcePenalties, který automaticky penalizuje IP adresy na základě podezřelého chování:

# /etc/ssh/sshd_config
# Penalizace za různé typy selhání
PerSourcePenalties crash:90s,authfail:5s,noauth:2s,grace-exceeded:20s

# Maximální délka penalizace
PerSourcePenaltyExemptList 10.0.0.0/8,172.16.0.0/12

Tohle je výrazně efektivnější než tradiční fail2ban, protože je to integrované přímo v SSH démonu. Žádné parsování logů, žádná latence — reakce je okamžitá. Pokud stále používáte fail2ban jako primární ochranu SSH, zvažte přechod na PerSourcePenalties.

Omezení příkazů v authorized_keys

Pro servisní účty a automatizované procesy je dobré omezit, co daný klíč smí dělat. Princip nejmenších oprávnění (least privilege) platí i tady:

# ~/.ssh/authorized_keys s omezením
command="/usr/local/bin/backup.sh",no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty ssh-ed25519 AAAA... backup-service

# Omezení s certifikáty — při podepisování
ssh-keygen -s ca_user_key \
    -I "backup-service" \
    -n backup \
    -O force-command="/usr/local/bin/backup.sh" \
    -O no-port-forwarding \
    -O no-x11-forwarding \
    -V +24h \
    backup_key.pub

Konfigurace firewallu pro SSH

Omezení přístupu k SSH na síťové úrovni je kritickou vrstvou obrany. Pokud SSH port visí otevřený na celý internet, žádná konfigurace sshd_config vás plně neochrání:

# nftables pravidla pro SSH
table inet filter {
    set ssh_allowed {
        type ipv4_addr
        flags interval
        elements = { 10.0.0.0/8, 192.168.1.0/24 }
    }

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

        # Povolení SSH pouze z důvěryhodných sítí
        tcp dport 22 ip saddr @ssh_allowed ct state new accept

        # Rate limiting pro povolené sítě
        tcp dport 22 ct state new limit rate 5/minute accept

        # Logování odmítnutých pokusů
        tcp dport 22 log prefix "SSH-DENIED: " drop
    }
}

Monitorování a audit

Logování na úrovni VERBOSE vám dá detailní pohled na každý pokus o přihlášení. A věřte mi — ty logy se vyplatí číst, obzvlášť po incidentu:

# Analýza logů SSH (journalctl)
journalctl -u sshd --since "1 hour ago" | grep -E "(Accepted|Failed|Disconnected)"

# Sledování úspěšných certifikátových přihlášení
journalctl -u sshd | grep "Accepted publickey.*-cert"

# Monitorování použitých algoritmů
journalctl -u sshd | grep "kex:"

# Auditování s auditd
# /etc/audit/rules.d/ssh.rules
-w /etc/ssh/sshd_config -p wa -k sshd_config_change
-w /etc/ssh/authorized_keys -p wa -k ssh_authorized_keys
-w /etc/ssh/ca_user_key.pub -p r -k ssh_ca_access

Migrace ze starších verzí: Krok za krokem

Pokud spravujete infrastrukturu se staršími verzemi OpenSSH (a ruku na srdce — kdo ne?), migrace na post-kvantovou kryptografii vyžaduje pečlivý a promyšlený postup. Následující plán minimalizuje riziko výpadku.

Fáze 1: Audit současného stavu

# Zjištění verze OpenSSH na všech serverech
for server in $(cat servers.txt); do
    echo -n "$server: "
    ssh "$server" "ssh -V 2>&1"
done

# Kontrola aktuálně používaných algoritmů
ssh -vvv user@server 2>&1 | grep -E "(kex:|cipher:|mac:)"

# Skenování SSH konfigurace pomocí ssh-audit
pip install ssh-audit
ssh-audit server.firma.cz

Fáze 2: Příprava — přidání nových algoritmů

# Na serverech s OpenSSH 9.9+ přidejte post-kvantové algoritmy
# BEZ odstraňování starých (zpětná kompatibilita)
KexAlgorithms mlkem768x25519-sha256,sntrup761x25519-sha512,curve25519-sha256,diffie-hellman-group16-sha512

# Generování nových hostitelských klíčů Ed25519 (pokud chybí)
ssh-keygen -t ed25519 -f /etc/ssh/ssh_host_ed25519_key -N ""

Fáze 3: Testování a validace

# Ověření, že se klient připojí s post-kvantovým algoritmem
ssh -o KexAlgorithms=mlkem768x25519-sha256 -v user@server 2>&1 | grep "kex:"
# Očekávaný výstup: kex: algorithm: mlkem768x25519-sha256

# Test zpětné kompatibility se staršími klienty
ssh -o KexAlgorithms=curve25519-sha256 user@server

Fáze 4: Zpřísnění — odstranění zastaralých algoritmů

# Po ověření, že všichni klienti podporují nové algoritmy
KexAlgorithms mlkem768x25519-sha256,sntrup761x25519-sha512,curve25519-sha256
Ciphers [email protected],[email protected],[email protected]
MACs [email protected],[email protected]

Srovnání bezpečnostních algoritmů: Co použít a čemu se vyhnout

Orientace v kryptografických algoritmech může být pěkně matoucí, obzvlášť s tím, jak rychle se věci mění. Tady je přehledné shrnutí — uložte si ho, budete se k němu vracet.

Algoritmy pro výměnu klíčů (Key Exchange)

Algoritmus	Post-kvantový	Minimální verze OpenSSH	Doporučení
mlkem768x25519-sha256	Ano (hybridní)	9.9	Primární volba — NIST standardizovaný ML-KEM
sntrup761x25519-sha512	Ano (hybridní)	9.0	Záložní volba — alternativní PQ schéma
curve25519-sha256	Ne	6.5	Fallback pro kompatibilitu — bezpečný proti klasickým útokům
diffie-hellman-group16-sha512	Ne	7.3	Pouze pro starší systémy — vyřadit co nejdříve
diffie-hellman-group14-sha256	Ne	7.3	Zastaralý — nedoporučuje se
diffie-hellman-group1-sha1	Ne	N/A (odstraněn)	Odstraněn — aktivně nebezpečný

Šifry pro přenos dat

Výběr šifry ovlivňuje jak bezpečnost, tak výkon. Tahle volba je důležitější, než si většina lidí myslí:

Šifra	Režim	Doporučení
[email protected]	AEAD	Nejvyšší priorita — excelentní výkon na CPU bez AES-NI
[email protected]	AEAD	Preferovaná — optimální výkon na CPU s AES-NI instrukcemi
[email protected]	AEAD	Přijatelná — menší bezpečnostní marže, ale stále bezpečná
aes256-ctr	CTR + odděl. MAC	Pouze kompatibilita — preferujte GCM varianty
aes*-cbc	CBC	Zakázat — zranitelný vůči padding oracle útokům

V praxi je volba mezi ChaCha20 a AES-GCM často otázkou hardwaru. Servery s procesory Intel/AMD podporujícími AES-NI budou mít výrazně lepší výkon s AES-GCM. Naopak ARM procesory (třeba v Raspberry Pi nebo některých cloudových instancích) obvykle lépe pracují s ChaCha20. OpenSSH 10.0+ tohle řeší inteligentně a řadí šifry s ohledem na dostupný hardware.

Typy klíčů pro autentizaci

Výběr typu klíče pro autentizaci uživatele si zaslouží pozornost. Tady je aktuální stav:

• Ed25519 — nejlepší volba pro softwarové klíče. Kompaktní (32 bajtů), rychlé operace, silná bezpečnost. Podporován od OpenSSH 6.5
• Ed25519-SK — nejlepší volba pro hardwarové klíče FIDO2. Kombinuje výhody Ed25519 s hardwarovou ochranou. Podporován od OpenSSH 8.2
• RSA (4096 bit) — stále bezpečný, ale generuje velké klíče a pomalejší operace. Používejte pouze s podpisovými algoritmy rsa-sha2-256 nebo rsa-sha2-512, nikdy ssh-rsa (SHA-1)
• ECDSA — bezpečný, ale existují obavy ohledně kvality generátoru náhodných čísel. Ed25519 je obecně preferován
• DSA — odstraněn v OpenSSH 10.0. Pokud máte ještě někde DSA klíče, migrujte okamžitě na Ed25519

Řešení běžných problémů při migraci

Migrace na moderní SSH konfiguraci se zřídka obejde bez pár komplikací. Tady jsou nejčastější problémy, se kterými se setkáte, a jak je vyřešit.

Problém: Klient nepodporuje post-kvantové algoritmy

Pokud se starší klient pokusí připojit k serveru, který nabízí pouze post-kvantové algoritmy, spojení selže s chybou „no matching key exchange method found". Není to nic dramatického, ale je potřeba to řešit:

# Diagnostika: zobrazení algoritmů nabízených serverem
ssh -vvv user@server 2>&1 | grep "peer server KEXINIT"

# Řešení na straně serveru: přidání fallback algoritmu
KexAlgorithms mlkem768x25519-sha256,sntrup761x25519-sha512,curve25519-sha256

# Řešení na straně klienta: aktualizace OpenSSH
# Debian/Ubuntu
sudo apt update && sudo apt install openssh-client

# RHEL/Fedora
sudo dnf update openssh-clients

# Ověření verze
ssh -V

Problém: FIDO2 klíč nefunguje — „device not found"

Klasika. Nejčastější příčinou je chybějící middleware pro FIDO2 nebo špatná oprávnění USB:

# Instalace potřebných knihoven
# Debian/Ubuntu
sudo apt install libfido2-dev libfido2-1 fido2-tools

# RHEL/Fedora
sudo dnf install libfido2 libfido2-devel fido2-tools

# Kontrola, zda systém vidí FIDO2 zařízení
fido2-token -L

# Pokud zařízení není viditelné, přidejte udev pravidlo
# /etc/udev/rules.d/70-fido2.rules
KERNEL=="hidraw*", SUBSYSTEM=="hidraw", ATTRS{idVendor}=="1050", TAG+="uaccess"

# Pro YubiKey 5 series:
KERNEL=="hidraw*", SUBSYSTEM=="hidraw", ATTRS{idVendor}=="1050", ATTRS{idProduct}=="0407", TAG+="uaccess"

# Reload udev pravidel
sudo udevadm control --reload-rules && sudo udevadm trigger

Problém: Certifikát SSH CA je odmítnut

Při práci s SSH certifikáty se odmítnutí certifikátu stane dřív nebo později každému. Dobrá zpráva: OpenSSH 10.1 výrazně vylepšil logování těchto situací:

# Kontrola obsahu certifikátu
ssh-keygen -L -f /path/to/certificate-cert.pub

# Typické příčiny odmítnutí:
# 1. Vypršená platnost — zkontrolujte Valid: řádek
# 2. Špatný principál — zkontrolujte Principals: řádek
# 3. CA není důvěryhodná — zkontrolujte TrustedUserCAKeys v sshd_config
# 4. Principál není v AuthorizedPrincipalsFile

# Podrobné logování na serveru pro diagnostiku
sudo journalctl -u sshd -f --no-pager | grep -i cert

# Testovací připojení s maximální verbositou
ssh -vvv -i ~/.ssh/id_ed25519 -o CertificateFile=~/.ssh/id_ed25519-cert.pub user@server

Problém: Výkonnostní dopad post-kvantových algoritmů

Post-kvantové algoritmy mají větší velikost klíčů a potenciálně vyšší výpočetní nároky. V praxi je ale dopad překvapivě minimální díky hybridnímu přístupu:

# Měření doby navázání spojení s různými algoritmy
# Post-kvantový (mlkem768x25519-sha256)
time ssh -o KexAlgorithms=mlkem768x25519-sha256 user@server exit

# Klasický (curve25519-sha256)
time ssh -o KexAlgorithms=curve25519-sha256 user@server exit

# Typický rozdíl je 1–5 ms na moderním hardware
# Pro dávkové operace s mnoha krátkými spojeními zvažte multiplexing:
# ~/.ssh/config
Host server.firma.cz
    ControlMaster auto
    ControlPath ~/.ssh/sockets/%r@%h-%p
    ControlPersist 600

Multiplexing SSH spojení je zvláště důležitý při použití post-kvantových algoritmů v prostředích s vysokou frekvencí krátkých spojení (Ansible, hromadné scp a podobně). Místo opakovaného navazování spojení s plným handshake se využívá existující tunel — jakýkoli výkonnostní overhead se tím kompletně eliminuje.

Kontrolní seznam zabezpečení SSH pro rok 2026

Následující kontrolní seznam shrnuje všechna doporučení z tohoto článku. Vytiskněte si ho, uložte do wiki — prostě mějte po ruce při příštím auditu:

Oblast	Opatření	Priorita
Verze	OpenSSH 10.0+ na všech serverech a klientech	Kritická
Výměna klíčů	mlkem768x25519-sha256 jako primární KexAlgorithm	Kritická
Šifry	ChaCha20-Poly1305 nebo AES-GCM, žádné CBC režimy	Vysoká
Autentizace	Zakázat hesla, používat klíče Ed25519 nebo FIDO2	Kritická
FIDO2	ed25519-sk s verify-required pro administrátory	Vysoká
Certifikáty	SSH CA pro prostředí s více než 10 servery	Vysoká
TTL certifikátů	Maximálně 8–24 hodin pro uživatelské certifikáty	Střední
DSA	Kompletně odstraněn (OpenSSH 10.0+)	Kritická
Root přístup	PermitRootLogin prohibit-password nebo no	Kritická
Brute-force	PerSourcePenalties aktivovány	Vysoká
Forwarding	Zakázat X11, TCP a Agent forwarding pokud není potřeba	Střední
Firewall	SSH přístupný pouze z důvěryhodných sítí	Kritická
Logování	LogLevel VERBOSE, integrace s auditd	Vysoká
Revokace	Aktivní RevokedKeys soubor na všech serverech	Střední

Soulad s regulacemi a standardy

Zabezpečení SSH není jen otázkou technické správnosti — v mnoha odvětvích existují regulatorní požadavky, které vyžadují specifickou konfiguraci. A rok 2025 přinesl významné změny i na tomto poli, zejména finalizaci standardu NIST SP 800-63-4.

NIST SP 800-63-4: Nové požadavky na autentizaci

Finální verze NIST SP 800-63-4 (z července 2025) přináší zásadní změny pro autentizaci vzdáleného přístupu, včetně SSH:

• AAL2 (Authenticator Assurance Level 2) — nyní musí nabízet phishing-rezistentní volbu. To se týká i SSH přístupu k produkčním serverům. FIDO2 klíče (ed25519-sk) tento požadavek splňují
• AAL3 — vyžaduje hardwarově vázané, neexportovatelné klíče. Synkronizované passkeys nejsou na této úrovni povoleny. Pro SSH to znamená fyzické bezpečnostní klíče (YubiKey, Nitrokey) s neexportovatelnými soukromými klíči
• SMS a e-mailové OTP jsou nedostatečné — pokud stále používáte Google Authenticator nebo podobné TOTP řešení jako druhý faktor pro SSH, je nejvyšší čas zvážit migraci na FIDO2

PCI DSS 4.0 a SSH

PCI DSS 4.0, platný od 31. března 2025, obsahuje zpřísněné požadavky na vzdálený přístup k systémům zpracovávajícím karetní data:

• Požadavek 8.3.1 vyžaduje vícefaktorovou autentizaci pro veškerý přístup do prostředí karetních dat (CDE)
• Požadavek 8.3.2 rozšiřuje MFA na veškerý vzdálený síťový přístup pocházející mimo důvěryhodnou síť
• Požadavek 2.2.7 vyžaduje šifrování veškerého nekonzolového administrativního přístupu pomocí silné kryptografie

V praxi to znamená, že SSH přístup k serverům v PCI scope musí využívat minimálně MFA (splnitelné pomocí FIDO2 klíčů) a silné kryptografické algoritmy. Post-kvantová výměna klíčů tento požadavek splňuje s velkou rezervou.

Automatizovaný audit SSH konfigurace

Pro průběžnou kontrolu souladu s bezpečnostními standardy se vyplatí automatizovat audit SSH konfigurace. Nástroj ssh-audit je pro tohle skvělý:

# Instalace ssh-audit
pip install ssh-audit

# Audit serveru — zobrazí hodnocení všech algoritmů
ssh-audit server.firma.cz

# Audit s výstupem ve formátu JSON (pro automatizaci)
ssh-audit --json server.firma.cz > ssh-audit-report.json

# Hromadný audit všech serverů
for server in $(cat servers.txt); do
    echo "=== $server ===" >> audit-report.txt
    ssh-audit --no-colors "$server" >> audit-report.txt 2>&1
done

# Skript pro kontrolu konkrétních požadavků
#!/bin/bash
# check-ssh-compliance.sh
SERVER="$1"
RESULT=$(ssh-audit --json "$SERVER" 2>/dev/null)

# Kontrola post-kvantových algoritmů
if echo "$RESULT" | python3 -c "
import json, sys
data = json.load(sys.stdin)
kex = [k['algorithm'] for k in data.get('kex', [])]
pq = any('mlkem' in k or 'sntrup' in k for k in kex)
print('PQ_OK' if pq else 'PQ_MISSING')
" | grep -q "PQ_OK"; then
    echo "[OK] $SERVER: Post-kvantové algoritmy dostupné"
else
    echo "[WARN] $SERVER: Chybí post-kvantové algoritmy"
fi

Integrace s SIEM a centrálním logováním

Pro organizace s centrálním řízením bezpečnosti je integrace SSH logů do SIEM systému nezbytností. Tady je konfigurace, která zajistí strukturované logování kompatibilní s běžnými SIEM platformami:

# /etc/ssh/sshd_config — rozšířené logování
LogLevel VERBOSE
SyslogFacility AUTH

# Přesměrování SSH logů do samostatného souboru (rsyslog)
# /etc/rsyslog.d/ssh.conf
:programname, isequal, "sshd" /var/log/ssh.log
& stop

# Logrotate konfigurace
# /etc/logrotate.d/ssh
/var/log/ssh.log {
    daily
    rotate 90
    compress
    delaycompress
    missingok
    notifempty
    create 0640 root adm
    postrotate
        /usr/lib/rsyslog/rsyslog-rotate
    endscript
}

# Příklad pravidla pro detekci anomálií (pro Elasticsearch/Watcher)
# Detekce úspěšného přihlášení z neznámé IP po sérii neúspěšných pokusů
{
  "trigger": { "schedule": { "interval": "5m" } },
  "input": {
    "search": {
      "request": {
        "indices": ["ssh-logs-*"],
        "body": {
          "query": {
            "bool": {
              "must": [
                { "match": { "message": "Accepted" } },
                { "range": { "@timestamp": { "gte": "now-5m" } } }
              ]
            }
          }
        }
      }
    }
  }
}

Závěr: Budoucnost SSH je post-kvantová

OpenSSH 10.0 a 10.1 vysílají jednoznačný signál: éra klasické kryptografie v SSH se chýlí ke konci. Post-kvantové algoritmy jsou dnes výchozím nastavením, varování o slabé kryptografii jsou aktivní a SHA-1 SSHFP záznamy budou brzy ignorovány. Směr je jasný a nevratný.

Pro administrátory a bezpečnostní inženýry to znamená jednu věc: akci. Teď, ne za rok. Hrozba „store now, decrypt later" je reálná a každý den, kdy vaše SSH spojení nepoužívá post-kvantovou výměnu klíčů, je dnem, kdy mohou být vaše data zachycena pro budoucí dešifrování.

Kombinace post-kvantové kryptografie, hardwarové FIDO2 autentizace a certifikátové autority vytváří trojvrstvou obranu odolnou vůči současným i budoucím hrozbám. Implementace těchto technologií není luxus — je to nezbytnost pro každou organizaci, která bere bezpečnost vážně.

Začněte dnes: aktualizujte OpenSSH, povolte post-kvantové algoritmy, nasaďte FIDO2 klíče a zvažte SSH CA pro správu důvěry. Za půl roku si poděkujete.