Prihlasovanie heslom cez SSH je najväčšia otvorená plocha bežného servera. Proti nemu sú bezmocné aj Fail2ban, aj akékoľvek prahy: tisíc adries po jednom pokuse za hodinu nikdy nedosiahne limit a skúšať budú presne tak dlho, kým je hádanie vôbec možné. Kľúče odstraňujú samotnú možnosť a je to jediné nastavenie z celého zoznamu utužovania, ktoré mení situáciu kvalitatívne.

Straší tu jediné: vypnúť heslo a zostať vonku. Nižšie je postup, pri ktorom je to vylúčené.

Kľúč

Generuje sa na vlastnom stroji, nie na serveri:

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

ed25519 namiesto RSA — kratší, rýchlejší a bez otázok na dĺžku. RSA je potrebné len vtedy, keď sa chystáte pripájať k niečomu veľmi starému; potom -t rsa -b 4096.

Heslo ku kľúču (passphrase) nastaviť sa oplatí: súbor kľúča môžu ukradnúť z notebooku a bez hesla funguje okamžite. Zadávať ho zakaždým nemusíte — o to sa stará ssh-agent, a na macOS aj väčšine desktopových Linuxov už beží.

Skopírovanie na server jedným príkazom, kým heslo ešte funguje:

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

Ak ssh-copy-id nie je k dispozícii, obsah súboru .pub sa pripíše ako riadok do ~/.ssh/authorized_keys na serveri. Práva sú dôležité: adresár .ssh — 700, súbor — 600, vlastníkom používateľ sám. Pri iných právach sshd mlčky odmietne súbor čítať a je to najčastejšia príčina toho, že „kľúč nefunguje“.

Kontrola, ktorá rozhoduje o všetkom

Skôr než čokoľvek vypnete, otvorte druhé spojenie bez zatvorenia prvého:

ssh -o PasswordAuthentication=no user@203.0.113.25

Voľba zakazuje klientovi ustúpiť k heslu — ak teda prihlásenie prebehlo, prebehlo práve kľúčom. Kým tento príkaz neprejde, k ďalšiemu kroku prejsť nemožno. A prvé spojenie až do konca nezatvárame: cezeň sa opraví všetko, čo sa dá rozbiť.

Vypnutie hesla a jedna nezrejmá pasca

Nastavenia dávame do samostatného súboru, aby ich aktualizácia balíka neprepísala. Ale na názve súboru 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

Vec sa má tak, že OpenSSH používa prvú nájdenú hodnotu parametra, nie poslednú, ako je to takmer všade inde. Súbory z sshd_config.d sa čítajú podľa abecedy a cloudové obrazy Ubuntu tam ukladajú 50-cloud-init.conf, v ktorom nezriedka stojí PasswordAuthentication yes. Váš súbor s číslom 90 potom neurobí nič: nastavenie je zdanlivo zapísané, ale heslo ďalej funguje. Odtiaľ číslo 10 — číta sa skôr.

Čo z toho napokon vzišlo, nemusíte hádať:

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

Tento príkaz vypíše platnú konfiguráciu po všetkých vloženiach. Verte jej, nie obsahu súborov.

Ďalej kontrola syntaxe a mäkké znovunačítanie služby:

sudo sshd -t && sudo systemctl reload ssh

sshd -t je povinný: preklep v konfigurácii pri restart nechá službu ležať a vás vonku. reload navyše netrhá otvorené relácie.

Ubuntu 24.04: port sa mení inde

Zvláštna pasca čerstvých Ubuntu: sshd sa tam spúšťa cez socket systemd. Riadok Port v sshd_config v tomto režime nerobí nič — počúva socket, nie démon. Ak meníte port, upravovať treba jeho:

sudo systemctl edit ssh.socket

a uviesť ListenStream= (prázdna hodnota ruší predchádzajúcu) s novým portom. Príznak, podľa ktorého sa to spozná: konfigurácia zmenená, služba reštartovaná, a server ďalej odpovedá na 22.

Mimochodom k zmene portu: ako ochrana nefunguje — skenery nájdu službu na ľubovoľnom porte za minúty. Jediný jej efekt je, že v logoch je ticho, lebo hromadné hádanie ide len na 22. To je pohodlné, ale nepleťte si to s bezpečnosťou.

Kto sa vôbec smie prihlásiť

Užitočným doplnkom je výslovný zoznam:

AllowUsers deploy admin

Všetko, čo nie je vymenované, sa odreže ešte pred kontrolou kľúča. Zároveň to pokrýva prípad, keď nejaký balík založí systémového používateľa so shellom a domovským adresárom.

Záložný vstup

Jeden kľúč na jednom notebooku je jediný bod zlyhania. Disk zomrie, notebook sa stratí a server sa stane nedostupným navždy. Rozumné minimum:

  • druhý kľúč z iného zariadenia v authorized_keys;
  • kópia súkromného kľúča v správcovi hesiel alebo na šifrovanom USB kľúči;
  • overený prístup ku konzole u poskytovateľa — VNC alebo sériová. Overený znamená, že ste sa tam aspoň raz prihlásili, nie že „niekde v paneli je tlačidlo“.

Zároveň sa pozrite, čo už v authorized_keys leží — aj u vášho používateľa, aj u roota. Cudzí kľúč tam prežije akúkoľvek zmenu hesla a zostáva funkčným prístupom.

Potom

Hádanie hesiel nikam nezmizne, len je teraz neužitočné: v logoch zostanú tisíce Failed password, z ktorých ani jedno nemôže skončiť úspechom. Teraz sa však oplatí pozerať na úspešné prihlásenia: z akej adresy, pod akým používateľom, v akom čase. Úspešné prihlásenie kľúčom z neznámej adresy je oveľa dôležitejšia udalosť než milión neúspešných pokusov a vo všeobecnom prúde si ju všimnúť je oveľa ťažšie. Práve tento obraz ukazuje ukážková stránka nižšie.