Röviden: Az ismeretlen SSH-kulcsok megtalálásához a szerver összes authorized_keys fájlját ellenőriznie kell, nem csak a rootét. Az sshd -T paranccsal tudja meg, mely fájlokat olvassa az SSH-szolgáltatása, sorolja fel minden kulcs ujjlenyomatát, és vesse össze az ismert kulcsokkal. Az idegen bejegyzéseket először mentse, azután távolítsa el, majd erősítse meg a hozzáférést.
A kulcs, amely túléli az összes jelszócserét
Egy incidens után sok üzemeltető először az összes jelszót megváltoztatja. A legfeltűnésmentesebb hátsó kapuk egyike ellen ez nem segít: egy további nyilvános kulcs ellen egy authorized_keys fájlban. Aki birtokolja a hozzá illő privát kulcsot, jelszó nélkül jelentkezik be, mindaddig, amíg valaki meg nem találja a sort.
Az ismeretlen SSH-kulcsok ezért azok közé a jelek közé tartoznak, amelyeket kódvégrehajtás után mindig ellenőrizni kell. A PHP2Shellre nincsenek közzétett, megerősített Indicators of Compromise; a felismerés viselkedéselemzésen alapul. Egy idegen kulcs nem sajátosan PHP2Shell-bizonyíték, de egyértelmű jele annak, hogy valaki tartós hozzáférést akart. További jeleket ír le a Megfertőzték már a rendszeremet? oldal.
Hol vannak az SSH-kulcsok a szerveren
Az OpenSSH a dokumentáció szerint alapértelmezetten két fájlt olvas be minden felhasználó home-könyvtárából: a .ssh/authorized_keys és a .ssh/authorized_keys2 fájlt. A másodikat gyakran elfelejtik. A beállítás módosítható, és az AuthorizedKeysCommand segítségével a szerver a kulcsokat akár külső programból is beszerezheti. Ezért először ellenőrizze, mi érvényes ténylegesen a szerverén:
# A tényleges SSH-konfiguráció kiírása (csak olvasva)
sudo sshd -T | grep -iE '^(authorizedkeysfile|authorizedkeyscommand|permitrootlogin|passwordauthentication|pubkeyauthentication)'
# További konfigurációs fájlok és Match-blokkok
ls -la /etc/ssh/sshd_config.d/ 2>/dev/null
sudo grep -rn -iE '^\s*(Match|AuthorizedKeys)' /etc/ssh/
Különleges hely a webszerver-felhasználó home-könyvtára. Debianon és Ubuntun ez a www-data esetén gyakran a /var/www. Ha ez a könyvtár a PHP számára írható, a beszúrt kód ott létrehozhat egy .ssh/authorized_keys fájlt. Hogy a bejelentkezés ilyenkor sikerül-e, az a bejelentkezési shelltől és az SSH-beállításoktól függ, de maga a fájl már riasztójel.
Nem minden ismeretlen bejegyzés rosszindulatú. A telepítési eszközök, a mentési szolgáltatások vagy a korábbi szolgáltatók saját kulcsokat helyeznek el. Az ilyen bejegyzéseknek azonban ismert tulajdonosa és célja kell, hogy legyen.
authorized_keys ellenőrzése lépésről lépésre
A következő parancsok nem változtatnak semmit. Kilistázzák a felhasználók összes kulcsfájlját, és minden kulcshoz megmutatják az ujjlenyomatot:
# Az összes authorized_keys fájl az összes felhasználó home-könyvtárában
getent passwd | cut -d: -f1,6 | while IFS=: read -r user home; do
for f in "$home/.ssh/authorized_keys" "$home/.ssh/authorized_keys2"; do
[ -f "$f" ] && echo "== $user: $f" && sudo ls -la --time-style=full-iso "$f"
done
done
# Egy fájl ujjlenyomatainak és megjegyzéseinek megjelenítése
sudo ssh-keygen -lf /root/.ssh/authorized_keys
# További kulcsfájlok a szokásos helyeken kívül
sudo find / -xdev -name 'authorized_keys*' 2>/dev/null
Az eredményt ezzel az ellenőrzőlistával vegye végig:
- Minden kulcs egy ismert személyhez vagy ismert szolgáltatáshoz tartozik? Az ujjlenyomatokat vesse össze, ne csak a megjegyzést.
- Van olyan felhasználónak kulcsa, akinek egyáltalán nem szabadna lennie? Például a webszerver-felhasználónak, az adatbázis- vagy a szolgáltatásfiókoknak.
- Állnak-e opciók a kulcs előtt? A
command=bejegyzések minden bejelentkezéskor egy rögzített parancsot hajtanak végre. Ez mentéseknél jogos, de búvóhely is. - Mikor módosították utoljára a fájlt? A 2026. október 17. utáni módosítási dátum, a sajtóbeszámolók szerint az első megfigyelt PHP2Shell-támadási kísérlet napja, különös figyelmet érdemel. Az időbélyegek azonban hamisíthatók.
- Stimmel a tulajdonos és a jogosultság? Az a fájl, amely más felhasználóé, mint a home-könyvtár, feltűnő.
Az idegen kulcsok biztonságos eltávolítása
Mielőtt töröl egy sort, mentse a fájlt időbélyeggel és ellenőrző összeggel a szerveren kívülre. Jegyezze fel az idegen kulcs ujjlenyomatát. Később segít annak a kérdésnek a megválaszolásában, hogy ugyanez a kulcs más szervereken is megjelenik-e, például egy sok ügyfélrendszert kezelő ügynökségnél.
Ellenőrizze a bejelentkezési naplókat is. Az /var/log/auth.log (Debian, Ubuntu) vagy az /var/log/secure (RHEL-család) fájlban az SSH-szolgáltatás naplózza a sikeres bejelentkezéseket a használt kulcs ujjlenyomatával. Így látja, használták-e már az idegen kulcsot, és melyik címről.
Gondoljon az ellenkező irányra is. Ha a szerveren privát kulcsok vannak, például az ~/.ssh/id_* alatt telepítésekhez vagy mentésekhez, a támadó lemásolhatta őket. Velük esetleg más szervereket, Git-repositorykat vagy mentési célokat ér el. Az ilyen kulcsok egy behatolás után felhasználtnak számítanak: hozzon létre újakat, és távolítsa el a régieket az összes célrendszeren.
Az idegen kulcs ritkán az egyetlen nyom. Aki elhelyezte, írási joggal rendelkezett, és esetleg további utakat is kialakított, például cron-feladatokat vagy további fiókokat. Ezért ellenőrizze a rejtett cron-feladatokat és az idegen admin-fiókokat is. Ha a támadó root jogosultságot szerzett, a szerver újjáépítése gyakran megbízhatóbb a tisztításnál.
Az idegen kulcsokat csak akkor távolítsa el, ha a PHP kijavított állapotban van (8.5.12, 8.4.27, 8.3.36, 8.2.35 vagy megerősített backport), és az összes workert újraindították. Különben a támadó ugyanazon a résen keresztül azonnal újra bejegyezheti a kulcsot.
Az SSH-hozzáférés megerősítése utána
A tisztítás után érdemes egy rövid megerősítés. A legtöbb pontot gyorsan meg lehet valósítani, de mindig egy második, nyitott munkamenettel kell tesztelni, hogy ne zárja ki magát.
| Intézkedés | Beállítás vagy eljárás |
|---|---|
| Bejelentkezés csak kulccsal | PasswordAuthentication no |
| A root közvetlen bejelentkezésének tiltása | PermitRootLogin no, munka személyes fiókokkal sudóval |
| A második kulcsfájl kikapcsolása | AuthorizedKeysFile .ssh/authorized_keys |
| A kulcsok korlátozása az eredetre | a from= opció a kulcs előtt, például mentési szerverekhez |
| A szolgáltatási kulcsok korlátozása | a restrict opció és rögzített command= az automatizáláshoz |
| Webszerver-felhasználó bejelentkezés nélkül | nologin bejelentkezési shell, nincs .ssh a home-könyvtárban |
Vezessen emellett listát az összes jogosult kulcsról tulajdonossal és céllal. Ha egy munkatárs vagy szolgáltató kilép, a kulcsát az összes szerverről eltávolítják. E lista nélkül a következő ellenőrzés ismét nyomozómunka. Az SSH-ra vonatkozó elismert megerősítési előírásokat a CIS Benchmarks is tartalmazza.
Hogyan segít konkrétan a PHP SOS?
- Megállapítjuk, mely kulcsfájlokat olvassa valójában az SSH-szolgáltatása, és minden bejegyzést összevetünk az ismert tulajdonosokkal.
- A leleteket mentjük, és kiértékeljük a bejelentkezési naplókat, hogy tisztázzuk, használták-e az idegen kulcsot.
- A kulcsokat, fiókokat és cron-feladatokat a helyes sorrendben tisztítjuk, és előtte lezárjuk a rést.
- A szerver megerősítése keretében megvalósítjuk az SSH-beállításokat, és kulcskezelést állítunk be tulajdonosi listával.
Gyakori kérdések
Honnan tudom, hogy egy SSH-kulcs idegen?
Minden kulcsnak van ujjlenyomata és többnyire egy megjegyzése a sor végén. Vesse össze az ujjlenyomatokat a munkatársai és a szolgáltatói kulcsaival. A megjegyzés önmagában nem bizonyít semmit, mert szabadon választható és hamisítható.
Segít a root jelszavát megváltoztatni?
Egy beszúrt kulcs ellen nem. A kulcsos bejelentkezéshez nem kell jelszó. Ezért magukat az authorized_keys fájlokat kell ellenőrizni és megtisztítani.
Miért lehet a webszerver-felhasználónak SSH-kulcsa?
A webszerver-felhasználónak saját home-könyvtára van, Debianon és Ubuntun gyakran /var/www. Ha ott van egy .ssh/authorized_keys, és a fióknak van bejelentkezési shellje, lehetséges a bejelentkezés ezzel a felhasználóval. Írható webkönyvtár esetén a beszúrt PHP-kód létrehozhat ilyen fájlt.
Mi az az authorized_keys2?
Egy régebbi második fájl, amelyet az OpenSSH az alapbeállítás szerint szintén beolvas. Sok ellenőrzési útmutató figyelmen kívül hagyja. Az sshd -T paranccsal ellenőrizze, mely fájlokat értékeli ki ténylegesen a szervere.