Hľadanie a odstránenie neznámych kľúčov SSH

Stručne: Ak chcete nájsť neznáme kľúče SSH, musíte skontrolovať všetky súbory authorized_keys na serveri, nielen súbor používateľa root. Pomocou sshd -T zistite, ktoré súbory vaša služba SSH číta, vypíšte odtlačky každého kľúča a porovnajte ich so známymi kľúčmi. Cudzie záznamy najprv zabezpečte, potom odstráňte a prístup následne zabezpečte.

Kľúč, ktorý prežije každú zmenu hesla

Po incidente mnohí prevádzkovatelia ako prvé zmenia všetky heslá. Proti jednému z najnenápadnejších zadných vrátok to nepomôže: ďalšiemu verejnému kľúču v súbore authorized_keys. Kto vlastní zodpovedajúci súkromný kľúč, prihlási sa bez hesla, kým riadok niekto nenájde.

Neznáme kľúče SSH patria preto medzi príznaky, ktoré by sa mali po vykonaní kódu vždy skontrolovať. Pre PHP2Shell neexistujú zverejnené, potvrdené indikátory kompromitácie (Indicators of Compromise); rozpoznanie sa opiera o analýzu správania. Cudzí kľúč nie je špecifickým dôkazom PHP2Shell, ale jasným znakom toho, že niekto chcel trvalý prístup. Ďalšie príznaky opisuje Som už kompromitovaný?.

Kde sú kľúče SSH na serveri

OpenSSH podľa dokumentácie štandardne číta dva súbory v domovskom adresári každého používateľa: .ssh/authorized_keys a .ssh/authorized_keys2. Druhý sa často zabúda. Nastavenie sa dá zmeniť a pomocou AuthorizedKeysCommand môže server kľúče dokonca získavať z externého programu. Preto najprv skontrolujte, čo na vašom serveri skutočne platí:

# Vypísať efektívnu konfiguráciu SSH (len čítanie)
sudo sshd -T | grep -iE '^(authorizedkeysfile|authorizedkeyscommand|permitrootlogin|passwordauthentication|pubkeyauthentication)'

# Dodatočné konfiguračné súbory a bloky Match
ls -la /etc/ssh/sshd_config.d/ 2>/dev/null
sudo grep -rn -iE '^\s*(Match|AuthorizedKeys)' /etc/ssh/

Osobitným miestom je domovský adresár používateľa webového servera. V Debiane a Ubuntu je to pre www-data často /var/www. Ak je tento adresár pre PHP zapisovateľný, môže tam votrelecký kód vytvoriť .ssh/authorized_keys. Či sa prihlásenie potom podarí, závisí od prihlasovacieho shellu a nastavení SSH, samotný súbor je však už poplachový znak.

Nie každý neznámy záznam je zlomyseľný. Nástroje na nasadenie, zálohovacie služby alebo bývalí dodávatelia ukladajú vlastné kľúče. Takéto záznamy by však mali mať známeho vlastníka a účel.

Kontrola authorized_keys: krok za krokom

Nasledujúce príkazy nič nemenia. Vypíšu všetky súbory s kľúčmi používateľov a ukážu odtlačok každého kľúča:

# Všetky súbory authorized_keys v domovských adresároch všetkých používateľov
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

# Zobraziť odtlačky a komentáre jedného súboru
sudo ssh-keygen -lf /root/.ssh/authorized_keys

# Ďalšie súbory s kľúčmi mimo obvyklých miest
sudo find / -xdev -name 'authorized_keys*' 2>/dev/null

Prejdite výsledok pomocou tohto kontrolného zoznamu:

1. Patrí každý kľúč známej osobe alebo známej službe? Porovnajte odtlačky, nielen komentár.
2. Má používateľ kľúč, hoci by ho nemal mať? Napríklad používateľ webového servera, databázy alebo servisné účty.
3. Sú pred kľúčom voľby? Záznamy s command= vykonajú pri každom prihlásení pevný príkaz. To je legitímne pre zálohy, ale aj úkryt.
4. Kedy bol súbor naposledy zmenený? Dátum zmeny po 17. 10. 2026, podľa správ médií prvom pozorovanom pokuse o útok PHP2Shell, si zaslúži osobitnú pozornosť. Časové pečiatky sa však dajú sfalšovať.
5. Zodpovedajú vlastník a práva? Súbor, ktorý patrí inému používateľovi než domovský adresár, je nápadný.

Cudzie kľúče odstrániť bezpečne

Skôr než zmažete riadok, zabezpečte súbor s časovou pečiatkou a kontrolným súčtom mimo servera. Poznačte si odtlačok cudzieho kľúča. Neskôr pomôže pri otázke, či sa ten istý kľúč objavuje aj na iných serveroch, napríklad v agentúre s mnohými zákazníckymi systémami.

Skontrolujte navyše protokoly prihlásení. V /var/log/auth.log (Debian, Ubuntu) alebo /var/log/secure (rodina RHEL) služba SSH zaznamenáva úspešné prihlásenia s odtlačkom použitého kľúča. Tak uvidíte, či sa cudzí kľúč už použil a z ktorej adresy.

Myslite aj na opačný smer. Ak sú na serveri súkromné kľúče, napríklad pod ~/.ssh/id_* pre nasadenia alebo zálohy, mohol ich útočník skopírovať. S nimi možno dosiahne iné servery, repozitáre Git alebo ciele záloh. Takéto kľúče po vlámaní platia za spotrebované: vytvorte nové kľúče a staré odstráňte na všetkých cieľových systémoch.

Cudzí kľúč je zriedka jedinou stopou. Kto ho uložil, mal práva zápisu a možno zriadil ďalšie cesty, napríklad cronjoby alebo ďalšie účty. Skontrolujte preto aj skryté cronjoby a cudzie účty administrátora. Ak mal útočník práva root, je nové nasadenie servera často spoľahlivejšie než vyčistenie.

Prístup SSH potom zabezpečiť

Po vyčistení sa oplatí krátke zabezpečenie. Väčšina bodov sa dá rýchlo zrealizovať, no vždy by ste ich mali otestovať s druhou, otvorenou reláciou, aby ste sa nevysunuli von.

Veďte navyše zoznam všetkých oprávnených kľúčov s vlastníkom a účelom. Keď zamestnanec alebo dodávateľ odíde, jeho kľúč sa odstráni na všetkých serveroch. Bez tohto zoznamu je ďalšia kontrola opäť detektívnou prácou. Uznávané požiadavky na zabezpečenie SSH obsahujú aj CIS Benchmarks.

Ako konkrétne pomáha PHP SOS?

• Zistíme, ktoré súbory s kľúčmi vaša služba SSH skutočne číta, a každý záznam preveríme voči známym vlastníkom.
• Nálezy zabezpečíme a vyhodnotíme protokoly prihlásení, aby sme objasnili, či sa cudzí kľúč použil.
• Kľúče, účty a cronjoby vyčistíme v správnom poradí a predtým uzavrieme zraniteľnosť.
• V rámci zabezpečenia servera zrealizujeme nastavenia SSH a zavedieme správu kľúčov so zoznamom vlastníkov.

Časté otázky

Zdroje

• BSI: pokyny k bezpečnostným incidentom IT
• php.net: bezpečnostné hlásenia
• CIS Benchmarks