Quando ti connetti per la prima volta a un determinato server SSH, ottieni la solita domanda con l'impronta digitale della chiave; in seguito, il client SSH memorizza una copia della chiave pubblica del server nel file .ssh/known_hosts . Ma il client SSH memorizza in realtà due chiavi: una per il server nome e una per il server IP .
Ad esempio, supponiamo che il server foo.example.com abbia IP 10.0.0.8 . Alla prima connessione ( ssh foo.example.com ), il client SSH otterrà la chiave pubblica del server, visualizzerà l'impronta digitale (un hash della chiave pubblica), chiederà conferma e quindi memorizzerà nel file known_hosts due mapping, uno per foo.example.com , l'altro per 10.0.0.8 , entrambi che puntano alla stessa chiave pubblica.
Quando ci si ricollega allo stesso server, SSH verifica i due mapping. Se la prima mappatura (quella per il nome) produce una chiave pubblica diversa da quella registrata in known_hosts , si ottiene il messaggio di errore spaventoso con MAIUSCOLE MAIUSCOLE (è così che riesce a essere spaventoso) e il cliente rifiuta per connettersi ulteriormente (quindi il messaggio non è solo spaventoso, è anche abbastanza scomodo).
Un'altra situazione è quando la prima associazione corrisponde:
- I tipi di utenti:
ssh foo.example.com .
- Il sistema DNS risolve quel nome in IP
10.0.0.8 .
- Il client SSH si connette a quella macchina e ottiene la chiave pubblica del server SSH.
- La chiave pubblica ottenuta corrisponde a quella trovata in
.ssh/known_hosts sotto la voce foo.example.com .
-
MA la chiave pubblica ottenuta NON corrisponde a quella trovata in
.ssh/known_hosts sotto la voce 10.0.0.8 .
In tal caso, si ottiene il messaggio esatto che viene visualizzato nella domanda. Il client SSH ha la certezza che stai parlando con il server previsto - la chiave pubblica corrisponde a quella registrata per lo stesso nome del server - ma qualcosa non funziona, quindi l'avviso e la conferma pronta.
Questo può accadere quando l'IP del server è cambiato. Con l'esempio sopra, supponiamo che, la scorsa settimana, foo.example.com abbia IP 10.0.0.7 , ma bar.example.com ha avuto IP 10.0.0.8 . A quel tempo, ti sei collegato ad entrambi. Ma lo scorso fine settimana, un sysadmin con un leggero disturbo ossessivo compulsivo ha deciso che alcuni IP dovevano essere modificati, in modo da poter impostare regole di networking più efficienti, regolari e matematicamente eleganti. Così ha "spostato i server" e impostato bar.example.com su IP 10.0.0.16 e foo.example.com su 10.0.0.8 . Il nostro amico sysadmin ha configurato il DNS in modo doveroso per segnalare il nuovo IP. Ora siamo lunedì e vuoi collegarti di nuovo. Il tuo client SSH parla al DNS, ottiene il nuovo IP per foo.example.com , e tutto va bene, tranne che la chiave registrata per 10.0.0.8 non corrisponde alla chiave pubblica di foo.example.com : infatti , il tuo file known_hosts contiene una copia della chiave pubblica di bar.example.com , elencata sotto l'IP 10.0.0.8 , che, fino alla scorsa settimana, era bar IP, non foo .
Un sysadmin con OCD non è strettamente necessario per questo scenario; può anche avvenire con impostazioni IP dinamiche o con alcuni casi di bilanciamento del carico.
Soluzione: utilizza un editor di testo e rimuovi la voce incriminata dal tuo known_hosts (riga 14, nel tuo caso). Puoi anche usare il comando ssh-keygen -R <host> per rimuovere la voce specifica. La prossima volta che ti connetteresti, il client mostrerà un altro avvertimento (questa volta lamenta la assenza di qualsiasi chiave pubblica registrata per l'IP di destinazione), ma questo passerà quasi inosservato, perché ci sarà non essere affatto pronto. Il client SSH registrerà quindi la chiave pubblica nuovamente in known_hosts e sistemerà le cose, almeno finché l'amministratore di sistema non sentirà nuovamente le voci .
In alternativa, disabilita il controllo IP dell'host nel client SSH, impostando l'opzione CheckHostIP su no (nel% di sistema /etc/ssh/ssh_config o .ssh/config o direttamente sulla riga di comando:% codice%). I controlli IP dell'host sono utili per rilevare situazioni anomale di nomi di server erratici, ma per alcuni amministratori di sistema, il jugglery IP del server è perfettamente "normale".