Přihlašování heslem přes SSH je největší otevřená plocha běžného serveru. Proti němu jsou bezmocné jak Fail2ban, tak jakékoli prahy: tisíc adres po jednom pokusu za hodinu nikdy nedosáhne limitu a zkoušet budou přesně tak dlouho, dokud je hádání vůbec možné. Klíče odstraňují samotnou možnost a je to jediné nastavení z celého seznamu utužování, které mění situaci kvalitativně.

Straší tu jediné: vypnout heslo a zůstat venku. Níže je postup, při kterém je to vyloučené.

Klíč

Generuje se na vlastním stroji, ne na serveru:

ssh-keygen -t ed25519 -C "pracovní notebook"

ed25519 místo RSA — kratší, rychlejší a bez otázek na délku. RSA je potřeba jen tehdy, když se chystáte připojovat k něčemu velmi starému; pak -t rsa -b 4096.

Heslo ke klíči (passphrase) nastavit stojí za to: soubor klíče mohou ukrást z notebooku a bez hesla funguje okamžitě. Zadávat je pokaždé nemusíte — o to se stará ssh-agent, a na macOS i většině desktopových Linuxů už běží.

Zkopírování na server jedním příkazem, dokud heslo ještě funguje:

ssh-copy-id -i ~/.ssh/id_ed25519.pub user@203.0.113.25

Pokud ssh-copy-id není k dispozici, obsah souboru .pub se připíše jako řádek do ~/.ssh/authorized_keys na serveru. Práva jsou důležitá: adresář .ssh — 700, soubor — 600, vlastníkem uživatel sám. Při jiných právech sshd mlčky odmítne soubor číst a je to nejčastější příčina toho, že „klíč nefunguje“.

Kontrola, která rozhoduje o všem

Než cokoli vypnete, otevřete druhé spojení, aniž byste zavřeli první:

ssh -o PasswordAuthentication=no user@203.0.113.25

Volba zakazuje klientovi ustoupit k heslu — pokud tedy přihlášení proběhlo, proběhlo právě klíčem. Dokud tento příkaz neprojde, k dalšímu kroku přejít nelze. A první spojení až do konce nezavíráme: přes ně se opraví vše, co lze rozbít.

Vypnutí hesla a jedna nezřejmá past

Nastavení dáváme do samostatného souboru, aby je aktualizace balíčku nepřepsala. Ale na názvu souboru záleží:

sudo tee /etc/ssh/sshd_config.d/10-hardening.conf <<'EOF'
PasswordAuthentication no
PermitRootLogin no
KbdInteractiveAuthentication no
PubkeyAuthentication yes
MaxAuthTries 3
LogLevel VERBOSE
EOF

Věc se má tak, že OpenSSH používá první nalezenou hodnotu parametru, ne poslední, jak je tomu téměř všude jinde. Soubory z sshd_config.d se čtou podle abecedy a cloudové obrazy Ubuntu tam ukládají 50-cloud-init.conf, v němž nezřídka stojí PasswordAuthentication yes. Váš soubor s číslem 90 pak neudělá nic: nastavení je zdánlivě zapsané, ale heslo dál funguje. Odtud číslo 10 — čte se dřív.

Co z toho nakonec vzešlo, nemusíte hádat:

sudo sshd -T | grep -Ei 'passwordauth|permitrootlogin|pubkeyauth'

Tento příkaz vypíše platnou konfiguraci po všech vloženích. Věřte jí, ne obsahu souborů.

Dále kontrola syntaxe a měkké znovunačtení služby:

sudo sshd -t && sudo systemctl reload ssh

sshd -t je povinný: překlep v konfiguraci při restart nechá službu ležet a vás venku. reload navíc netrhá otevřená sezení.

Ubuntu 24.04: port se mění jinde

Zvláštní past čerstvých Ubuntu: sshd se tam spouští přes socket systemd. Řádek Port v sshd_config v tomto režimu nedělá nic — naslouchá socket, ne démon. Pokud měníte port, upravovat je třeba jej:

sudo systemctl edit ssh.socket

a uvést ListenStream= (prázdná hodnota ruší předchozí) s novým portem. Příznak, podle kterého se to pozná: konfigurace změněna, služba restartována, a server dál odpovídá na 22.

Mimochodem ke změně portu: jako ochrana nefunguje — skenery najdou službu na libovolném portu za minuty. Jediný její efekt je, že v logách je ticho, protože hromadné hádání jde jen na 22. To je pohodlné, ale nepleťte si to s bezpečností.

Kdo se vůbec smí přihlásit

Užitečným doplňkem je výslovný seznam:

AllowUsers deploy admin

Vše, co není vyjmenováno, se odřízne ještě před kontrolou klíče. Zároveň to pokrývá případ, kdy nějaký balíček založí systémového uživatele se shellem a domovským adresářem.

Záložní vstup

Jeden klíč na jednom notebooku je jediný bod selhání. Disk zemře, notebook se ztratí a server se stane nedostupným navždy. Rozumné minimum:

  • druhý klíč z jiného zařízení v authorized_keys;
  • kopie soukromého klíče ve správci hesel nebo na šifrovaném flash disku;
  • ověřený přístup ke konzoli u poskytovatele — VNC nebo sériová. Ověřený znamená, že jste se tam alespoň jednou přihlásili, ne že „někde v panelu je tlačítko“.

Zároveň se podívejte, co už v authorized_keys leží — jak u vašeho uživatele, tak u roota. Cizí klíč tam přežije jakoukoli změnu hesla a zůstává funkčním přístupem.

Poté

Hádání hesel nikam nezmizí, jen je nyní neužitečné: v logách zůstanou tisíce Failed password, z nichž ani jedno nemůže skončit úspěchem. Nyní se však vyplatí dívat na úspěšná přihlášení: z jaké adresy, pod jakým uživatelem, v jakou dobu. Úspěšné přihlášení klíčem z neznámé adresy je mnohem důležitější událost než milion neúspěšných pokusů a v obecném proudu je mnohem těžší si jí všimnout. Právě tento obraz ukazuje ukázková stránka níže.