A jelszavas SSH-bejelentkezés egy szokásos szerver legnagyobb nyitott felülete. Ellene tehetetlen a Fail2ban és bármilyen küszöb is: ezer cím óránként egy próbálkozással sosem éri el a korlátot, és pontosan addig fognak próbálkozni, amíg a kitalálás egyáltalán lehetséges. A kulcsok magát a lehetőséget szüntetik meg, és ez az egyetlen beállítás az egész keményítési listából, amely minőségileg változtat a helyzeten.

Egyvalami ijesztő itt: kikapcsolni a jelszót, és kívül maradni. Alább az a sorrend, amellyel ez kizárt.

A kulcs

A saját gépeden generálódik, nem a szerveren:

ssh-keygen -t ed25519 -C "munkalaptop"

ed25519 az RSA helyett — rövidebb, gyorsabb, és nincsenek kérdések a hosszról. RSA csak akkor kell, ha valami nagyon régihez fogsz csatlakozni; olyankor -t rsa -b 4096.

Jelmondatot érdemes a kulcsra tenni: a kulcsfájlt ellophatják a laptopról, és jelmondat nélkül azonnal működik. Nem kell minden alkalommal beírni — erről az ssh-agent gondoskodik, macOS-en és a legtöbb asztali Linuxon pedig már fut is.

Másolás a szerverre egyetlen paranccsal, amíg a jelszó még működik:

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

Ha az ssh-copy-id nem érhető el, a .pub fájl tartalma sorként kerül a szerveren a ~/.ssh/authorized_keys fájlba. A jogosultságok fontosak: a .ssh könyvtár 700, a fájl 600, a tulajdonos maga a felhasználó. Más jogosultságok mellett az sshd némán megtagadja a fájl olvasását, és ez a leggyakoribb oka annak, hogy „a kulcs nem működik”.

Az ellenőrzés, amelyen minden múlik

Mielőtt bármit kikapcsolnál, nyiss egy második kapcsolatot anélkül, hogy az elsőt bezárnád:

ssh -o PasswordAuthentication=no user@203.0.113.25

A kapcsoló megtiltja a kliensnek a jelszóra való visszalépést — vagyis ha a bejelentkezés sikerült, akkor éppen kulccsal sikerült. Amíg ez a parancs le nem fut, a következő lépésre nem szabad áttérni. Az első kapcsolatot pedig a végéig nem zárjuk be: azon keresztül javítható minden, amit el lehet rontani.

A jelszó kikapcsolása és egy nem nyilvánvaló csapda

A beállításokat külön fájlba tesszük, hogy a csomagfrissítés ne írja felül őket. De a fájl neve számít:

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

A helyzet az, hogy az OpenSSH egy paraméter elsőként megtalált értékét használja, nem az utolsót, mint szinte mindenhol máshol. Az sshd_config.d fájljait ábécésorrendben olvassa, az Ubuntu felhőképei pedig 50-cloud-init.conf néven raknak oda fájlt, amelyben nemritkán PasswordAuthentication yes áll. A 90-es számú fájlod ilyenkor semmit nem tesz: a beállítás látszólag megvan, a jelszó viszont továbbra is működik. Innen a 10-es szám — azt olvassa be korábban.

Hogy végül mi lett az eredmény, azt nem kell találgatni:

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

Ez a parancs a minden beemelés utáni érvényes konfigurációt írja ki. Ennek higgy, ne a fájlok tartalmának.

Ezután szintaxisellenőrzés és a szolgáltatás lágy újratöltése:

sudo sshd -t && sudo systemctl reload ssh

Az sshd -t kötelező: egy elgépelés a konfigurációban restart esetén a szolgáltatást leállva, téged pedig kívül hagy. A reload ráadásul nem szakítja meg a nyitott munkameneteket.

Ubuntu 24.04: a portot nem ott kell módosítani

A friss Ubuntuk külön csapdája: az sshd ott systemd-socketen keresztül indul. A Port sor az sshd_config fájlban ebben az üzemmódban semmit nem tesz — a socket figyel, nem a démon. Ha portot cserélsz, azt kell módosítani:

sudo systemctl edit ssh.socket

és meg kell adni a ListenStream= értéket (üres érték nullázza az előzőt) az új porttal. A tünet, amelyről felismerhető: a konfiguráció módosítva, a szolgáltatás újraindítva, a szerver pedig továbbra is a 22-esen válaszol.

A portcseréről egyébként: védelemként nem működik — a szkennerek percek alatt megtalálják a szolgáltatást bármelyik porton. Egyetlen hatása, hogy a naplókban csend lesz, mert a tömeges találgatás csak a 22-esre megy. Ez kényelmes, de ne keverd össze a biztonsággal.

Ki jelentkezhet be egyáltalán

Hasznos kiegészítés egy kifejezett lista:

AllowUsers deploy admin

Minden, ami nincs felsorolva, még a kulcs ellenőrzése előtt elutasításra kerül. Ez egyúttal lefedi azt az esetet is, amikor valamelyik csomag shellel és saját könyvtárral rendelkező rendszerfelhasználót hoz létre.

Tartalék bejárat

Egy kulcs egyetlen laptopon egyetlen hibapont. A lemez meghal, a laptop elvész, és a szerver örökre elérhetetlenné válik. Ésszerű minimum:

  • egy második kulcs másik eszközről az authorized_keys fájlban;
  • a privát kulcs másolata jelszókezelőben vagy titkosított pendrive-on;
  • kipróbált konzolhozzáférés a szolgáltatónál — VNC vagy soros. A kipróbált azt jelenti, hogy legalább egyszer beléptél oda, nem azt, hogy „valahol a panelen van egy gomb”.

Egyúttal nézd meg, mi van már az authorized_keys fájlban — a saját felhasználódnál és a rootnál is. Egy idegen kulcs ott bármilyen jelszóváltást túlél, és működő hozzáférés marad.

Utána

A jelszókitalálás nem tűnik el, csak most már haszontalan: a naplókban több ezer Failed password sor marad, amelyek közül egy sem végződhet sikerrel. Mostantól viszont a sikeres bejelentkezéseket érdemes nézni: milyen címről, milyen felhasználóval, mikor. Egy sikeres kulcsos bejelentkezés ismeretlen címről sokkal fontosabb esemény, mint egymillió sikertelen próbálkozás, és az általános áramlatban sokkal nehezebb észrevenni. Pontosan ezt a képet mutatja az alábbi bemutatóoldal.