# Onbekende SSH-sleutels vinden en verwijderen

> authorized_keys controleren: waar SSH-sleutels op de server staan, hoe u vreemde vermeldingen herkent, veilig verwijdert en de SSH-toegang daarna beveiligt.

Bron: https://phpsos.de/nl/blog/ssh-schluessel-pruefen/  
Stand: 25-10-2026  
Aanbieder: PHP SOS, PHP-noodhulp en serverbeveiliging. Directe hulp via WhatsApp: https://wa.me/491736494914?text=Hallo%20PHP%20SOS%2C%20wij%20hebben%20hulp%20nodig%20met%20onze%20PHP-server.%20Bedrijf%3A%20%E2%80%A6%20Website%3A%20%E2%80%A6

**Kort gezegd:** Om onbekende SSH-sleutels te vinden, moet u alle authorized_keys-bestanden op de server controleren, niet alleen die van root. Stel met `sshd -T` vast welke bestanden uw SSH-service leest, som de vingerafdrukken van elke sleutel op en vergelijk ze met de bekende sleutels. Vreemde vermeldingen eerst veiligstellen, dan verwijderen en de toegang daarna beveiligen.

## De sleutel die elke wachtwoordwissel overleeft

Na een incident wijzigen veel exploitanten als eerste alle wachtwoorden. Tegen een van de onopvallendste achterdeuren helpt dat niet: een extra openbare sleutel in een `authorized_keys`-bestand. Wie de bijpassende privésleutel bezit, meldt zich zonder wachtwoord aan, zolang totdat iemand de regel vindt.

Onbekende SSH-sleutels behoren daarom tot de tekenen die na een code-uitvoering altijd moeten worden gecontroleerd. Voor PHP2Shell bestaan geen gepubliceerde, bevestigde Indicators of Compromise; de detectie berust op gedragsanalyse. Een vreemde sleutel is geen specifiek PHP2Shell-bewijs, maar wel een duidelijk teken dat iemand blijvende toegang wilde. Verdere tekenen beschrijft [Ben ik al gecompromitteerd?](https://phpsos.de/nl/php2shell/bin-ich-gehackt-anzeichen/).

## Waar SSH-sleutels op de server staan

OpenSSH leest volgens de documentatie standaard twee bestanden in de thuismap van elke gebruiker: `.ssh/authorized_keys` en `.ssh/authorized_keys2`. Het tweede wordt vaak vergeten. De instelling kan worden gewijzigd, en met `AuthorizedKeysCommand` kan de server sleutels zelfs uit een extern programma betrekken. Controleer daarom eerst wat er op uw server werkelijk geldt:

```bash
# Effectieve SSH-configuratie uitvoeren (alleen lezend)
sudo sshd -T | grep -iE '^(authorizedkeysfile|authorizedkeyscommand|permitrootlogin|passwordauthentication|pubkeyauthentication)'

# Aanvullende configuratiebestanden en Match-blokken
ls -la /etc/ssh/sshd_config.d/ 2>/dev/null
sudo grep -rn -iE '^\s*(Match|AuthorizedKeys)' /etc/ssh/
```

Een bijzondere plek is de thuismap van de webservergebruiker. Onder Debian en Ubuntu is dat voor `www-data` vaak `/var/www`. Is deze map voor PHP beschrijfbaar, dan kan ingebrachte code daar een `.ssh/authorized_keys` aanmaken. Of het aanmelden dan lukt, hangt af van login-shell en SSH-instellingen, maar het bestand zelf is al een alarmteken.

Niet elke onbekende vermelding is kwaadaardig. Deploymenthulpmiddelen, back-updiensten of eerdere dienstverleners plaatsen eigen sleutels. Zulke vermeldingen moeten echter een bekende eigenaar en doel hebben.

## authorized_keys controleren: stap voor stap

De volgende opdrachten wijzigen niets. Ze sommen alle sleutelbestanden van de gebruikers op en tonen voor elke sleutel de vingerafdruk:

```bash
# Alle authorized_keys-bestanden in de thuismappen van alle gebruikers
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

# Vingerafdrukken en opmerkingen van een bestand tonen
sudo ssh-keygen -lf /root/.ssh/authorized_keys

# Verdere sleutelbestanden buiten de gebruikelijke plekken
sudo find / -xdev -name 'authorized_keys*' 2>/dev/null
```

Loop het resultaat met deze controlelijst door:

1. **Hoort elke sleutel bij een bekende persoon of een bekende dienst?** Vergelijk de vingerafdrukken, niet alleen de opmerking.
2. **Heeft een gebruiker sleutels die er helemaal geen zou mogen hebben?** Bijvoorbeeld de webservergebruiker, database- of serviceaccounts.
3. **Staan er opties vóór de sleutel?** Vermeldingen met `command=` voeren bij elke aanmelding een vaste opdracht uit. Dat is legitiem voor back-ups, maar ook een schuilplaats.
4. **Wanneer is het bestand voor het laatst gewijzigd?** Een wijzigingsdatum na 17 oktober 2026, de volgens mediaberichten eerste waargenomen PHP2Shell-aanvalspoging, verdient bijzondere aandacht. Tijdstempels zijn echter te vervalsen.
5. **Kloppen eigenaar en rechten?** Een bestand dat aan een andere gebruiker toebehoort dan de thuismap, valt op.

## Vreemde sleutels veilig verwijderen

Voordat u een regel wist, stelt u het bestand met tijdstempel en controlesom veilig buiten de server. Noteer de vingerafdruk van de vreemde sleutel. Hij helpt later bij de vraag of dezelfde sleutel ook op andere servers opduikt, bijvoorbeeld bij een bureau met veel klantsystemen.

Controleer bovendien de aanmeldlogs. In `/var/log/auth.log` (Debian, Ubuntu) of `/var/log/secure` (RHEL-familie) logt de SSH-service geslaagde aanmeldingen met de vingerafdruk van de gebruikte sleutel. Zo ziet u of de vreemde sleutel al is gebruikt en vanaf welk adres.

Denk ook aan de tegenovergestelde richting. Staan er op de server privésleutels, bijvoorbeeld onder `~/.ssh/id_*` voor deployments of back-ups, dan kon een aanvaller ze kopiëren. Daarmee bereikt hij mogelijk andere servers, Git-repositories of back-updoelen. Zulke sleutels gelden na een inbraak als verbruikt: nieuwe sleutels genereren en de oude op alle doelsystemen verwijderen.

Een vreemde sleutel is zelden het enige spoor. Wie hem heeft geplaatst, had schrijfrechten en heeft mogelijk verdere wegen ingericht, zoals cronjobs of extra accounts. Controleer daarom ook [verborgen cronjobs](https://phpsos.de/nl/blog/cronjobs-als-hintertuer/) en [vreemde beheerdersaccounts](https://phpsos.de/nl/blog/fremde-admin-konten-finden/). Had de aanvaller rootrechten, dan is een heropbouw van de server vaak betrouwbaarder dan een opschoning.

> **Belangrijk:**
> Verwijder vreemde sleutels pas als PHP op een verholpen stand is (8.5.12, 8.4.27, 8.3.36, 8.2.35 of bevestigde backport) en alle workers zijn herstart. Anders kan de aanvaller de sleutel via hetzelfde lek meteen opnieuw invoeren.

## De SSH-toegang daarna beveiligen

Na de opschoning loont een korte beveiligingsronde. De meeste punten zijn snel doorgevoerd, maar moeten altijd met een tweede, open sessie worden getest, zodat u uzelf niet buitensluit.

| Maatregel | Instelling of werkwijze |
|---|---|
| Aanmelden alleen met sleutel | `PasswordAuthentication no` |
| Root niet rechtstreeks laten aanmelden | `PermitRootLogin no`, werken via persoonlijke accounts met sudo |
| Tweede sleutelbestand uitschakelen | `AuthorizedKeysFile .ssh/authorized_keys` |
| Sleutel beperken tot herkomst | Optie `from=` vóór de sleutel, bijvoorbeeld voor back-upservers |
| Servicesleutels beperken | Optie `restrict` en vaste `command=` voor automatisering |
| Webservergebruiker zonder login | Login-shell `nologin`, geen `.ssh` in de thuismap |

Houd bovendien een lijst bij van alle gemachtigde sleutels met eigenaar en doel. Vertrekt een medewerker of dienstverlener, dan wordt zijn sleutel op alle servers verwijderd. Zonder deze lijst is de volgende controle weer speurwerk. Erkende beveiligingsrichtlijnen voor SSH bevatten ook de CIS Benchmarks.

## Hoe helpt PHP SOS concreet?

- Wij stellen vast welke sleutelbestanden uw SSH-service werkelijk leest en controleren elke vermelding tegen de bekende eigenaren.
- Wij stellen vondsten veilig en analyseren de aanmeldlogs om vast te stellen of een vreemde sleutel is gebruikt.
- Wij ruimen sleutels, accounts en cronjobs op in de juiste volgorde en dichten daarvoor eerst het lek.
- In het kader van de [serverbeveiliging](https://phpsos.de/nl/leistungen/server-haertung/) voeren wij de SSH-instellingen door en richten wij een sleutelbeheer met eigenarenlijst in.


## Veelgestelde vragen

**Hoe herken ik of een SSH-sleutel vreemd is?**  
Elke sleutel heeft een vingerafdruk en meestal een opmerking aan het einde van de regel. Vergelijk de vingerafdrukken met de sleutels van uw medewerkers en dienstverleners. De opmerking alleen bewijst niets, want ze is vrij te kiezen en te vervalsen.

**Helpt het het rootwachtwoord te wijzigen?**  
Tegen een ingebrachte sleutel niet. Aanmelden met een sleutel heeft geen wachtwoord nodig. Daarom moeten de authorized_keys-bestanden zelf worden gecontroleerd en opgeschoond.

**Waarom kan de webservergebruiker een SSH-sleutel hebben?**  
De webservergebruiker heeft een eigen thuismap, onder Debian en Ubuntu vaak /var/www. Staat daar een .ssh/authorized_keys en heeft het account een login-shell, dan is aanmelden als deze gebruiker mogelijk. Bij een beschrijfbare webmap kan ingebrachte PHP-code zo'n bestand aanmaken.

**Wat is authorized_keys2?**  
Een oudere tweede bestand dat OpenSSH volgens de standaardinstelling eveneens leest. Veel controlehandleidingen zien het over het hoofd. Controleer met sshd -T welke bestanden uw server werkelijk evalueert.

## Bronnen

- [BSI: aanwijzingen over IT-beveiligingsincidenten (Duitse federale dienst voor informatiebeveiliging)](https://www.bsi.bund.de/)
- [php.net: beveiligingsmeldingen](https://www.php.net/)
- [CIS Benchmarks](https://www.cisecurity.org/cis-benchmarks)