# Nezināmu SSH atslēgu atrašana un noņemšana

> authorized_keys pārbaude: kur serverī atrodas SSH atslēgas, kā atpazīt svešus ierakstus, droši tos noņemt un pēc tam nostiprināt SSH piekļuvi.

Avots: https://phpsos.de/lv/blog/ssh-schluessel-pruefen/  
Aktuāls uz: 25.10.2026  
Pakalpojuma sniedzējs: PHP SOS, PHP ārkārtas palīdzība un serveru drošība. Tūlītēja palīdzība pa WhatsApp: https://wa.me/491736494914?text=Sveiki%2C%20PHP%20SOS%2C%20mums%20nepiecie%C5%A1ama%20pal%C4%ABdz%C4%ABba%20ar%20m%C5%ABsu%20PHP%20serveri.%20Uz%C5%86%C4%93mums%3A%20%E2%80%A6%20Vietne%3A%20%E2%80%A6

**Īsi sakot:** Lai atrastu nezināmas SSH atslēgas, serverī jāpārbauda visi authorized_keys faili, ne tikai root fails. Ar `sshd -T` noskaidrojiet, kurus failus jūsu SSH pakalpojums lasa, uzskaitiet katras atslēgas pirkstu nospiedumus un salīdziniet tos ar zināmajām atslēgām. Svešus ierakstus vispirms nodrošiniet, tad noņemiet un pēc tam nostipriniet piekļuvi.

## Atslēga, kas pārdzīvo katru paroles maiņu

Pēc incidenta daudzi operatori pirmā darbā maina visas paroles. Pret vienu no neuzkrītošākajām slēptajām piekļuvēm tas nepalīdz: papildu publisko atslēgu `authorized_keys` failā. Kam ir atbilstošā privātā atslēga, pieteicas bez paroles, tik ilgi, kamēr kāds rindu atrod.

Nezināmas SSH atslēgas tāpēc pieder pie pazīmēm, kas pēc koda izpildes vienmēr jāpārbauda. PHP2Shell nav publicētu, apstiprinātu Indicators of Compromise; atpazīšana balstās uz uzvedības analīzi. Sveša atslēga nav specifisks PHP2Shell pierādījums, bet skaidra zīme, ka kāds gribēja pastāvīgu piekļuvi. Citas pazīmes apraksta [Vai esmu jau kompromitēts?](https://phpsos.de/lv/php2shell/bin-ich-gehackt-anzeichen/).

## Kur serverī atrodas SSH atslēgas

OpenSSH saskaņā ar dokumentāciju pēc noklusējuma lasa divus failus katra lietotāja mājas direktorijā: `.ssh/authorized_keys` un `.ssh/authorized_keys2`. Otro bieži aizmirst. Iestatījumu var mainīt, un ar `AuthorizedKeysCommand` serveris atslēgas var pat saņemt no ārējas programmas. Tāpēc vispirms pārbaudiet, kas jūsu serverī patiešām ir spēkā:

```bash
# Izvadīt efektīvo SSH konfigurāciju (tikai lasot)
sudo sshd -T | grep -iE '^(authorizedkeysfile|authorizedkeyscommand|permitrootlogin|passwordauthentication|pubkeyauthentication)'

# Papildu konfigurācijas faili un Match bloki
ls -la /etc/ssh/sshd_config.d/ 2>/dev/null
sudo grep -rn -iE '^\s*(Match|AuthorizedKeys)' /etc/ssh/
```

Īpaša vieta ir tīmekļa servera lietotāja mājas direktorija. Debian un Ubuntu sistēmās tā `www-data` bieži ir `/var/www`. Ja šī direktorija PHP ir rakstāma, ievadīts kods tur var izveidot `.ssh/authorized_keys`. Vai pieteikšanās tad izdodas, ir atkarīgs no pieteikšanās čaulas un SSH iestatījumiem, taču pats fails jau ir trauksmes signāls.

Ne katrs nezināms ieraksts ir ļaunprātīgs. Izvietošanas rīki, rezerves kopiju pakalpojumi vai agrākie pakalpojumu sniedzēji noglabā savas atslēgas. Šādiem ierakstiem tomēr jābūt zināmam īpašniekam un nolūkam.

## authorized_keys pārbaude: solis pa solim

Šīs komandas neko nemaina. Tās uzskaita visu lietotāju atslēgu failus un katrai atslēgai parāda pirkstu nospiedumu:

```bash
# Visi authorized_keys faili visu lietotāju mājas direktorijās
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

# Parādīt faila pirkstu nospiedumus un komentārus
sudo ssh-keygen -lf /root/.ssh/authorized_keys

# Citi atslēgu faili ārpus ierastajām vietām
sudo find / -xdev -name 'authorized_keys*' 2>/dev/null
```

Rezultātu izejiet ar šo kontrolsarakstu:

1. **Vai katra atslēga pieder zināmai personai vai zināmam pakalpojumam?** Salīdziniet pirkstu nospiedumus, ne tikai komentāru.
2. **Vai kādam lietotājam ir atslēga, kam tās nemaz nevajadzētu būt?** Piemēram, tīmekļa servera lietotājam, datubāzes vai pakalpojumu kontiem.
3. **Vai pirms atslēgas ir opcijas?** Ieraksti ar `command=` pie katras pieteikšanās izpilda fiksētu komandu. Tas ir likumīgi rezerves kopijām, bet arī slēptuve.
4. **Kad fails pēdējoreiz mainīts?** Izmaiņu datums pēc 17.10.2026, kas saskaņā ar plašsaziņas līdzekļu ziņojumiem bija pirmais novērotais PHP2Shell uzbrukuma mēģinājums, pelna īpašu uzmanību. Laika zīmogus tomēr var viltot.
5. **Vai īpašnieks un tiesības sakrīt?** Fails, kas pieder citam lietotājam nekā mājas direktorija, uzkrīt.

## Svešu atslēgu droša noņemšana

Pirms dzēšat rindu, failu nodrošiniet ar laika zīmogu un kontrolsummu ārpus servera. Pierakstiet sveša atslēgas pirkstu nospiedumu. Tas vēlāk palīdz jautājumā, vai tā pati atslēga parādās arī citos serveros, piemēram, aģentūrā ar daudzām klientu sistēmām.

Pārbaudiet arī pieteikšanās protokolus. `/var/log/auth.log` (Debian, Ubuntu) vai `/var/log/secure` (RHEL saime) SSH pakalpojums protokolē sekmīgas pieteikšanās ar izmantotās atslēgas pirkstu nospiedumu. Tā redzat, vai sveša atslēga jau ir izmantota un no kuras adreses.

Padomājiet arī par pretējo virzienu. Ja serverī atrodas privātas atslēgas, piemēram, zem `~/.ssh/id_*` izvietošanai vai rezerves kopijām, uzbrucējs tās varēja nokopēt. Ar tām viņš, iespējams, sasniedz citus serverus, Git repozitorijus vai rezerves kopiju mērķus. Šādas atslēgas pēc ielaušanās uzskatāmas par izmantotām: izveidot jaunas atslēgas un vecās noņemt visās mērķa sistēmās.

Sveša atslēga reti ir vienīgā pēda. Kas to noglabājis, tam bija rakstīšanas tiesības un viņš, iespējams, iekārtojis citus ceļus, piemēram, cronjobs vai papildu kontus. Tāpēc pārbaudiet arī [slēptos cronjobs](https://phpsos.de/lv/blog/cronjobs-als-hintertuer/) un [svešos admin kontus](https://phpsos.de/lv/blog/fremde-admin-konten-finden/). Ja uzbrucējam bija root tiesības, servera jaunbūve bieži ir uzticamāka nekā attīrīšana.

> **Svarīgi:**
> Svešas atslēgas noņemiet tikai tad, kad PHP ir labotā stāvoklī (8.5.12, 8.4.27, 8.3.36, 8.2.35 vai apstiprināts backport) un visi worker ir pārstartēti. Citādi uzbrucējs atslēgu pa to pašu ievainojamību var uzreiz ierakstīt atkal.

## SSH piekļuves pēc tam nostiprināšana

Pēc attīrīšanas vērts veikt īsu nostiprināšanu. Lielāko daļu punktu var īstenot ātri, bet vienmēr tie jātestē ar otru, atvērtu sesiju, lai neizslēgtu sevi.

| Pasākums | Iestatījums vai rīcība |
|---|---|
| Pieteikšanās tikai ar atslēgu | `PasswordAuthentication no` |
| Neļaut root pieteikties tieši | `PermitRootLogin no`, darbs caur personiskiem kontiem ar sudo |
| Izslēgt otro atslēgu failu | `AuthorizedKeysFile .ssh/authorized_keys` |
| Atslēgu ierobežot pēc izcelsmes | opcija `from=` pirms atslēgas, piemēram, rezerves kopiju serverim |
| Ierobežot pakalpojumu atslēgas | opcija `restrict` un fiksēts `command=` automatizācijai |
| Tīmekļa servera lietotājs bez pieteikšanās | pieteikšanās čaula `nologin`, nav `.ssh` mājas direktorijā |

Turklāt uzturiet visu pilnvaroto atslēgu sarakstu ar īpašnieku un nolūku. Kad darbinieks vai pakalpojumu sniedzējs aiziet, viņa atslēga tiek noņemta visos serveros. Bez šī saraksta nākamā pārbaude atkal ir detektīvdarbs. Atzītas SSH nostiprināšanas prasības ietver arī CIS Benchmarks.

## Kā PHP SOS palīdz konkrēti?

- Mēs noskaidrojam, kurus atslēgu failus jūsu SSH pakalpojums patiešām lasa, un pārbaudām katru ierakstu pret zināmajiem īpašniekiem.
- Mēs nodrošinām atradumus un izvērtējam pieteikšanās protokolus, lai noskaidrotu, vai sveša atslēga ir izmantota.
- Mēs sakopjam atslēgas, kontus un cronjobs pareizajā secībā un iepriekš aizveram ievainojamību.
- [Servera nostiprināšanas](https://phpsos.de/lv/leistungen/server-haertung/) ietvaros mēs īstenojam SSH iestatījumus un iestatām atslēgu pārvaldību ar īpašnieku sarakstu.


## Biežāk uzdotie jautājumi

**Kā atpazīt, vai SSH atslēga ir sveša?**  
Katrai atslēgai ir pirkstu nospiedums un parasti komentārs rindas beigās. Salīdziniet pirkstu nospiedumus ar jūsu darbinieku un pakalpojumu sniedzēju atslēgām. Komentārs vien neko nepierāda, jo to var brīvi izvēlēties un viltot.

**Vai palīdz root paroles maiņa?**  
Pret ievadītu atslēgu nē. Pieteikšanās ar atslēgu paroli neprasa. Tāpēc paši authorized_keys faili jāpārbauda un jāsakopj.

**Kāpēc tīmekļa servera lietotājam var būt SSH atslēga?**  
Tīmekļa servera lietotājam ir sava mājas direktorija, Debian un Ubuntu sistēmās bieži /var/www. Ja tur ir .ssh/authorized_keys un kontam ir pieteikšanās čaula, pieteikšanās kā šim lietotājam ir iespējama. Ja tīmekļa direktorijs ir rakstāms, ievadīts PHP kods šādu failu var izveidot.

**Kas ir authorized_keys2?**  
Vecāks otrs fails, ko OpenSSH saskaņā ar noklusējuma iestatījumu arī lasa. Daudzas pārbaudes pamācības to palaiž garām. Ar sshd -T pārbaudiet, kurus failus jūsu serveris patiešām izvērtē.

## Avoti

- [BSI: norādes par IT drošības incidentiem](https://www.bsi.bund.de/)
- [php.net: drošības paziņojumi](https://www.php.net/)
- [CIS Benchmarks](https://www.cisecurity.org/cis-benchmarks)
