WardtermClient SSH
IT
Scarica

WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! Cosa fare

Il server ha presentato una chiave diversa da quella salvata nel tuo known_hosts. È normale dopo una reinstallazione, ed è anche esattamente l'aspetto di un attacco. Ottieni il vero fingerprint in un altro modo, come la console del provider, confrontalo, e solo allora esegui ssh-keygen -R server e collegati di nuovo. Non usare mai StrictHostKeyChecking=no per superarlo.

Aggiornata il . Riprodotto con OpenSSH 10.3 su macOS rigenerando le chiavi host di un container Debian 13 usa e getta con OpenSSH 10.0.

Il messaggio

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that a host key has just been changed.
The fingerprint for the ED25519 key sent by the remote host is
SHA256:iU7+QOFWSHJeCFBdzU31dTOoJRNhncp+Wzw3UJMzasU.
Please contact your system administrator.
Add correct host key in /home/user/.ssh/known_hosts to get rid of this message.
Offending ED25519 key in /home/user/.ssh/known_hosts:1
Host key for server has changed and you have requested strict checking.
Host key verification failed.

Un server dimostra la propria identità con la sua chiave host. Il tuo computer ha salvato quella chiave la prima volta che ti sei collegato. Ora ne ha ricevuta una diversa, e ssh si è fermato prima di inviare qualsiasi cosa. I due dettagli che ti servono sono il nuovo fingerprint (la riga SHA256:) e la posizione della vecchia voce (known_hosts:1 è la riga 1). Su Debian e Ubuntu il messaggio suggerisce anche un comando ssh-keygen -R: eseguilo solo dopo il controllo qui sotto.

Causa legittima o attacco?

Cause comuni e innocue:

  • Il server è stato ricostruito, reinstallato o ripristinato, il che spesso crea nuove chiavi host.
  • L'indirizzo ora appartiene a un'altra macchina: una nuova VM su un IP cloud riutilizzato, o un Elastic IP spostato.
  • Un load balancer o una coppia di failover ti manda a una macchina con chiavi diverse.
  • Una porta inoltrata come localhost:2222 ora porta altrove.
  • Un amministratore o un servizio ha cambiato le chiavi, come ha fatto GitHub con la sua chiave host RSA a marzo 2023.
  • Il server non offre più il tipo di chiave che avevi salvato. Nel nostro test, un server limitato a RSA ha fatto comparire questo avviso a un client che aveva salvato la sua chiave ED25519.

Diffida quando nessuno sa spiegare il cambiamento, quando compare solo su una rete come il Wi-Fi pubblico, o quando si tratta di un server che nessuno ha toccato. Finché non lo sai, non digitare una password né eseguire nulla su di esso. Provare da un'altra rete aiuta: se i fingerprint differiscono tra le reti, qualcosa su una delle due interferisce.

Controlla il nuovo fingerprint fuori banda

Fuori banda significa attraverso un canale che un attaccante su questa connessione non può controllare: la console web del provider, una console seriale, l'accesso fisico o un collega con accesso verificato. Sul server, esegui:

sudo ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub
256 SHA256:iU7+QOFWSHJeCFBdzU31dTOoJRNhncp+Wzw3UJMzasU root@server (ED25519)

Usa il file per il tipo di chiave indicato nell'avviso: ssh_host_rsa_key.pub o ssh_host_ecdsa_key.pub per gli altri. Il valore deve corrispondere esattamente a quello dell'avviso. Alcune immagini cloud stampano i fingerprint anche nel log della console al primo avvio.

Il comando qui sotto mostra solo ciò che invia il server sul percorso di rete attuale. È comodo per leggere un valore, ma da solo non dimostra nulla, perché un attaccante gli invierebbe la stessa chiave falsa:

ssh-keyscan -t ed25519 server | ssh-keygen -lf -

Rimuovi la vecchia chiave

ssh-keygen -R server
# Host server found: line 1
/home/user/.ssh/known_hosts updated.
Original contents retained as /home/user/.ssh/known_hosts.old

Funziona anche con i nomi in hash, e non devi modificare il file a mano. Usa lo stesso nome con cui ti colleghi. Alcune configurazioni richiedono più di una chiamata:

ssh-keygen -R 203.0.113.10
ssh-keygen -R '[server]:2222'

La seconda forma è per un server su una porta diversa dalla 22.

Collegati di nuovo e confronta

ssh user@server
The authenticity of host 'server (203.0.113.10)' can't be established.
ED25519 key fingerprint is: SHA256:iU7+QOFWSHJeCFBdzU31dTOoJRNhncp+Wzw3UJMzasU
This key is not known by any other names.
Are you sure you want to continue connecting (yes/no/[fingerprint])?

Confronta, o meglio ancora incolla a questa richiesta il fingerprint che hai ottenuto dalla console. ssh allora li confronta per te, e te lo richiede se non corrispondono.

Perché non StrictHostKeyChecking=no

È il consiglio che troverai più spesso, e toglie del tutto la protezione. L'abbiamo provato contro una chiave cambiata. Stampa ancora l'avviso, poi prosegue:

Password authentication is disabled to avoid man-in-the-middle attacks.
Keyboard-interactive authentication is disabled to avoid man-in-the-middle attacks.
Agent forwarding is disabled to avoid man-in-the-middle attacks.

L'accesso con chiave è comunque andato a buon fine, quindi lavori su un server che non hai verificato, e tutto ciò che digiti o copi lì può arrivare a un attaccante. Impostare UserKnownHostsFile=/dev/null fa un danno simile: non viene mai ricordato nulla, quindi non si può mai controllare nulla.

Per gli script che incontrano host nuovi, usa StrictHostKeyChecking=accept-new. Salva le chiavi degli host nuovi e rifiuta comunque una chiave cambiata, come abbiamo confermato. Vedi known_hosts spiegato.

Per script e CI che si fermano con una sola riga, vedi Host key verification failed in script e CI.

Smettere di vedere questo avviso per i cambi pianificati

  • Quando ricostruisci un server, ripristina le sue vecchie chiavi host dal tuo backup sicuro, se la tua policy lo permette.
  • Per un insieme di macchine dietro un solo nome, usa i certificati host, così i client si fidano di una CA invece che di ogni singola chiave.
  • Per ruotare le chiavi, aggiungi prima la nuova e lascia che i client la imparino con UpdateHostKeys, e solo dopo rimuovi la vecchia.

Domande

Basta eseguire ssh-keygen -R?

Solo dopo aver confermato il nuovo fingerprint per un'altra via. Il comando toglie l'avviso, non la sua causa, quindi da solo può nascondere un attacco.

Perché l'avviso compare dopo aver reinstallato il server?

Una reinstallazione di solito crea nuove chiavi host, quindi la chiave non corrisponde più a quella salvata in known_hosts. Confronta il nuovo fingerprint dalla console, poi rimuovi la vecchia voce.

StrictHostKeyChecking=accept-new fa superare l'avviso?

No. accept-new salva solo le chiavi degli host mai visti. Una chiave cambiata viene comunque rifiutata.

Fonti

Altro in Messaggi di errore

Tutte le guide