Hitta och ta bort okända SSH-nycklar

Kort sagt: För att hitta okända SSH-nycklar måste ni kontrollera alla authorized_keys-filer på servern, inte bara root:s. Ta reda på med sshd -T vilka filer er SSH-tjänst läser, lista fingeravtrycken för varje nyckel och stäm av dem mot de kända nycklarna. Säkra främmande poster först, ta sedan bort dem och härda därefter åtkomsten.

Nyckeln som överlever varje lösenordsbyte

Efter en incident byter många driftansvariga först alla lösenord. Mot en av de mest anonyma bakdörrarna hjälper det inte: en extra offentlig nyckel i en authorized_keys-fil. Den som äger den passande privata nyckeln loggar in utan lösenord, så länge tills någon hittar raden.

Okända SSH-nycklar hör därför till de tecken som alltid bör kontrolleras efter en kodkörning. För PHP2Shell finns inga publicerade, bekräftade Indicators of Compromise; upptäckten bygger på beteendeanalys. En främmande nyckel är inget specifikt PHP2Shell-belägg, men ett tydligt tecken på att någon ville ha varaktig åtkomst. Fler tecken beskrivs i Är jag redan komprometterad?.

Var SSH-nycklar ligger på servern

OpenSSH läser enligt dokumentationen som standard två filer i varje användares hemkatalog: .ssh/authorized_keys och .ssh/authorized_keys2. Den andra glöms ofta bort. Inställningen kan ändras, och med AuthorizedKeysCommand kan servern till och med hämta nycklar från ett externt program. Kontrollera därför först vad som faktiskt gäller på er server:

# Skriv ut den effektiva SSH-konfigurationen (bara läsande)
sudo sshd -T | grep -iE '^(authorizedkeysfile|authorizedkeyscommand|permitrootlogin|passwordauthentication|pubkeyauthentication)'

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

En särskild plats är webbserveranvändarens hemkatalog. Under Debian och Ubuntu är det för www-data ofta /var/www. Är den katalogen skrivbar för PHP kan insmugglad kod lägga en .ssh/authorized_keys där. Om inloggningen sedan lyckas beror på inloggningsskal och SSH-inställningar, men själva filen är redan ett larmtecken.

Inte varje okänd post är illasinnad. Deployment-verktyg, säkerhetskopieringstjänster eller tidigare tjänsteleverantörer lägger in egna nycklar. Sådana poster bör dock ha en känd ägare och ett känt syfte.

Kontrollera authorized_keys: steg för steg

Kommandona nedan ändrar ingenting. De listar alla användares nyckelfiler och visar fingeravtrycket för varje nyckel:

# Alla authorized_keys-filer i alla användares hemkataloger
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

# Visa fingeravtryck och kommentarer för en fil
sudo ssh-keygen -lf /root/.ssh/authorized_keys

# Ytterligare nyckelfiler utanför de vanliga platserna
sudo find / -xdev -name 'authorized_keys*' 2>/dev/null

Gå igenom resultatet med den här checklistan:

1. Tillhör varje nyckel en känd person eller en känd tjänst? Stäm av fingeravtrycken, inte bara kommentaren.
2. Har en användare nycklar som inte borde ha några? Till exempel webbserveranvändaren, databas- eller tjänstekonton.
3. Står det alternativ före nyckeln? Poster med command= kör ett fast kommando vid varje inloggning. Det är legitimt för säkerhetskopior, men också ett gömställe.
4. När ändrades filen senast? Ett ändringsdatum efter den 17.10.2026, det enligt medierapporter första observerade PHP2Shell-angreppsförsöket, förtjänar särskild uppmärksamhet. Tidsstämplar kan dock förfalskas.
5. Stämmer ägare och rättigheter? En fil som tillhör en annan användare än hemkatalogen är uppseendeväckande.

Ta bort främmande nycklar säkert

Innan ni raderar en rad säkrar ni filen med tidsstämpel och kontrollsumma utanför servern. Notera den främmande nyckelns fingeravtryck. Det hjälper senare med frågan om samma nyckel dyker upp även på andra servrar, till exempel hos en byrå med många kundsystem.

Kontrollera dessutom inloggningsloggarna. I /var/log/auth.log (Debian, Ubuntu) eller /var/log/secure (RHEL-familjen) loggar SSH-tjänsten lyckade inloggningar med fingeravtrycket för den använda nyckeln. Så ser ni om den främmande nyckeln redan har använts och från vilken adress.

Tänk också på motsatt riktning. Ligger privata nycklar på servern, till exempel under ~/.ssh/id_* för deployments eller säkerhetskopior, kunde en angripare kopiera dem. Med dem når han kanske andra servrar, Git-repositorier eller säkerhetskopieringsmål. Sådana nycklar räknas efter ett intrång som förbrukade: skapa nya nycklar och ta bort de gamla på alla målsystem.

En främmande nyckel är sällan det enda spåret. Den som har lagt den hade skrivrättigheter och har kanske upprättat fler vägar, till exempel cronjobb eller extra konton. Kontrollera därför också dolda cronjobb och främmande adminkonton. Hade angriparen root-rättigheter är en nyuppbyggnad av servern ofta mer tillförlitlig än en sanering.

Härda SSH-åtkomsten efteråt

Efter saneringen lönar sig en kort härdning. De flesta punkter går snabbt att genomföra, men bör alltid testas med en andra, öppen session så att ni inte stänger ute er själva.

För dessutom en lista över alla behöriga nycklar med ägare och syfte. Slutar en medarbetare eller tjänsteleverantör tas hans nyckel bort på alla servrar. Utan den listan är nästa kontroll återigen detektivarbete. Erkända härdningsanvisningar för SSH finns också i CIS Benchmarks.

Hur hjälper PHP SOS konkret?

• Vi tar reda på vilka nyckelfiler er SSH-tjänst verkligen läser och kontrollerar varje post mot de kända ägarna.
• Vi säkrar fynd och utvärderar inloggningsloggarna för att klarlägga om en främmande nyckel har använts.
• Vi sanerar nycklar, konton och cronjobb i rätt ordning och stänger sårbarheten först.
• Inom ramen för serverhärdningen genomför vi SSH-inställningarna och sätter upp en nyckelhantering med ägarlista.

Vanliga frågor

Källor

• BSI (den tyska federala myndigheten för informationssäkerhet): anvisningar om IT-säkerhetsincidenter
• php.net: säkerhetsmeddelanden
• CIS Benchmarks