it-swarm-eu.dev

Chiavi ECDSA cambiate, SSH non è sicuro ora?

Sto gestendo alcuni server Ubuntu non critici nella mia stanza del college al college. Li ha disattivati ​​prima dell'interruzione, tornare, inserire SSH e ricevere un avviso che le chiavi ECDSA sono cambiate.

Sembrava più o meno così

Warning: the ECDSA Host key for '<snip>' differs from the key for the IP address '<snip>'
Offending key for IP in /home/<snip>/.ssh/known_hosts:14
Matching Host key in /home/<snip>/.ssh/known_hosts:12
Are you sure you want to continue connecting (yes/no)?

Questo sembra molto meno spaventoso dell'errore di modifica dell'identità del server, quindi non mi preoccupo troppo, ma comunque, cosa potrebbe causare questo cambiamento? È qualcosa di cui dovrei preoccuparmi?

29
TheLQ

Quando ci si connette per la prima volta a un determinato server SSH, si ottiene la solita domanda con l'impronta digitale della chiave; successivamente, il client SSH memorizza una copia della chiave pubblica del server nel file .ssh/known_hosts. Ma il client SSH in realtà memorizza 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 known_hosts file due mapping, uno per foo.example.com, l'altro per 10.0.0.8, entrambi che puntano alla stessa chiave pubblica.

Quando ti riconnetti 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, Ricevi il messaggio di errore spaventoso con LETTERE MAIUSCOLE (è così che riesce a spaventare), e il cliente rifiuta di connettersi ulteriormente (quindi il messaggio non è solo spaventoso, ma è anche piuttosto scomodo).

Un'altra situazione è quando la prima mappatura corrisponde:

  • L'utente digita: 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 fa [~ # ~] non [ ~ # ~] corrisponde a quello trovato in .ssh/known_hosts sotto la voce 10.0.0.8.

In tal caso, ricevi il messaggio esatto che visualizzi nella tua domanda. Il client SSH ha la certezza che stai parlando con il server previsto - la chiave pubblica corrisponde a quella registrata per lo stesso server nome - ma qualcosa è ancora sbagliato, quindi l'avvertimento e il prompt di conferma.

Questo può accadere quando l'IP del server è cambiato. Con l'esempio sopra, supponiamo che, la scorsa settimana, foo.example.com Avesse IP 10.0.0.7, Ma bar.example.com Avesse IP 10.0.0.8. A quel tempo, ti sei collegato ad entrambi. Ma lo scorso fine settimana, un amministratore di sistema con un lieve disturbo ossessivo compulsivo ha deciso che alcuni IP dovevano essere cambiati, in modo da poter impostare regole di rete più efficienti, regolari e matematicamente eleganti. Quindi "ha spostato i server" e ha impostato bar.example.com Su IP 10.0.0.16 E foo.example.com Su 10.0.0.8. Il nostro amico amministratore di sistema ha debitamente configurato il DNS per segnalare il nuovo IP. Ora siamo lunedì e vuoi riconnetterti. 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: In effetti, 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 IP di bar, non di foo.

Un amministratore di sistema con DOC non è strettamente necessario per questo scenario; può accadere anche con configurazioni IP dinamiche o con alcuni casi di bilanciamento del carico.

Soluzione: usa un editor di testo e rimuovi la voce offensiva 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 connetterai, il client visualizzerà un altro avviso (questa volta lamentandosi dell'assenza di qualsiasi chiave pubblica registrata per l'IP di destinazione), ma questo volerà quasi inosservato, perché non ci sarà alcun Prompt. Il client SSH registrerà quindi nuovamente la chiave pubblica in known_hosts E sistemerà le cose, almeno fino a quando l'amministratore di sistema non sentirà di nuovo le voci .

In alternativa, disabilita il controllo IP dell'host nel client SSH, impostando l'opzione CheckHostIP su no (in /etc/ssh/ssh_config A livello di sistema, oppure .ssh/config, o direttamente dalla riga di comando: ssh -o CheckHostIP=no foo.example.com). I controlli Host-IP sono utili per rilevare situazioni anomale di nomi di server erranti, ma per alcuni amministratori di sistema, la giocoleria IP del server è perfettamente "normale".

41
Tom Leek

Supponendo che sto indovinando il <snip> parti correttamente, sembra il nome host (example.com) ora si sta risolvendo in un IP diverso rispetto a prima.

Se è necessario preoccuparsi o meno, è difficile da dire senza ulteriori informazioni. In che forma è il nome host? È un nome di dominio completo? È stato risolto utilizzando DNS? Hai apportato modifiche al DNS? Quel tipo di informazione.

Probabilmente è meglio se sostituisci i tuoi nomi host e IP con esempi (example.com, example.net, example.org e anything-you-want.test sono utili per nomi host, IP privati ​​come 192.168.foo.bar o 10.foo.bar.baz sono utili per gli IP), in questo modo l'output del comando è più facile da interpretare. Puoi anche usarlo per indicare se due domini si trovano nello stesso TLD, se due IP si trovano nella stessa sottorete, ecc. Quindi è molto utile.

10
Jerome Baum

Se l'IP non è stato spostato e il pacchetto openssh-server non è stato aggiornato e viene generata una nuova chiave host, che cosa è successo?

Sebbene sia possibile disabilitare il controllo della chiave host, questa non è una pratica che vorrei iniziare.

Quello che sembra essere successo è che ssh ora sta usando un diverso sistema di chiavi host (ECDSA vs DSA o RSA) e l'avvertimento ci sta rendendo consapevoli di ciò.

5
Lars Nordin