Az SSH-szerver biztonságos beállítása

Modul 2: SSH és kulcsok · Olvasási idő: 12 perc

Tanulási cél: A lecke után Ön képes kikapcsolni a jelszavas bejelentkezést és a jelszavas root-bejelentkezést, ellenőrizni, melyik beállítás érvényes valójában, és mindezt úgy elvégezni, hogy ne zárja ki magát a szerverről.

Kulcsfogalmak: sshd, sshd_config, sshd_config.d, az első érték számít, PasswordAuthentication, KbdInteractiveAuthentication, PermitRootLogin, AuthenticationMethods, AllowUsers, sshd -t, sshd -T, második munkamenet, cloud-init, ssh.socket

Először a biztonsági háló

Ez a lecke lezár valamit, amin Önnek is át kell jutnia. Egy elírás azt jelentheti, hogy többé nem tud belépni. Ezért mindig, mielőtt hozzákezd:

1. Két kulcs működik (2.1. lecke), és egy új ablakban ellenőrizte, hogy a kulcsos bejelentkezés sikerül.
2. Pillanatkép (snapshot) készült a VPS-éről. A WebOké-nál ezt a VPS-képernyőn készítheti el, más szolgáltatóknál is snapshotnak vagy image-nek hívják. Ha valami félresikerül, visszaállítja.
3. A szolgáltató konzolját ismeri: ott SSH nélkül is be tud lépni.
4. A jelenlegi SSH-munkamenete nyitva marad a végéig. Egy futó munkamenet akkor is működik tovább, ha módosítja a beállításokat vagy újratölti a szolgáltatást. Minden módosítást egy második ablakban tesztel.

Hol vannak a beállítások

Az SSH-szerver neve sshd. A beállításai a /etc/ssh/sshd_config fájlban vannak. Debian és Ubuntu rendszeren a fájl tetején ez a sor áll:

Include /etc/ssh/sshd_config.d/*.conf

A .conf végződésű fájlokat a sshd_config.d mappában tehát a főfájl többi része előtt olvassa be, ábécésorrendben. Ez hasznos: a saját beállításait egy saját fájlba teszi, a főfájlt pedig érintetlenül hagyja, így a csomag frissítése nem írja felül a módosításait.

Ennek azonban van egy következménye, amely sokakat meglep. Az sshd_config esetében érvényes: minden beállításnál az az első érték számít, amellyel az sshd találkozik. Az ugyanazt a beállítást tartalmazó későbbi sorokat figyelmen kívül hagyja. Aki az sshd_config aljára beírja, hogy PasswordAuthentication no, az tehát nem győz egy olyan fájllal szemben a sshd_config.d mappában, amely azt mondja: yes.

A cloud-init csapdája

Sok VPS-image-et az első indításkor a cloud-init állít be. Attól függően, hogyan van beállítva az image és a telepítés, a cloud-init létrehozhat egy olyan fájlt, mint a /etc/ssh/sshd_config.d/50-cloud-init.conf, benne például ezzel:

PasswordAuthentication yes

Mivel ezt a fájlt a főfájl előtt olvassa be, a jelszavas bejelentkezés bekapcsolva marad, bármit ír is az sshd_config fájlba. Ne feltételezze tehát, hanem nézze meg:

root@web1:~# grep -ri passwordauthentication /etc/ssh/sshd_config /etc/ssh/sshd_config.d/
/etc/ssh/sshd_config:#PasswordAuthentication yes
/etc/ssh/sshd_config.d/50-cloud-init.conf:PasswordAuthentication yes

Két tiszta megoldás van: módosítsa ezt a fájlt no értékre, vagy tegye a saját beállításait egy olyan fájlba, amely ábécésorrendben korábban következik, például 00-beveiliging.conf. Egy 99-mijn.conf nevű fájl éppen hogy nem működik, mert akkor a cloud-init már nyert.

A fontos beállítások

Hozza létre a saját fájlját:

root@web1:~# nano /etc/ssh/sshd_config.d/00-beveiliging.conf

ezzel a tartalommal:

# Bejelentkezés csak kulccsal
PasswordAuthentication no
KbdInteractiveAuthentication no
PermitRootLogin prohibit-password

Mit jelent az egyes sor?

• PasswordAuthentication no: a szerver többé nem fogad el jelszót. Az OpenSSH alapértéke yes.
• KbdInteractiveAuthentication no: a "keyboard-interactive" egy második módja annak, hogy a szerver jelszót kérjen, a PAM-on keresztül. Ha ezt bekapcsolva hagyja, valaki mégis megpróbálhat jelszót megadni, akkor is, ha a PasswordAuthentication értéke no. Régebbi leírásokban ennek a beállításnak ChallengeResponseAuthentication a neve; az OpenSSH 8.7 óta ez ugyanannak a dolognak egy elavult másik neve. A Debian alapértelmezetten már no értékre állítja, de azért írja be: így egyértelmű, és más rendszereken is helyes lesz.
• PermitRootLogin prohibit-password: a root bejelentkezhet, de csak kulccsal. Az OpenSSH 7.0 óta ez az alapértelmezés. Szigorúbb a PermitRootLogin no: a root egyáltalán nem léphet be SSH-n keresztül, Ön hétköznapi felhasználóként jelentkezik be, és sudót használ (3.2. lecke). A no értéket csak akkor állítsa be, ha biztos benne, hogy a bejelentkezés ezzel a felhasználóval és a sudo működik.

Opcionálisan, azoknak, akik többet szeretnének:

AllowUsers anna
AuthenticationMethods publickey

Az AllowUsers csak a felsorolt felhasználókat engedi be; minden más nevet elutasít, akkor is, ha érvényes kulcsa van. Hasznos, de ne felejtse ki saját magát, és ne felejtse el kiegészíteni, ha egy második rendszergazdát vesz fel. Az AuthenticationMethods publickey egyetlen sorban kimondja, hogy csak a kulcsok érvényesek.

Tesztelés, alkalmazás, ellenőrzés

Először az sshd-vel ellenőrizteti a fájlt. Ez semmit nem indít el és semmit nem változtat:

root@web1:~# sshd -t
root@web1:~#

Ha nincs kimenet, az azt jelenti: nincs hiba. Elírás esetén látja a sort és a fájlt. Csak ezután töltse újra a szolgáltatást:

root@web1:~# systemctl reload ssh

Debian és Ubuntu rendszeren a szolgáltatás neve ssh, AlmaLinux és Rocky Linux rendszeren sshd.

Ezután ellenőrizze, melyik érték érvényes valójában. A sshd -T a teljes, kiértékelt konfigurációt mutatja, az összes Include-fájl feldolgozása után:

root@web1:~# sshd -T | grep -Ei 'passwordauth|kbdinteractive|permitrootlogin'
permitrootlogin without-password
passwordauthentication no
kbdinteractiveauthentication no

(A without-password a prohibit-password régi neve. Az OpenSSH 10.1 előtti verziói, például a Debian 13 és az Ubuntu 24.04 rendszeren, még a régi nevet mutatják; az újabbak prohibit-password nevet. A jelentésük ugyanaz.)

És most a legfontosabb: teszteljen egy második ablakban, miközben az első nyitva marad.

anna@laptop:~$ ssh anna@192.0.2.10
anna@web1:~$

Ha ez működik, próbáljon meg szándékosan jelszóval bejelentkezni. Ennek sikertelennek kell lennie:

anna@laptop:~$ ssh -o PreferredAuthentications=password -o PubkeyAuthentication=no anna@192.0.2.10
anna@192.0.2.10: Permission denied (publickey).

A Permission denied után zárójelben az áll, milyen bejelentkezési módokat kínál még a szerver. Ha ott csak publickey szerepel, akkor rendben van. Ha password vagy keyboard-interactive is ott áll, akkor valahol még egy másik érték érvényes: nézze meg újra a sshd -T paranccsal.

Pontosan ezt a listát ellenőrzi kívülről a tanfolyami feladat is. Az SSH-kliense minden kapcsolatnál először megkérdezi, mely módok engedélyezettek, egy "none" típusú kéréssel. A szerver a listával válaszol, anélkül hogy jelszót vagy kulcsot próbálna ki bárki.

Ubuntu 24.04 és újabb: ssh.socket

Az Ubuntu 22.10 óta nem maga az sshd figyel a 22-es porton, hanem a systemd, az ssh.socket segítségével. A systemd csak akkor indítja el az SSH-szolgáltatást, amikor kapcsolat érkezik. A lecke beállításai szempontjából ez nem számít: a systemctl reload ssh vagy a restart ssh elegendő.

Akkor viszont számít, ha a portot vagy a figyelési címet módosítja (Port, ListenAddress). Az Ubuntu 24.04 óta a systemd ezeket az értékeket az sshd_config fájlból olvassa, de csak ez után:

root@web1:~# systemctl daemon-reload
root@web1:~# systemctl restart ssh.socket

Ha ezt elfelejti, a szerver egyszerűen tovább figyel a régi porton. Ami rosszabb: ha előbb a tűzfalat állítja át egy új portra, az SSH pedig a régin marad, akkor kizárja magát. Mindig ellenőrizze a ss -tlnp | grep ssh paranccsal, hol folyik valójában a figyelés (5.1. lecke), és az új portot még azelőtt nyissa meg a tűzfalon, hogy a régit lezárná. Hogy van-e értelme másik portnak, azt a 2.3. leckében olvashatja.

Ha mégis baj történik

Ha nem tud belépni, nyissa meg a szolgáltató konzolját, jelentkezzen be rootként (jelszóval, mert a konzol egy "billentyűzet a szerveren", nem SSH), és állítsa vissza a fájlját:

root@web1:~# mv /etc/ssh/sshd_config.d/00-beveiliging.conf /root/
root@web1:~# systemctl reload ssh

Ha ez sem sikerül, állítsa vissza a pillanatképet. A WebOké-nál a VPS-képernyőn új root-jelszót is beállíthat; más szolgáltatóknál gyakran van hasonló gomb vagy mentési mód (rescue).

AlmaLinux és Rocky Linux rendszeren

A szolgáltatás neve sshd (systemctl reload sshd). Ott is egy Include /etc/ssh/sshd_config.d/*.conf áll a fájl tetején, és a rendszer saját fájlokat is szállít abba a mappába; ugyanaz az "első érték számít" szabály érvényes. Ha a portot módosítja, akkor a SELinuxnak is engedélyeznie kell azt a portot (semanage port -a -t ssh_port_t -p tcp 2222), a firewalldnek pedig meg kell nyitnia.

Összefoglalás

• Az sshd_config esetében az első érték számít; a sshd_config.d mappában lévő fájlokat olvassa be először. A saját beállításait tegye egy olyan fájlba, mint a 00-beveiliging.conf.
• Állítsa be a PasswordAuthentication no és a KbdInteractiveAuthentication no értéket is; a root csak kulccsal (prohibit-password) vagy egyáltalán ne lépjen be (no).
• Ellenőrizzen a sshd -t paranccsal az újratöltés előtt, és a sshd -T paranccsal azt, melyik érték érvényes valójában; figyeljen egy esetleges 50-cloud-init.conf fájlra.
• Teszteljen egy második ablakban, és tartsa nyitva az első munkamenetet. Ismerje a konzolt, és készítsen előre pillanatképet.
• Ubuntu 24.04+ rendszeren egy másik porthoz systemctl daemon-reload és systemctl restart ssh.socket szükséges.

Kvíz

Feladat

Z2.2. feladat: A jelszavas bejelentkezés ki van kapcsolva. Kapcsolja ki a jelszavas bejelentkezést és a keyboard-interactive módot a leckében leírtak szerint, majd nézesse meg a programmal kívülről. Adja meg a szervere IP-címét vagy hosztnevét, az SSH-portot (alapértelmezés: 22) és azt a felhasználónevet, amellyel Ön bejelentkezik (például anna, nem root és nem kitalált név). A program nem jelentkezik be: csak megkérdezi, ahogy minden SSH-kliens a bejelentkezés előtt, milyen bejelentkezési módokat kínál a szervere az adott felhasználónak. A helyes eredmény: csak publickey.

További olvasnivaló

A cikkekben leírt lépések a WebOké VPS-képernyőjére vonatkoznak; más szolgáltatóknál hasonlóan működik.

• A VPS biztonságossá tétele: az első öt perc
• Nem fér hozzá a VPS-éhez: mi a teendő?
• A VPS snapshotjai és biztonsági mentései
• Az sshd_config kézikönyve: https://man.openbsd.org/sshd_config
• Ubuntu: SSHd now uses socket-based activation: https://discourse.ubuntu.com/t/sshd-now-uses-socket-based-activation-ubuntu-22-10-and-later/30189