Iskanje in odstranjevanje neznanih ključev SSH

Na kratko: Da najdete neznane ključe SSH, morate preveriti vse datoteke authorized_keys na strežniku, ne samo tiste za root. Z sshd -T ugotovite, katere datoteke bere vaša storitev SSH, naštejte prstne odtise vsakega ključa in jih primerjajte z znanimi ključi. Tuje vnose najprej zavarujte, nato odstranite in dostop pozneje utrdite.

Ključ, ki preživi vsako menjavo gesla

Po incidentu mnogi upravljavci najprej zamenjajo vsa gesla. Proti eni najbolj neopaznih stranskih vrat to ne pomaga: dodatnemu javnemu ključu v datoteki authorized_keys. Kdor ima ustrezni zasebni ključ, se prijavi brez gesla, dokler kdo vrstice ne najde.

Neznani ključi SSH zato sodijo med znake, ki jih je po izvedbi kode treba vedno preveriti. Za PHP2Shell ni objavljenih, potrjenih indikatorjev ogroženosti (Indicators of Compromise); odkrivanje temelji na analizi vedenja. Tuj ključ ni specifičen dokaz za PHP2Shell, je pa jasen znak, da je nekdo želel trajen dostop. Nadaljnje znake opisuje Ali smo že ogroženi?.

Kje na strežniku ležijo ključi SSH

OpenSSH po dokumentaciji privzeto bere dve datoteki v domačem imeniku vsakega uporabnika: .ssh/authorized_keys in .ssh/authorized_keys2. Druga se pogosto pozabi. Nastavitev je mogoče spremeniti in z AuthorizedKeysCommand lahko strežnik ključe celo pridobi iz zunanjega programa. Zato najprej preverite, kaj na vašem strežniku dejansko velja:

# Izpis veljavne konfiguracije SSH (samo branje)
sudo sshd -T | grep -iE '^(authorizedkeysfile|authorizedkeyscommand|permitrootlogin|passwordauthentication|pubkeyauthentication)'

# Dodatne konfiguracijske datoteke in bloki Match
ls -la /etc/ssh/sshd_config.d/ 2>/dev/null
sudo grep -rn -iE '^\s*(Match|AuthorizedKeys)' /etc/ssh/

Posebno mesto je domači imenik uporabnika spletnega strežnika. V Debianu in Ubuntuju je to za www-data pogosto /var/www. Če je ta imenik za PHP zapisljiv, lahko vnesena koda tam ustvari .ssh/authorized_keys. Ali prijava nato uspe, je odvisno od prijavne lupine in nastavitev SSH, sama datoteka pa je že alarmni znak.

Ni vsak neznan vnos zlonameren. Orodja za uvajanje, storitve varnostnega kopiranja ali prejšnji izvajalci shranijo lastne ključe. Takšni vnosi pa bi morali imeti znanega lastnika in namen.

Preverjanje authorized_keys: korak za korakom

Naslednji ukazi ničesar ne spremenijo. Naštejejo vse datoteke s ključi uporabnikov in za vsak ključ pokažejo prstni odtis:

# Vse datoteke authorized_keys v domačih imenikih vseh uporabnikov
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

# Prikaz prstnih odtisov in komentarjev ene datoteke
sudo ssh-keygen -lf /root/.ssh/authorized_keys

# Dodatne datoteke s ključi zunaj običajnih mest
sudo find / -xdev -name 'authorized_keys*' 2>/dev/null

Rezultat preglejte s tem kontrolnim seznamom:

1. Ali vsak ključ pripada znani osebi ali znani storitvi? Primerjajte prstne odtise, ne samo komentarja.
2. Ali ima uporabnik ključ, čeprav ga ne bi smel imeti? Na primer uporabnik spletnega strežnika, računi podatkovne baze ali storitev.
3. Ali so pred ključem možnosti? Vnosi z command= ob vsaki prijavi izvedejo fiksen ukaz. To je legitimno za varnostne kopije, a tudi skrivališče.
4. Kdaj je bila datoteka nazadnje spremenjena? Datum spremembe po 17. 10. 2026, po poročilih medijev prvem opaženem poskusu napada PHP2Shell, zasluži posebno pozornost. Časovne žige je mogoče ponarediti.
5. Ali se ujemata lastnik in pravice? Datoteka, ki pripada drugemu uporabniku kot domači imenik, je opazna.

Varna odstranitev tujih ključev

Preden vrstico izbrišete, datoteko z časovnim žigom in kontrolno vsoto zavarujte zunaj strežnika. Zabeležite prstni odtis tujega ključa. Pozneje pomaga pri vprašanju, ali se isti ključ pojavlja tudi na drugih strežnikih, na primer pri agenciji z mnogimi sistemi strank.

Preverite tudi dnevnike prijav. V /var/log/auth.log (Debian, Ubuntu) ali /var/log/secure (družina RHEL) storitev SSH uspešne prijave beleži s prstnim odtisom uporabljenega ključa. Tako vidite, ali je bil tuj ključ že uporabljen in s katerega naslova.

Pomislite tudi na nasprotno smer. Če so na strežniku zasebni ključi, na primer pod ~/.ssh/id_* za uvajanja ali varnostne kopije, jih je napadalec lahko kopiral. Z njimi morda doseže druge strežnike, repozitorije Git ali cilje varnostnih kopij. Takšni ključi po vdoru veljajo za porabljene: ustvarite nove in stare odstranite na vseh ciljnih sistemih.

Tuj ključ je redko edina sled. Kdor ga je shranil, je imel pravice pisanja in je morda uredil še druge poti, na primer cronjobe ali dodatne račune. Zato preverite tudi skrite cronjobe in tuje skrbniške račune. Če je imel napadalec pravice root, je nova postavitev strežnika pogosto zanesljivejša od čiščenja.

Nato utrdite dostop SSH

Po čiščenju se splača kratko utrjevanje. Večina točk je hitro izvedena, vendar jih vedno preizkusite z drugo, odprto sejo, da se ne zaklenete ven.

Vodite tudi seznam vseh pooblaščenih ključev z lastnikom in namenom. Ko zaposleni ali izvajalec odide, se njegov ključ odstrani na vseh strežnikih. Brez tega seznama je naslednje preverjanje spet detektivsko delo. Priznane smernice za utrjevanje SSH vsebujejo tudi CIS Benchmarks.

Kako PHP SOS pomaga konkretno?

• Ugotovimo, katere datoteke s ključi vaša storitev SSH res bere, in vsak vnos preverimo glede na znane lastnike.
• Najdbe zavarujemo in ovrednotimo dnevnike prijav, da razjasnimo, ali je bil tuj ključ uporabljen.
• Ključe, račune in cronjobe očistimo v pravem vrstnem redu in prej zapremo ranljivost.
• V okviru utrjevanja strežnika izvedemo nastavitve SSH in vzpostavimo upravljanje ključev s seznamom lastnikov.

Pogosta vprašanja

Viri

• BSI: napotki k varnostnim incidentom v IT (Nemčija)
• php.net: varnostna obvestila
• CIS Benchmarks