# Trovare e rimuovere chiavi SSH sconosciute

> Verificare authorized_keys: dove si trovano le chiavi SSH sul server, come riconoscere voci estranee, rimuoverle in sicurezza e poi rafforzare l'accesso SSH.

Fonte: https://phpsos.de/it/blog/ssh-schluessel-pruefen/  
Stato: 25/10/2026  
Fornitore: PHP SOS, Assistenza di emergenza PHP e sicurezza dei server. Assistenza immediata su WhatsApp: https://wa.me/491736494914?text=Buongiorno%20PHP%20SOS%2C%20abbiamo%20bisogno%20di%20aiuto%20con%20il%20nostro%20server%20PHP.%20Azienda%3A%20%E2%80%A6%20Sito%20web%3A%20%E2%80%A6

**In breve:** per trovare chiavi SSH sconosciute deve verificare tutti i file authorized_keys sul server, non solo quello di root. Determini con `sshd -T` quali file legga il Suo servizio SSH, elenchi le impronte digitali di ogni chiave e le confronti con le chiavi note. Le voci estranee prima si conservano, poi si rimuovono e infine si rafforza l'accesso.

## La chiave che sopravvive a ogni cambio di password

Dopo un incidente molti gestori cambiano come prima cosa tutte le password. Contro una delle backdoor più discrete questo non aiuta: una chiave pubblica aggiuntiva in un file `authorized_keys`. Chi possiede la corrispondente chiave privata accede senza password, finché qualcuno non trova la riga.

Le chiavi SSH sconosciute rientrano perciò tra i segni che dopo un'esecuzione di codice vanno sempre verificati. Per PHP2Shell non esistono Indicators of Compromise pubblicati e confermati; il rilevamento si basa sull'analisi del comportamento. Una chiave estranea non è una prova specifica di PHP2Shell, ma un chiaro segno che qualcuno voleva un accesso permanente. Altri segni li descrive [Sono già compromesso?](https://phpsos.de/it/php2shell/bin-ich-gehackt-anzeichen/).

## Dove si trovano le chiavi SSH sul server

OpenSSH legge, secondo la documentazione, per impostazione predefinita due file nella directory home di ogni utente: `.ssh/authorized_keys` e `.ssh/authorized_keys2`. Il secondo viene spesso dimenticato. L'impostazione si può cambiare e con `AuthorizedKeysCommand` il server può persino ottenere le chiavi da un programma esterno. Verifichi quindi per prima cosa cosa valga effettivamente sul Suo server:

```bash
# Mostrare la configurazione SSH effettiva (solo lettura)
sudo sshd -T | grep -iE '^(authorizedkeysfile|authorizedkeyscommand|permitrootlogin|passwordauthentication|pubkeyauthentication)'

# File di configurazione aggiuntivi e blocchi Match
ls -la /etc/ssh/sshd_config.d/ 2>/dev/null
sudo grep -rn -iE '^\s*(Match|AuthorizedKeys)' /etc/ssh/
```

Un luogo particolare è la directory home dell'utente del server web. Su Debian e Ubuntu per `www-data` è spesso `/var/www`. Se questa directory è scrivibile per PHP, del codice inserito può creare lì un `.ssh/authorized_keys`. Se l'accesso poi riesca dipende da shell di login e impostazioni SSH, ma il file in sé è già un segnale d'allarme.

Non ogni voce sconosciuta è malevola. Strumenti di deployment, servizi di backup o fornitori precedenti depositano chiavi proprie. Tali voci dovrebbero però avere un proprietario e uno scopo noti.

## Verificare authorized_keys: passo per passo

I comandi seguenti non modificano nulla. Elencano tutti i file di chiavi degli utenti e mostrano per ogni chiave l'impronta digitale:

```bash
# Tutti i file authorized_keys nelle directory home di tutti gli utenti
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

# Mostrare impronte digitali e commenti di un file
sudo ssh-keygen -lf /root/.ssh/authorized_keys

# Altri file di chiavi fuori dai luoghi consueti
sudo find / -xdev -name 'authorized_keys*' 2>/dev/null
```

Esamini il risultato con questa lista di controllo:

1. **Ogni chiave appartiene a una persona o a un servizio noti?** Confronti le impronte digitali, non solo il commento.
2. **Un utente ha chiavi pur non dovendone avere?** Ad esempio l'utente del server web, account di database o di servizio.
3. **Ci sono opzioni davanti alla chiave?** Le voci con `command=` eseguono a ogni accesso un comando fisso. È legittimo per i backup, ma anche un nascondiglio.
4. **Quando è stato modificato per l'ultima volta il file?** Una data di modifica successiva al 17 ottobre 2026, il primo tentativo di attacco a PHP2Shell osservato secondo i media, merita particolare attenzione. Le marcature temporali si possono però falsificare.
5. **Proprietario e permessi sono corretti?** Un file che appartiene a un utente diverso da quello della directory home è sospetto.

## Rimuovere in sicurezza le chiavi estranee

Prima di cancellare una riga, conservi il file con marcatura temporale e somma di controllo fuori dal server. Annoti l'impronta digitale della chiave estranea. Aiuta in seguito a capire se la stessa chiave compaia anche su altri server, ad esempio presso un'agenzia con molti sistemi di clienti.

Verifichi inoltre i log di accesso. In `/var/log/auth.log` (Debian, Ubuntu) o `/var/log/secure` (famiglia RHEL) il servizio SSH registra gli accessi riusciti con l'impronta digitale della chiave utilizzata. Così vede se la chiave estranea sia già stata usata e da quale indirizzo.

Pensi anche alla direzione opposta. Se sul server si trovano chiavi private, ad esempio sotto `~/.ssh/id_*` per deployment o backup, un aggressore può averle copiate. Con esse raggiunge forse altri server, repository Git o destinazioni di backup. Tali chiavi dopo un'intrusione si considerano compromesse: generare nuove chiavi e rimuovere le vecchie su tutti i sistemi di destinazione.

Una chiave estranea raramente è l'unica traccia. Chi l'ha depositata aveva diritti di scrittura e forse ha predisposto altre vie, ad esempio cron job o account aggiuntivi. Verifichi quindi anche i [cron job nascosti](https://phpsos.de/it/blog/cronjobs-als-hintertuer/) e gli [account admin estranei](https://phpsos.de/it/blog/fremde-admin-konten-finden/). Se l'aggressore aveva diritti di root, una ricostruzione del server è spesso più affidabile di una bonifica.

> **Importante:**
> Rimuova le chiavi estranee solo quando PHP è a uno stato corretto (8.5.12, 8.4.27, 8.3.36, 8.2.35 o backport confermato) e tutti i worker sono stati riavviati. Altrimenti l'aggressore può reinserire subito la chiave attraverso la stessa vulnerabilità.

## Rafforzare poi l'accesso SSH

Dopo la bonifica vale la pena un breve rafforzamento. La maggior parte dei punti si attua in fretta, ma va sempre testata con una seconda sessione aperta, per non restare chiusi fuori.

| Misura | Impostazione o procedura |
|---|---|
| Accesso solo con chiave | `PasswordAuthentication no` |
| Non far accedere direttamente root | `PermitRootLogin no`, lavoro tramite account personali con sudo |
| Disattivare il secondo file di chiavi | `AuthorizedKeysFile .ssh/authorized_keys` |
| Limitare le chiavi per provenienza | opzione `from=` davanti alla chiave, ad esempio per i server di backup |
| Limitare le chiavi di servizio | opzione `restrict` e `command=` fisso per l'automazione |
| Utente del server web senza login | shell di login `nologin`, nessun `.ssh` nella directory home |

Tenga inoltre un elenco di tutte le chiavi autorizzate con proprietario e scopo. Quando un collaboratore o fornitore se ne va, la sua chiave viene rimossa da tutti i server. Senza questo elenco la verifica successiva è di nuovo un lavoro da investigatore. Indicazioni di rafforzamento riconosciute per SSH le contengono anche i CIS Benchmarks.

## Come aiuta concretamente PHP SOS?

- Determiniamo quali file di chiavi il Suo servizio SSH legga davvero e verifichiamo ogni voce rispetto ai proprietari noti.
- Conserviamo i ritrovamenti e valutiamo i log di accesso per chiarire se una chiave estranea sia stata usata.
- Bonifichiamo chiavi, account e cron job nell'ordine corretto e chiudiamo prima la vulnerabilità.
- Nell'ambito dell'[hardening del server](https://phpsos.de/it/leistungen/server-haertung/) attuiamo le impostazioni SSH e configuriamo una gestione delle chiavi con elenco dei proprietari.


## Domande frequenti

**Come riconosco se una chiave SSH è estranea?**  
Ogni chiave ha un'impronta digitale e di solito un commento a fine riga. Confronti le impronte con le chiavi dei Suoi collaboratori e fornitori. Il solo commento non prova nulla, perché è liberamente scelto e può essere falsificato.

**Cambiare la password di root aiuta?**  
Non contro una chiave inserita abusivamente. L'accesso con chiave non richiede una password. Per questo i file authorized_keys stessi vanno verificati e bonificati.

**Perché l'utente del server web può avere una chiave SSH?**  
L'utente del server web ha una propria directory home, su Debian e Ubuntu spesso /var/www. Se lì si trova un .ssh/authorized_keys e l'account ha una shell di login, un accesso come quell'utente è possibile. Con una directory web scrivibile, del codice PHP inserito può creare un file simile.

**Che cos'è authorized_keys2?**  
Un secondo file più vecchio che OpenSSH, con l'impostazione predefinita, legge a sua volta. Molte guide di verifica lo trascurano. Controlli con sshd -T quali file il Suo server valuti effettivamente.

## Fonti

- [BSI: indicazioni sugli incidenti di sicurezza IT](https://www.bsi.bund.de/)
- [php.net: segnalazioni di sicurezza](https://www.php.net/)
- [CIS Benchmarks](https://www.cisecurity.org/cis-benchmarks)