Autentifikacija lozinkom preko SSH-a najveća je izložena površina koju običan server ima. Protiv nje ne pomažu ni Fail2ban ni bilo kakav prag: hiljadu adresa sa jednim pokušajem na sat nikada neće dostići ograničenje i nastaviće da pogađaju tačno onoliko dugo koliko je pogađanje uopšte moguće. Ključevi uklanjaju samu mogućnost, i od cele liste otvrdnjavanja ovo je jedino podešavanje koje kvalitativno menja situaciju.

Samo je jedna stvar u vezi s tim zastrašujuća: isključiti lozinku i ostati napolju. Evo redosleda pri kojem se to ne može desiti.

Ključ

Generiše se na vašoj mašini, ne na serveru:

ssh-keygen -t ed25519 -C "work laptop"

ed25519 umesto RSA: kraći, brži i bez pitanja o dužini. RSA je potreban samo ako morate da dosegnete nešto vrlo staro; tada -t rsa -b 4096.

Lozinku na ključu vredi postaviti: fajl ključa može biti ukraden sa laptopa, a bez lozinke radi odmah. Nećete morati da je kucate svaki put — to obavlja ssh-agent, a na macOS-u i većini stonih Linux sistema on već radi.

Kopiranje na server je jedna komanda, dok lozinka još radi:

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

Ako ssh-copy-id nije dostupan, sadržaj .pub fajla dodaje se kao red u ~/.ssh/authorized_keys na serveru. Dozvole su bitne: direktorijum .ssh 700, fajl 600, vlasnik korisnik. Sa bilo čim drugim sshd tiho odbija da pročita fajl, i to je najčešći uzrok priče „ključ ne radi".

Provera koja to rešava

Pre nego što bilo šta isključite, otvorite drugu vezu ne zatvarajući prvu:

ssh -o PasswordAuthentication=no user@203.0.113.25

Opcija zabranjuje klijentu da se vrati na lozinku — dakle ako je prijava uspela, uspela je ključem. Dok ta komanda ne proradi, ne idite dalje. I držite prvu vezu otvorenom do samog kraja: ona je ta koja popravlja sve što uspete da pokvarite.

Isključivanje lozinki i jedna neočigledna prepreka

Podešavanja idu u zaseban fajl da ih ažuriranje paketa ne bi prepisalo. Ali naziv fajla je bitan:

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

Stvar je u tome što OpenSSH koristi prvu vrednost koju pronađe za parametar, a ne poslednju kao gotovo svuda drugde. Fajlovi u sshd_config.d čitaju se abecedno, a Ubuntu slike iz oblaka tamo stavljaju 50-cloud-init.conf, koji često sadrži PasswordAuthentication yes. Vaš fajl sa brojem 90 u toj situaciji neće uraditi ništa: podešavanje izgleda kao da je na mestu dok lozinka nastavlja da radi. Otuda broj 10 — čita se ranije.

Šta je zaista ispalo možete videti bez nagađanja:

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

Ta komanda ispisuje efektivnu konfiguraciju posle svih uključivanja. Verujte njoj, a ne sadržaju fajlova.

Zatim provera sintakse i nežno ponovno učitavanje servisa:

sudo sshd -t && sudo systemctl reload ssh

sshd -t je obavezno: greška u kucanju u konfiguraciji uz restart ostavlja servis oboren a vas napolju. reload takođe ne prekida otvorene sesije.

Ubuntu 24.04: port nije tamo gde mislite

Zasebna zamka na skorašnjem Ubuntuu: sshd se tamo pokreće preko systemd socket-a. U tom režimu red Port u sshd_config ne radi ništa — osluškuje socket, a ne demon. Ako menjate port, to je ono što treba izmeniti:

sudo systemctl edit ssh.socket

a ListenStream= (prazna vrednost poništava prethodnu) mora navesti novi port. Simptom koji to odaje: konfiguracija je promenjena, servis ponovo pokrenut, a server i dalje odgovara na 22.

Kad smo već kod menjanja porta: kao zaštita ne radi — skeneri pronalaze servis na bilo kom portu za nekoliko minuta. Jedini efekat su tiši dnevnici, jer masovno pogađanje ide samo na 22. To je zgodno, ali nemojte to mešati sa bezbednošću.

Ko uopšte sme da se prijavi

Korisan dodatak je izričita lista:

AllowUsers deploy admin

Sve što nije na listi preseca se pre nego što se ključ uopšte proveri. To pokriva i slučaj kada neki paket kreira sistemskog korisnika sa ljuskom i početnim direktorijumom.

Rezervni put unutra

Jedan ključ na jednom laptopu jedinstvena je tačka otkaza. Disk umre, laptop se izgubi i server postaje nedostupan zauvek. Razuman minimum:

  • drugi ključ sa drugog uređaja u authorized_keys;
  • kopija privatnog ključa u menadžeru lozinki ili na šifrovanom USB-u;
  • testiran pristup konzoli kod provajdera — VNC ili serijski. Testiran znači da ste se preko njega prijavili bar jednom, a ne da „negde u panelu postoji dugme".

Kad ste već tu, pogledajte šta se već nalazi u authorized_keys — i vašeg korisnika i root-a. Tuđi ključ tamo preživljava svaku promenu lozinke i ostaje radni pristup.

Posle toga

Pogađanje lozinki neće nestati, samo postaje beskorisno: dnevnici će i dalje skupljati hiljade redova Failed password, od kojih nijedan ne može da se završi uspehom. Ono što sada vredi pratiti jesu uspešne prijave: sa koje adrese, pod kojim korisnikom, u koje vreme. Uspešna prijava ključem sa nepoznate adrese daleko je važniji događaj od milion neuspeha, i mnogo teže se primeti u opštem toku. Upravo tu sliku prikazuje demo stranica ispod.