OpenSSH Hardening na Linuxu 2026: PQ KEX + FIDO2

Ažurirano: 1. lipnja 2026.

Otvrdnjavanje OpenSSH-a u 2026. znači uključiti hibridnu post-kvantnu razmjenu ključeva (mlkem768x25519-sha256 ili sntrup761x25519-sha512), prebaciti se na Ed25519 ključeve s FIDO2 hardverskim tokenima, isključiti lozinke i root prijavu te složiti slojevitu obranu (sshd_config, nftables, Fail2ban). Ova konfiguracija zatvara oko 95% napadne površine SSH-a i štiti vas od "store-now, decrypt-later" napada koji ciljaju klasičnu kriptografiju.

• OpenSSH 10.2 (Ubuntu 26.04) standardno koristi NIST-ov ML-KEM-768 hibridni KEX; OpenSSH 9.x podržava samo sntrup761x25519-sha512.
• Ed25519 ostaje preporučeni format ključa: 68 znakova duga javna komponenta, brža od RSA-4096, bez pogrešaka u izboru parametara.
• Pet promjena u sshd_config eliminira gotovo sav automatizirani napad: PermitRootLogin no, PasswordAuthentication no, MaxAuthTries 3, AllowUsers, te jake šifre i MAC-ovi.
• Fail2ban s backendom systemd i nftables rate-limit pravila čine slojeve obrane, pa pojedinačni napadač ne probija sve odjednom.
• Alat ssh-audit automatski otkriva slabe algoritme; pokrenite ga prije svake produkcije.
• Konfiguracija se sprema u /etc/ssh/sshd_config.d/99-hardening.conf kako vam nadogradnja paketa ne bi prebrisala promjene.

Zašto je post-kvantni KEX obavezan u 2026.

Klasične SSH razmjene ključeva (curve25519-sha256, ECDH-P256, DH-group14) temelje se na težini diskretnog logaritma i problema eliptičnih krivulja. Shorov algoritam, kada bude pokrenut na dovoljno velikom kvantnom računalu, rješava oba u polinomnom vremenu. To znači da svaka SSH sesija zaštićena isključivo klasičnom kriptografijom ima rok trajanja. Napadač koji danas snimi promet može ga dešifrirati za pet ili deset godina kada hardver sazri. Poznati store-now, decrypt-later scenarij, dakle.

OpenSSH 9.0 je 2022. uveo [email protected] kao prvi hibridni post-kvantni KEX. OpenSSH 10.0 dodaje NIST-standardizirani mlkem768x25519-sha256 (FIPS 203, prije poznat kao Kyber). Verzija 10.2 koja dolazi s Ubuntuom 26.04 ima ML-KEM-768 uključen prema zadanim postavkama. Oba algoritma su hibridna: kombiniraju post-kvantnu komponentu s klasičnim X25519, pa ako jedan ikad bude probijen, drugi nastavlja štititi sesiju. Najnovija izdanja izbacuju i upozorenje na klijentu kad se server ne pridržava: "connection is not using a post-quantum key exchange algorithm". Više detalja u službenim OpenSSH bilješkama o izdanju.

Praktična dodatna latencija ML-KEM rukovanja je 1–2 ms u odnosu na čisti X25519; payload je oko 1,5 KB veći. Na bilo kojoj modernoj vezi razlika je neprimjetna, a ControlMaster dijeljenje sesije ionako eliminira trošak za ponovljene konekcije. Iskreno, kad sam ovo prvi put uključio na fleetu od dvjestotinjak servera, čekao sam neke pritužbe deploy timova. Stiglo je točno nula. Ako vaš fleet vrti OpenSSH 9.6 ili noviji, danas možete uključiti PQ KEX bez vidljivih posljedica po korisnike.

Minimalna otvrđena konfiguracija sshd_config

Nikada ne uređujte /etc/ssh/sshd_config izravno na sustavima koje održavate paketnim menadžerom. Stavite vlastite postavke u drop-in datoteku. Ubuntu 24.04+, Debian 12+, Fedora 39+ i RHEL 9+ već uključuju red Include /etc/ssh/sshd_config.d/*.conf. Tako vaše promjene nadživljavaju nadogradnju paketa, lako se verzioniraju u Git-u i jasno se odvajaju od distribucijskih zadanih vrijednosti.

# /etc/ssh/sshd_config.d/99-hardening.conf
# Zabrana root prijave i lozinki: najveći učinak po retku konfiguracije
PermitRootLogin no
PasswordAuthentication no
KbdInteractiveAuthentication no
ChallengeResponseAuthentication no
PermitEmptyPasswords no
UsePAM yes

# Smanjenje napadne površine
MaxAuthTries 3
MaxSessions 4
LoginGraceTime 30
ClientAliveInterval 300
ClientAliveCountMax 2
TCPKeepAlive no
X11Forwarding no
AllowAgentForwarding no
AllowTcpForwarding no
PermitUserEnvironment no
PrintLastLog yes
LogLevel VERBOSE

# Eksplicitno dozvoljeni korisnici (zamijenite "deploy admin")
AllowUsers deploy admin

# Post-kvantni KEX, AEAD šifre, ETM MAC-ovi, Ed25519 host ključ
KexAlgorithms mlkem768x25519-sha256,[email protected],curve25519-sha256,[email protected]
Ciphers [email protected],[email protected],[email protected]
MACs [email protected],[email protected]
HostKeyAlgorithms ssh-ed25519,[email protected],rsa-sha2-512,rsa-sha2-256
PubkeyAcceptedAlgorithms ssh-ed25519,[email protected],rsa-sha2-512,rsa-sha2-256

Validirajte konfiguraciju prije restarta. Jedan zarez na krivom mjestu i ostat ćete vani:

sudo sshd -t
sudo sshd -T | grep -E 'permitrootlogin|passwordauth|kexalgorithms|ciphers|macs'
sudo systemctl reload ssh

Izbor KEX algoritama, šifri i MAC-ova

Redoslijed u KexAlgorithms direktivi je važan. OpenSSH bira prvi algoritam koji podržavaju i klijent i server. Stavite ML-KEM na prvo mjesto, sntrup kao drugi izbor, a klasične X25519 varijante isključivo kao fallback za starije klijente koje još niste nadogradili. SSH Audit hardening vodiči daju iste prioritete za sve glavne distribucije.

Za šifre, prioritet imaju AEAD modovi (Authenticated Encryption with Associated Data). chacha20-poly1305 i aes256-gcm obavljaju i šifriranje i autentifikaciju u jednom prolazu, što čini cijelu klasu napada na malleability nemogućim. CBC modovi su odavno deprecated; ako ih i dalje vidite u izlazu sshd -T, vaš drop-in nije primijenjen. AES-256 ima dodatnu otpornost na Groverov kvantni algoritam (efektivno 128-bitni nivo sigurnosti), pa ga preferirajte ispred AES-128 u dugoročnoj infrastrukturi.

MAC algoritmi se računaju samo kada šifra nije AEAD. Pri korištenju chacha20-poly1305 MAC se ignorira, ali ostavite ETM (Encrypt-then-MAC) varijante za slučaj fallback šifri. hmac-sha2-512-etm ima prednost u kvantnom okruženju jer Groverov napad smanjuje efektivnu sigurnost hash-a na pola njegove bit-dužine. Izbjegavajte sve što nije iz porodice SHA-2 ETM: hmac-md5, hmac-sha1, umac-64 i ne-ETM varijante imaju poznate ili teorijske probleme.

Ed25519, FIDO2 i SSH certifikati

Ed25519 je pravi izbor za korisničke i host ključeve u 2026. Brži je od RSA-4096, javni dio stane u jedan red, a fiksna duljina znači da nema rizika od pogrešnog odabira parametara koji prati ECDSA i RSA. Generirajte par naredbom ssh-keygen -t ed25519 -C "korisnik@host" i dodajte -a 100 ako želite jači KDF (više rundi za enkripciju privatnog ključa).

Za sve interaktivne korisnike u produkciji preporučuje se FIDO2 hardverski token (YubiKey 5, Token2, OnlyKey). Privatni ključ nikada nije na disku, već u sigurnom elementu tokena, što potpis zahtijeva fizički dodir korisnika:

# FIDO2 Ed25519 (zahtijeva OpenSSH >= 8.2 i token)
ssh-keygen -t ed25519-sk -O resident -O verify-required \
  -C "yubikey-resident-$(hostname)"

# Kopiraj javni dio na server
ssh-copy-id -i ~/.ssh/id_ed25519_sk.pub [email protected]

Za automatizaciju (CI/CD agenti, Ansible kontroleri, deploy boxevi) koristite SSH certifikate umjesto trajnih ključeva. Certifikat ima TTL koji se mjeri u minutama, automatski istječe i ne zahtijeva centralno čišćenje authorized_keys datoteka. Smallstep dokumentacija o SSH certifikatima dobro prikazuje arhitekturu CA + agent + short-lived cert. Za rate-limiting konekcija prema certifikatskim CA infrastruktrama na razini paketa kombinirajte ovo s pravilima opisanim u našem vodiču nftables vatrozid za Linux.

Fail2ban i nftables: rate-limiting i banovi

Niti jedan SSH server koji visi na javnom IP-u ne smije biti samo iza sshd_config-a. Botneti skeniraju IPv4 prostor i pokušavaju brute-force unutar prve četiri minute aktivnog servera (mjerio sam to na čistom honeypotu, stvarno toliko traje). Tri sloja čine razumnu obranu: paketni vatrozid (nftables) ograničava broj novih konekcija po izvoru, Fail2ban prati log i banuje ponavljače, a sam sshd odbija slabe pokušaje autentifikacije.

# /etc/nftables.d/ssh-ratelimit.nft
table inet filter {
  set ssh_offenders { type ipv4_addr; flags timeout; timeout 1h; }
  chain input {
    type filter hook input priority filter; policy drop;
    ct state established,related accept
    iif lo accept
    tcp dport 22 ip saddr @ssh_offenders drop
    tcp dport 22 ct state new limit rate 4/minute burst 8 packets accept
    tcp dport 22 ct state new add @ssh_offenders { ip saddr timeout 1h }
  }
}

Fail2ban od verzije 1.0 koristi systemd backend, pa nije potrebno pisati custom logpath ako su logovi u journalu. Minimalni otvrđeni jail:

# /etc/fail2ban/jail.d/sshd.local
[sshd]
enabled = true
backend = systemd
filter = sshd
mode = aggressive
maxretry = 3
findtime = 10m
bantime = 1h
bantime.increment = true
bantime.factor = 2
bantime.maxtime = 1w
banaction = nftables-multiport

Eskalirajući ban (bantime.increment) udvostručuje vrijeme bana svaki put kad se isti IP vrati: prvi put 1h, drugi 2h, peti 32h, do tjedan dana. Aktivirajte i provjerite:

sudo fail2ban-client reload
sudo fail2ban-client status sshd
# Provjera trenutno banovanih u nftables setu:
sudo nft list set inet filter ssh_offenders

Za fleet od više od 50 strojeva razmotrite CrowdSec ili centralni Wazuh menadžer umjesto per-host Fail2bana. IP koji napadne jedan server odmah se banuje na svima, što je ogromna razlika kad krene koordiniran skener. Za detekciju anomalija na razini kernela, pogledajte i naš pregled eBPF-a kao sigurnosne platforme.

Match blokovi, bastion hostovi i 2FA

Za realistične produkcijske topologije rijetko želite isti SSH policy za sve. Match blokovi omogućuju različita pravila ovisno o korisniku, grupi, IP-u ili adresi:

# Bastion host: dozvoli samo ProxyJump prema unutarnjoj mreži
Match User jumpuser
  AllowTcpForwarding yes
  PermitTunnel no
  ForceCommand /usr/bin/false
  GatewayPorts no
  X11Forwarding no

# Backup servisni račun samo iz internih CIDR-ova
Match User backup Address 10.0.0.0/8,192.168.0.0/16
  AuthenticationMethods publickey
  PermitTTY no
  ForceCommand /usr/local/bin/restic-backup

Za interaktivne ljudske korisnike kombinacija publickey + TOTP dvostruke autentifikacije zadovoljava većinu compliance kontrola. Instalirajte libpam-google-authenticator, zatim u /etc/pam.d/sshd dodajte auth required pam_google_authenticator.so, a u sshd config:

Match Group admins
  AuthenticationMethods publickey,keyboard-interactive:pam

Bastion (jump) host arhitektura dodatno smanjuje izloženost, jer samo bastion ima port 22 javno, a svi ostali serveri prihvaćaju SSH isključivo s bastion IP-a. Klijenti se spajaju kroz njega s ssh -J bastion target ili sa stalnim ~/.ssh/config blokom ProxyJump bastion. Ako vam je infrastruktura kontejnerizirana, izbjegavajte SSH unutar kontejnera. Preporučeni obrazac je kubectl exec ili docker exec, što je detaljno razmatrano u vodiču o sigurnosti Linux kontejnera.

Audit, logiranje i ssh-audit

Otvrdnjavanje bez verifikacije je placebo. Tri obavezna alata u svakom produkcijskom okruženju:

1. ssh-audit, koji automatski testira algoritme, šifre, MAC-ove i poznate ranjivosti vašeg servera:

   pip install --user ssh-audit
   ssh-audit -t 5 server.example.com
   # Ili Docker varijanta:
   docker run --rm positronsecurity/ssh-audit server.example.com

   Izlaz pokazuje (fail) oznake na slabim algoritmima i preporuke za uklanjanje. Spremite output u CI da regress test ne propusti slučajno vraćanje slabog ciphera.
2. auditd pravila, koja prate svaki pokušaj prijave, izmjenu authorized_keys i pokretanje sudo komandi:

   # /etc/audit/rules.d/ssh.rules
   -w /etc/ssh/sshd_config -p wa -k sshd-config
   -w /etc/ssh/sshd_config.d/ -p wa -k sshd-config
   -w /home -p wa -k user-home
   -a always,exit -F arch=b64 -S execve -F path=/usr/sbin/sshd -k sshd-exec

3. Journald + SIEM: LogLevel VERBOSE u sshd_config snima otisak ključa s kojim se korisnik prijavio. Forwardajte journalctl -u ssh -f u Loki, Wazuh ili Elastic, i postavite alarm na pojavu Accepted publickey izvan poslovnih sati.

Za CIS compliance verifikaciju koristite lynis audit system ili OpenSCAP sa scap-security-guide profilom. Oba automatski provjere većinu kontrola iz CIS Distribution Independent Linux Benchmarka. Pokrenite ih tjedno u CI i blokirajte deployment ako ocjena padne ispod 85%.

Često postavljana pitanja

Trebam li promijeniti SSH port s 22 na nešto drugo?

Ne kao primarna mjera sigurnosti. Promjena porta (security through obscurity) smanjuje šum u logovima, ali ne zaustavlja determiniranog napadača koji skenira sve portove. Ako mijenjate, kombinirajte to s AllowUsers i Fail2banom; sam non-default port nije obrana.

Je li sntrup761x25519 i dalje siguran kada postoji ML-KEM?

Da. Sntrup761 nije NIST-standardiziran ali nije ni probijen, a OpenSSH ga zadržava radi kompatibilnosti. ML-KEM (FIPS 203) ima prednost jer je formalno standardiziran i zahtijevan za američke savezne sustave. Hibridni dizajn znači da ćete biti zaštićeni i ako se jedan kasnije pokaže slabim, pa stavite oba algoritma u KexAlgorithms red.

Kako zaštititi SSH na poslužitelju ako klijenti rade na starom OpenSSH-u bez PQC podrške?

Ostavite klasične curve25519-sha256 varijante kao fallback na kraju KexAlgorithms liste i nadogradite klijente prema rasporedu. Dotad fokusirajte otvrdnjavanje na ono što djeluje na svim verzijama: onemogućivanje lozinki, Ed25519 ključeve, MaxAuthTries 3, Fail2ban i nftables rate-limit.

Zašto Fail2ban ne banuje IP-ove kod mene?

Najčešća tri uzroka: pogrešan logpath (na sustavima sa journalom koristite backend = systemd), port u jailu koji ne odgovara stvarnom SSH portu, i nedostatak banaction kompatibilnog s vašim vatrozidom. Pokrenite sudo fail2ban-client status sshd i pogledajte sudo journalctl -u fail2ban -n 100 za stvarne greške.

Trebam li onemogućiti SSH agent forwarding?

Onemogućite ga (AllowAgentForwarding no) na svakom serveru koji nije jump host. Agent forwarding znači da kompromitirani server može koristiti vaš lokalni agent za skok dalje, što efektivno povećava radius proboja. Na bastionu ga ostavite uključenim, ali kombinirajte s IdentitiesOnly yes i kratkim TTL-om certifikata.