# Ismeretlen SSH-kulcsok keresése és eltávolítása

> authorized_keys ellenőrzése: hol vannak az SSH-kulcsok a szerveren, hogyan ismeri fel az idegen bejegyzéseket, távolítja el biztonságosan, és erősíti meg az SSH-t.

Forrás: https://phpsos.de/hu/blog/ssh-schluessel-pruefen/  
Állapot: 2026. 10. 25.  
Szolgáltató: PHP SOS, PHP-vészhelyzeti segítség és szerverbiztonság. Azonnali segítség WhatsAppon: https://wa.me/491736494914?text=%C3%9Cdv%C3%B6zl%C3%B6m%2C%20PHP%20SOS%21%20Seg%C3%ADts%C3%A9gre%20van%20sz%C3%BCks%C3%A9g%C3%BCnk%20a%20PHP-szerver%C3%BCnkkel.%20C%C3%A9g%3A%20%E2%80%A6%20Weboldal%3A%20%E2%80%A6

**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?](https://phpsos.de/hu/php2shell/bin-ich-gehackt-anzeichen/) 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:

```bash
# 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:

```bash
# 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:

1. **Minden kulcs egy ismert személyhez vagy ismert szolgáltatáshoz tartozik?** Az ujjlenyomatokat vesse össze, ne csak a megjegyzést.
2. **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.
3. **Á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.
4. **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.
5. **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](https://phpsos.de/hu/blog/cronjobs-als-hintertuer/) és az [idegen admin-fiókokat](https://phpsos.de/hu/blog/fremde-admin-konten-finden/) is. Ha a támadó root jogosultságot szerzett, a szerver újjáépítése gyakran megbízhatóbb a tisztításnál.

> **Fontos:**
> 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](https://phpsos.de/hu/leistungen/server-haertung/) 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.

## Források

- [BSI: tudnivalók informatikai biztonsági incidensekről](https://www.bsi.bund.de/)
- [php.net: biztonsági közlemények](https://www.php.net/)
- [CIS Benchmarks](https://www.cisecurity.org/cis-benchmarks)