Lyhyesti: Tuntemattomien SSH-avainten löytämiseksi on tarkistettava kaikki palvelimen authorized_keys-tiedostot, ei vain rootin. Selvittäkää komennolla sshd -T, mitä tiedostoja SSH-palvelunne lukee, luetteloikaa jokaisen avaimen sormenjäljet ja verratkaa niitä tunnettuihin avaimiin. Varmistakaa vieraat merkinnät ensin, poistakaa ne sitten ja koventakaa pääsy sen jälkeen.
Avain, joka säilyy jokaisen salasanan vaihdon yli
Tapauksen jälkeen monet ylläpitäjät vaihtavat ensimmäisenä kaikki salasanat. Yhtä huomaamattomimmista takaoves vastaan se ei auta: ylimääräistä julkista avainta authorized_keys-tiedostossa. Joka omistaa sopivan yksityisen avaimen, kirjautuu ilman salasanaa, niin kauan kuin kukaan ei löydä riviä.
Tuntemattomat SSH-avaimet kuuluvat siksi merkkeihin, jotka koodin suorituksen jälkeen kannattaa aina tarkistaa. PHP2Shellille ei ole julkaistuja, vahvistettuja Indicators of Compromise -tunnisteita; havaitseminen perustuu käyttäytymisanalyysiin. Vieras avain ei ole erityinen PHP2Shell-todiste, mutta selvä merkki siitä, että joku halusi pysyvän pääsyn. Muita merkkejä kuvaa Olenko jo vaarantunut?.
Missä SSH-avaimet palvelimella sijaitsevat
OpenSSH lukee dokumentaation mukaan oletuksena kaksi tiedostoa jokaisen käyttäjän kotihakemistosta: .ssh/authorized_keys ja .ssh/authorized_keys2. Toinen unohtuu usein. Asetusta voi muuttaa, ja AuthorizedKeysCommand-asetuksella palvelin voi jopa hakea avaimet ulkoisesta ohjelmasta. Tarkistakaa siksi ensin, mikä palvelimellanne todella pätee:
# Tulosta voimassa oleva SSH-konfiguraatio (vain lukien)
sudo sshd -T | grep -iE '^(authorizedkeysfile|authorizedkeyscommand|permitrootlogin|passwordauthentication|pubkeyauthentication)'
# Lisäkonfiguraatiotiedostot ja Match-lohkot
ls -la /etc/ssh/sshd_config.d/ 2>/dev/null
sudo grep -rn -iE '^\s*(Match|AuthorizedKeys)' /etc/ssh/
Erityinen paikka on verkkopalvelinkäyttäjän kotihakemisto. Debianilla ja Ubuntulla se on käyttäjälle www-data usein /var/www. Jos tämä hakemisto on PHP:n kirjoitettavissa, lisätty koodi voi luoda sinne .ssh/authorized_keys-tiedoston. Se, onnistuuko kirjautuminen silloin, riippuu kirjautumisshellistä ja SSH-asetuksista, mutta tiedosto itsessään on jo hälytysmerkki.
Kaikki tuntemattomat merkinnät eivät ole pahantahtoisia. Käyttöönottotyökalut, varmuuskopiopalvelut tai aiemmat palveluntarjoajat tallentavat omia avaimiaan. Tällaisilla merkinnöillä pitäisi kuitenkin olla tunnettu omistaja ja tarkoitus.
authorized_keys-tarkistus vaihe vaiheelta
Seuraavat komennot eivät muuta mitään. Ne luettelevat käyttäjien kaikki avaintiedostot ja näyttävät jokaisen avaimen sormenjäljen:
# Kaikki authorized_keys-tiedostot kaikkien käyttäjien kotihakemistoissa
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
# Näytä tiedoston sormenjäljet ja kommentit
sudo ssh-keygen -lf /root/.ssh/authorized_keys
# Muut avaintiedostot tavallisten paikkojen ulkopuolella
sudo find / -xdev -name 'authorized_keys*' 2>/dev/null
Käykää tulos läpi tämän tarkistuslistan avulla:
- Kuuluuko jokainen avain tunnetulle henkilölle tai palvelulle? Verratkaa sormenjäljet, älkää vain kommenttia.
- Onko käyttäjällä avain, jota ei pitäisi olla? Esimerkiksi verkkopalvelinkäyttäjällä, tietokanta- tai palvelutileillä.
- Onko avaimen edessä valintoja? Merkinnät
command=suorittavat jokaisella kirjautumisella kiinteän komennon. Se on oikeutettua varmuuskopioille, mutta myös piilopaikka. - Milloin tiedosto on viimeksi muutettu? Muutospäivä 17.10.2026 jälkeen, mediatietojen mukaan ensimmäisen havaitun PHP2Shell-hyökkäysyrityksen päivä, ansaitsee erityistä huomiota. Aikaleimat voi kuitenkin väärentää.
- Täsmäävätkö omistaja ja oikeudet? Tiedosto, jonka omistaa eri käyttäjä kuin kotihakemiston, pistää silmään.
Vieraiden avainten turvallinen poistaminen
Ennen kuin poistatte rivin, varmistakaa tiedosto aikaleiman ja tarkistussumman kanssa palvelimen ulkopuolelle. Kirjatkaa vieraan avaimen sormenjälki ylös. Se auttaa myöhemmin kysymyksessä siitä, ilmestyykö sama avain myös muille palvelimille, esimerkiksi toimistolla, jolla on monta asiakasjärjestelmää.
Tarkistakaa lisäksi kirjautumislokit. Tiedostossa /var/log/auth.log (Debian, Ubuntu) tai /var/log/secure (RHEL-perhe) SSH-palvelu kirjaa onnistuneet kirjautumiset käytetyn avaimen sormenjäljen kanssa. Näin näette, onko vierasta avainta jo käytetty ja mistä osoitteesta.
Ajatelkaa myös vastakkaista suuntaa. Jos palvelimella on yksityisiä avaimia, esimerkiksi polussa ~/.ssh/id_* käyttöönottoja tai varmuuskopioita varten, hyökkääjä on voinut kopioida ne. Niillä hän voi päästä muille palvelimille, Git-repositorioihin tai varmuuskopiokohteisiin. Tällaiset avaimet katsotaan murron jälkeen käytetyiksi: luokaa uudet avaimet ja poistakaa vanhat kaikista kohdejärjestelmistä.
Vieras avain on harvoin ainoa jälki. Joka sen on tallentanut, on omannut kirjoitusoikeudet ja on voinut ottaa käyttöön muita teitä, esimerkiksi cron-töitä tai lisätilejä. Tarkistakaa siksi myös piilotetut cron-työt ja vieraat ylläpitäjätilit. Jos hyökkääjällä oli root-oikeudet, palvelimen uudelleenrakennus on usein luotettavampaa kuin siivous.
Poistakaa vieraat avaimet vasta, kun PHP on korjatulla tasolla (8.5.12, 8.4.27, 8.3.36, 8.2.35 tai vahvistettu backport) ja kaikki workerit on käynnistetty uudelleen. Muuten hyökkääjä voi kirjata avaimen heti takaisin saman aukon kautta.
SSH-pääsyn koventaminen jälkikäteen
Siivouksen jälkeen lyhyt koventaminen kannattaa. Useimmat kohdat on helppo toteuttaa, mutta ne kannattaa aina testata toisella, avoimella istunnolla, jotta ette lukitse itseänne ulos.
| Toimenpide | Asetus tai toimintatapa |
|---|---|
| Kirjautuminen vain avaimella | PasswordAuthentication no |
| Rootin suora kirjautuminen estetty | PermitRootLogin no, työskentely henkilökohtaisilla tileillä ja sudolla |
| Toinen avaintiedosto pois käytöstä | AuthorizedKeysFile .ssh/authorized_keys |
| Avainten rajaus alkuperän mukaan | valinta from= avaimen edessä, esim. varmuuskopiopalvelimelle |
| Palveluavainten rajoittaminen | valinta restrict ja kiinteä command= automaatiolle |
| Verkkopalvelinkäyttäjä ilman kirjautumista | kirjautumisshell nologin, ei .ssh-hakemistoa kotihakemistossa |
Ylläpitäkää lisäksi luetteloa kaikista oikeutetuista avaimista omistajan ja tarkoituksen kanssa. Kun työntekijä tai palveluntarjoaja lähtee, hänen avaimensa poistetaan kaikilta palvelimilta. Ilman tätä luetteloa seuraava tarkistus on taas salapoliisityötä. Tunnustetut SSH-koventamisohjeet sisältävät myös CIS Benchmarks.
Miten PHP SOS auttaa konkreettisesti?
- Selvitämme, mitä avaintiedostoja SSH-palvelunne todella lukee, ja tarkistamme jokaisen merkinnän tunnettuja omistajia vasten.
- Varmistamme löydöt ja arvioimme kirjautumislokit selvittääksemme, onko vierasta avainta käytetty.
- Siivoamme avaimet, tilit ja cron-työt oikeassa järjestyksessä ja suljemme ensin aukon.
- Palvelimen koventamisen puitteissa toteutamme SSH-asetukset ja otamme käyttöön avainhallinnan omistajaluettelolla.
Usein kysytyt kysymykset
Mistä tiedän, että SSH-avain on vieras?
Jokaisella avaimella on sormenjälki ja yleensä kommentti rivin lopussa. Verratkaa sormenjälkiä työntekijöidenne ja palveluntarjoajienne avaimiin. Pelkkä kommentti ei todista mitään, sillä se on vapaasti valittavissa ja väärennettävissä.
Auttaako root-salasanan vaihtaminen?
Ei lisättyä avainta vastaan. Avaimella kirjautuminen ei tarvitse salasanaa. Siksi authorized_keys-tiedostot itse on tarkistettava ja siivottava.
Miksi verkkopalvelinkäyttäjällä voi olla SSH-avain?
Verkkopalvelinkäyttäjällä on oma kotihakemisto, Debianilla ja Ubuntulla usein /var/www. Jos siellä on .ssh/authorized_keys ja tilillä on kirjautumisshell, kirjautuminen tällä käyttäjällä on mahdollista. Jos verkkohakemisto on kirjoitettavissa, lisätty PHP-koodi voi luoda tällaisen tiedoston.
Mikä on authorized_keys2?
Vanhempi toinen tiedosto, jonka OpenSSH lukee oletusasetuksilla myös. Moni tarkistusohje ohittaa sen. Tarkistakaa komennolla sshd -T, mitä tiedostoja palvelimenne todella käyttää.