# Nežinomų SSH raktų radimas ir šalinimas

> authorized_keys patikra: kur serveryje saugomi SSH raktai, kaip atpažinti svetimus įrašus, saugiai juos pašalinti ir po to sutvirtinti SSH prieigą.

Šaltinis: https://phpsos.de/lt/blog/ssh-schluessel-pruefen/  
Būsena: 2026-10-25  
Teikėjas: PHP SOS, PHP avarinė pagalba ir serverio sauga. Skubi pagalba per „WhatsApp“: https://wa.me/491736494914?text=Sveiki%2C%20PHP%20SOS%2C%20mums%20reikia%20pagalbos%20su%20m%C5%ABs%C5%B3%20PHP%20serveriu.%20%C4%AEmon%C4%97%3A%20%E2%80%A6%20Svetain%C4%97%3A%20%E2%80%A6

**Trumpai:** norėdami rasti nežinomus SSH raktus, turite patikrinti visus authorized_keys failus serveryje, ne tik root. Su `sshd -T` nustatykite, kuriuos failus skaito jūsų SSH tarnyba, išvardykite kiekvieno rakto kontrolinius kodus ir palyginkite su žinomais raktais. Svetimus įrašus pirmiausia išsaugokite, tada pašalinkite ir po to sutvirtinkite prieigą.

## Raktas, išgyvenantis kiekvieną slaptažodžio keitimą

Po incidento daugelis operatorių pirmiausia pakeičia visus slaptažodžius. Nuo vienų nepastebimiausių užpakalinių durų tai nepadeda: papildomo viešojo rakto `authorized_keys` faile. Kas turi atitinkamą privatųjį raktą, prisijungia be slaptažodžio, tol, kol kas nors suras eilutę.

Todėl nežinomi SSH raktai priklauso požymiams, kuriuos po kodo vykdymo reikia tikrinti visada. PHP2Shell atveju paskelbtų, patvirtintų kompromitavimo indikatorių (Indicators of Compromise) nėra; aptikimas remiasi elgsenos analize. Svetimas raktas nėra specifinis PHP2Shell įrodymas, bet aiškus ženklas, kad kažkas norėjo ilgalaikės prieigos. Kitus požymius aprašo [Ar jau esu pažeistas?](https://phpsos.de/lt/php2shell/bin-ich-gehackt-anzeichen/).

## Kur serveryje saugomi SSH raktai

Pagal dokumentaciją OpenSSH pagal numatytuosius nustatymus skaito du failus kiekvieno naudotojo namų kataloge: `.ssh/authorized_keys` ir `.ssh/authorized_keys2`. Antrasis dažnai pamirštamas. Nustatymą galima pakeisti, o su `AuthorizedKeysCommand` serveris raktus gali gauti net iš išorinės programos. Todėl pirmiausia patikrinkite, kas jūsų serveryje iš tikrųjų galioja:

```bash
# Išvesti efektyvią SSH konfigūraciją (tik skaitymas)
sudo sshd -T | grep -iE '^(authorizedkeysfile|authorizedkeyscommand|permitrootlogin|passwordauthentication|pubkeyauthentication)'

# Papildomi konfigūracijos failai ir Match blokai
ls -la /etc/ssh/sshd_config.d/ 2>/dev/null
sudo grep -rn -iE '^\s*(Match|AuthorizedKeys)' /etc/ssh/
```

Ypatinga vieta yra žiniatinklio serverio naudotojo namų katalogas. Debian ir Ubuntu sistemose `www-data` tai dažnai yra `/var/www`. Jei šis katalogas PHP rašomas, įterptas kodas ten gali sukurti `.ssh/authorized_keys`. Ar prisijungimas tuomet pavyks, priklauso nuo prisijungimo apvalkalo ir SSH nustatymų, bet pats failas jau yra pavojaus ženklas.

Ne kiekvienas nežinomas įrašas yra piktavalis. Diegimo įrankiai, atsarginių kopijų paslaugos ar ankstesni paslaugų teikėjai deda savo raktus. Tokie įrašai tačiau turėtų turėti žinomą savininką ir paskirtį.

## authorized_keys patikra žingsnis po žingsnio

Toliau pateiktos komandos nieko nekeičia. Jos išvardija visus naudotojų raktų failus ir kiekvienam raktui parodo kontrolinį kodą:

```bash
# Visi authorized_keys failai visų naudotojų namų kataloguose
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

# Parodyti failo kontrolinius kodus ir komentarus
sudo ssh-keygen -lf /root/.ssh/authorized_keys

# Kiti raktų failai už įprastų vietų ribų
sudo find / -xdev -name 'authorized_keys*' 2>/dev/null
```

Rezultatą peržiūrėkite pagal šį kontrolinį sąrašą:

1. **Ar kiekvienas raktas priklauso žinomam asmeniui ar paslaugai?** Palyginkite kontrolinius kodus, ne tik komentarą.
2. **Ar naudotojas turi raktą, kurio išvis neturėtų turėti?** Pavyzdžiui, žiniatinklio serverio, duomenų bazės ar paslaugų paskyros.
3. **Ar prieš raktą yra parinkčių?** Įrašai su `command=` kiekvieno prisijungimo metu vykdo fiksuotą komandą. Tai teisėta atsarginėms kopijoms, bet ir slėptuvė.
4. **Kada failas paskutinį kartą pakeistas?** Pakeitimo data po 2026-10-17, pagal žiniasklaidos pranešimus pirmojo pastebėto PHP2Shell atakos bandymo dienos, vertas ypatingo dėmesio. Laiko žymas tačiau galima suklastoti.
5. **Ar sutampa savininkas ir teisės?** Failas, priklausantis kitam naudotojui nei namų katalogas, krenta į akis.

## Svetimų raktų saugus pašalinimas

Prieš ištrindami eilutę, failą išsaugokite su laiko žyma ir kontroline suma už serverio ribų. Užsirašykite svetimo rakto kontrolinį kodą. Jis vėliau padeda atsakyti, ar tas pats raktas atsiranda ir kituose serveriuose, pavyzdžiui, agentūros su daug klientų sistemų.

Papildomai patikrinkite prisijungimo protokolus. `/var/log/auth.log` (Debian, Ubuntu) arba `/var/log/secure` (RHEL šeima) SSH tarnyba registruoja sėkmingus prisijungimus su naudoto rakto kontroliniu kodu. Taip matote, ar svetimas raktas jau buvo naudotas ir iš kokio adreso.

Pagalvokite ir apie priešingą kryptį. Jei serveryje yra privačių raktų, pavyzdžiui, po `~/.ssh/id_*` diegimams ar atsarginėms kopijoms, užpuolikas galėjo juos nukopijuoti. Su jais jis galbūt pasiekia kitus serverius, Git saugyklas ar atsarginių kopijų tikslus. Tokie raktai po įsilaužimo laikomi nebetinkamais: sukurkite naujus raktus ir senus pašalinkite visose tikslinėse sistemose.

Svetimas raktas retai yra vienintelis pėdsakas. Kas jį padėjo, turėjo rašymo teises ir galbūt įrengė kitus kelius, pavyzdžiui, cron užduotis ar papildomas paskyras. Todėl patikrinkite ir [paslėptas cron užduotis](https://phpsos.de/lt/blog/cronjobs-als-hintertuer/) bei [svetimas administratoriaus paskyras](https://phpsos.de/lt/blog/fremde-admin-konten-finden/). Jei užpuolikas turėjo root teises, serverio perkūrimas dažnai patikimesnis nei išvalymas.

> **Svarbu:**
> Svetimus raktus šalinkite tik kai PHP yra ištaisytoje būsenoje (8.5.12, 8.4.27, 8.3.36, 8.2.35 arba patvirtintas atgalinis perkėlimas) ir visi darbiniai procesai (worker) paleisti iš naujo. Kitaip užpuolikas per tą pačią spragą raktą iškart gali įrašyti iš naujo.

## Po to SSH prieigą sutvirtinti

Po išvalymo verta trumpai sutvirtinti. Dauguma punktų įgyvendinami greitai, bet visada turėtų būti išbandomi su antra, atvira sesija, kad savęs neišblokuotumėte.

| Priemonė | Nustatymas ar veiksmai |
|---|---|
| Prisijungimas tik raktu | `PasswordAuthentication no` |
| Root tiesiogiai neprisijungia | `PermitRootLogin no`, darbas per asmenines paskyras su sudo |
| Išjungti antrą raktų failą | `AuthorizedKeysFile .ssh/authorized_keys` |
| Apriboti raktą pagal kilmę | parinktis `from=` prieš raktą, pavyzdžiui, atsarginių kopijų serveriui |
| Apriboti paslaugų raktus | parinktis `restrict` ir fiksuotas `command=` automatizavimui |
| Žiniatinklio serverio naudotojas be prisijungimo | prisijungimo apvalkalas `nologin`, jokio `.ssh` namų kataloge |

Be to, tvarkykite visų įgaliotų raktų sąrašą su savininku ir paskirtimi. Kai darbuotojas ar paslaugų teikėjas išeina, jo raktas pašalinamas visuose serveriuose. Be šio sąrašo kita patikra vėl yra detektyvinis darbas. Pripažintus SSH sutvirtinimo reikalavimus turi ir CIS Benchmarks.

## Kaip PHP SOS padeda konkrečiai?

- Nustatome, kuriuos raktų failus jūsų SSH tarnyba iš tikrųjų skaito, ir kiekvieną įrašą tikriname pagal žinomus savininkus.
- Radinius išsaugome ir vertiname prisijungimo protokolus, kad išsiaiškintume, ar svetimas raktas buvo naudotas.
- Raktus, paskyras ir cron užduotis išvalome teisinga eile ir prieš tai uždarome spragą.
- Vykdydami [serverio sutvirtinimą](https://phpsos.de/lt/leistungen/server-haertung/) įgyvendiname SSH nustatymus ir įrengiame raktų valdymą su savininkų sąrašu.


## Dažni klausimai

**Kaip atpažinti, ar SSH raktas svetimas?**  
Kiekvienas raktas turi kontrolinį kodą (fingerprint) ir dažniausiai komentarą eilutės gale. Palyginkite kontrolinius kodus su savo darbuotojų ir paslaugų teikėjų raktais. Vien komentaras nieko neįrodo, nes jį galima laisvai pasirinkti ir suklastoti.

**Ar padeda pakeisti root slaptažodį?**  
Nuo įterpto rakto ne. Prisijungimui raktu slaptažodžio nereikia. Todėl patys authorized_keys failai turi būti patikrinti ir išvalyti.

**Kodėl žiniatinklio serverio naudotojas gali turėti SSH raktą?**  
Žiniatinklio serverio naudotojas turi savo namų katalogą, Debian ir Ubuntu sistemose dažnai /var/www. Jei ten yra .ssh/authorized_keys ir paskyra turi prisijungimo apvalkalą, prisijungti kaip šis naudotojas galima. Esant rašomam žiniatinklio katalogui, įterptas PHP kodas tokį failą gali sukurti.

**Kas yra authorized_keys2?**  
Senesnis antras failas, kurį OpenSSH pagal numatytąjį nustatymą taip pat skaito. Daug patikros instrukcijų jį praleidžia. Su sshd -T patikrinkite, kuriuos failus jūsų serveris iš tikrųjų vertina.

## Šaltiniai

- [BSI: Nuorodos dėl IT saugumo incidentų](https://www.bsi.bund.de/)
- [php.net: saugumo pranešimai](https://www.php.net/)
- [CIS Benchmarks](https://www.cisecurity.org/cis-benchmarks)