Find og fjern ukendte SSH-nøgler

Kort sagt: For at finde ukendte SSH-nøgler skal I kontrollere alle authorized_keys-filer på serveren, ikke kun roots. Find med sshd -T ud af, hvilke filer jeres SSH-tjeneste læser, opregn fingeraftrykkene for hver nøgle, og afstem dem med de kendte nøgler. Sikr fremmede poster først, fjern dem derefter, og hærd bagefter adgangen.

Nøglen, der overlever hvert skift af adgangskode

Efter en hændelse ændrer mange driftsansvarlige først alle adgangskoder. Mod en af de mest upåfaldende bagdøre hjælper det ikke: en ekstra offentlig nøgle i en authorized_keys-fil. Den, der ejer den passende private nøgle, logger ind uden adgangskode, indtil nogen finder linjen.

Ukendte SSH-nøgler hører derfor til de tegn, som altid bør kontrolleres efter en kodeudførelse. For PHP2Shell findes der ingen offentliggjorte, bekræftede indicators of compromise; opdagelsen beror på adfærdsanalyse. En fremmed nøgle er intet specifikt PHP2Shell-bevis, men et klart tegn på, at nogen ville have varig adgang. Yderligere tegn beskriver Er jeg allerede kompromitteret?.

Hvor SSH-nøgler ligger på serveren

OpenSSH læser ifølge dokumentationen som standard to filer i hver brugers hjemmemappe: .ssh/authorized_keys og .ssh/authorized_keys2. Den anden glemmes ofte. Indstillingen kan ændres, og med AuthorizedKeysCommand kan serveren endda hente nøgler fra et eksternt program. Kontrollér derfor først, hvad der faktisk gælder på jeres server:

# Udlæs den effektive SSH-konfiguration (kun læsende)
sudo sshd -T | grep -iE '^(authorizedkeysfile|authorizedkeyscommand|permitrootlogin|passwordauthentication|pubkeyauthentication)'

# Yderligere konfigurationsfiler og Match-blokke
ls -la /etc/ssh/sshd_config.d/ 2>/dev/null
sudo grep -rn -iE '^\s*(Match|AuthorizedKeys)' /etc/ssh/

Et særligt sted er webserverbrugerens hjemmemappe. Under Debian og Ubuntu er det for www-data ofte /var/www. Er denne mappe skrivbar for PHP, kan indsmuglet kode oprette en .ssh/authorized_keys dér. Om loginet så lykkes, afhænger af login-shell og SSH-indstillinger, men selve filen er allerede et alarmtegn.

Ikke enhver ukendt post er ondsindet. Deployment-værktøjer, backup-tjenester eller tidligere tjenesteydere lægger egne nøgler. Sådanne poster bør dog have en kendt ejer og et kendt formål.

Kontrollér authorized_keys: trin for trin

Følgende kommandoer ændrer intet. De opregner alle brugernes nøglefiler og viser fingeraftrykket for hver nøgle:

# Alle authorized_keys-filer i alle brugeres hjemmemapper
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

# Vis fingeraftryk og kommentarer for en fil
sudo ssh-keygen -lf /root/.ssh/authorized_keys

# Yderligere nøglefiler uden for de sædvanlige steder
sudo find / -xdev -name 'authorized_keys*' 2>/dev/null

Gennemgå resultatet med denne tjekliste:

1. Tilhører hver nøgle en kendt person eller en kendt tjeneste? Afstem fingeraftrykkene, ikke kun kommentaren.
2. Har en bruger nøgler, som slet ikke bør have nogen? F.eks. webserverbrugeren, database- eller tjenestekonti.
3. Står der tilvalg foran nøglen? Poster med command= udfører en fast kommando ved hvert login. Det er legitimt til backups, men også et gemmested.
4. Hvornår blev filen sidst ændret? En ændringsdato efter 17.10.2026, det ifølge mediernes rapporter første observerede PHP2Shell-angrebsforsøg, fortjener særlig opmærksomhed. Tidsstempler kan dog forfalskes.
5. Passer ejer og rettigheder? En fil, der tilhører en anden bruger end hjemmemappen, er påfaldende.

Fjern fremmede nøgler sikkert

Før I sletter en linje, sikr filen med tidsstempel og kontrolsum uden for serveren. Notér den fremmede nøgles fingeraftryk. Det hjælper senere ved spørgsmålet, om den samme nøgle også dukker op på andre servere, f.eks. hos et bureau med mange kundesystemer.

Kontrollér desuden login-logs. I /var/log/auth.log (Debian, Ubuntu) eller /var/log/secure (RHEL-familien) logger SSH-tjenesten vellykkede logins med fingeraftrykket for den anvendte nøgle. Så kan I se, om den fremmede nøgle allerede er brugt, og fra hvilken adresse.

Tænk også på modsat retning. Ligger der private nøgler på serveren, f.eks. under ~/.ssh/id_* til deployments eller backups, kunne en angriber kopiere dem. Med dem når han måske andre servere, Git-repositories eller backupmål. Sådanne nøgler regnes efter et indbrud som brugt op: Opret nye nøgler, og fjern de gamle på alle målsystemer.

En fremmed nøgle er sjældent det eneste spor. Den, der har lagt den, havde skriverettigheder og har måske indrettet yderligere veje, f.eks. cronjobs eller ekstra konti. Kontrollér derfor også skjulte cronjobs og fremmede admin-konti. Havde angriberen root-rettigheder, er en nyopbygning af serveren ofte mere pålidelig end en oprydning.

Hærd SSH-adgangen bagefter

Efter oprydningen er en kort hærdning umagen værd. De fleste punkter er hurtigt gennemført, men bør altid testes med en anden, åben session, så I ikke låser jer selv ude.

Før desuden en liste over alle berettigede nøgler med ejer og formål. Forlader en medarbejder eller tjenesteyder virksomheden, fjernes hans nøgle på alle servere. Uden denne liste er den næste kontrol igen detektivarbejde. Anerkendte hærdningsretningslinjer for SSH indeholder også CIS Benchmarks.

Hvordan hjælper PHP SOS konkret?

• Vi finder ud af, hvilke nøglefiler jeres SSH-tjeneste virkelig læser, og kontrollerer hver post mod de kendte ejere.
• Vi sikrer fund og analyserer login-logs for at afklare, om en fremmed nøgle er brugt.
• Vi renser nøgler, konti og cronjobs i den rette rækkefølge og lukker først sårbarheden.
• Som led i serverhærdningen gennemfører vi SSH-indstillingerne og sætter en nøgleadministration med ejerliste op.

Ofte stillede spørgsmål

Kilder

• BSI (det tyske forbundsagentur for informationssikkerhed): Henvisninger om it-sikkerhedshændelser
• php.net: Sikkerhedsmeddelelser
• CIS Benchmarks