Come correggere gli avvisi sulla chiave host ECDSA


288

Sto cercando di installare SSH senza password su un server Ubuntu con ssh-copy-id myuser@myserver, ma sto ottenendo l'errore:

Avvertenza: la chiave host ECDSA per "myserver" differisce dalla chiave per l'indirizzo IP "192.168.1.123"

Cosa sta causando questo e come posso risolverlo? Ho provato a eliminare la .sshdirectory sul computer remoto, ed eseguendo ssh-keygen -R "myserver"localmente, ma questo non risolve l'errore.


nel mio caso, cambio il bind del server (ip) con il dominio, quindi il The ECDSA host key for server has changed. La mia strada è rimuovere la stringa di cache relativa sul dominio in ~/.ssh/known_hosts. Quindi funziona ssh.
Ninja,

Risposte:


417

Rimuovere la chiave memorizzata nella cache per 192.168.1.123sul computer locale:

ssh-keygen -R 192.168.1.123

14
Non ha funzionato per me sul server Debian appena installato al lavoro quando SSHing da casa. Inoltre, la risposta è piuttosto concisa.
Chris K,

/home/wf/.ssh/known_hosts aggiornato. Contenuti originali mantenuti come /home/wf/.ssh/known_hosts.old "Avviso: aggiunta permanente della chiave host ECDSA per l'indirizzo IP 'xxxx' all'elenco di host noti." È visualizzato. e poi sembra funzionare
Wolfgang Fahl il

13
È possibile aggiornare la chiave invece di rimuoverla. Utilizzare ssh-keyscan -t ecdsa my.server.domain >> ~/.ssh/known_hostsdopo che non è necessario verificare la nuova chiave all'inizio connettersi all'host.
Alex,

2
Per chi non riesce a farlo funzionare: ho registrato più occorrenze dello stesso IP: 1 / detto indirizzo IP (xx.xx.xx.xx), dominio (tomsihap.fr), server vps fornito dal provider indirizzo (vpsxxx.ovh.net). ssh-keygen -R per ognuno di questi ha funzionato.
tomsihap,

Ha funzionato per me, ma la confusione potrebbe essere da quale host dovrebbe essere eseguito questo comando? La risposta proviene da quella che ha mostrato l'errore. La seconda domanda e risposta sono più ovvie, ma per ogni evenienza: quale indirizzo passare a ssh-keygen -R? L'indirizzo che figura nella dichiarazione di errore.
Russ Bateman,

63

Nel mio caso ssh-keygen -R ...non è stato corretto l'avviso. Ho avuto informazioni extra come questa:

Offending key for IP in /home/myuser/.ssh/known_hosts:8
Matching host key in /home/myuser/.ssh/known_hosts:24

Ho semplicemente modificato ~/.ssh/known_hostsed eliminato manualmente la riga 8 (la "chiave offensiva"). Ho provato a ricollegarmi, l'host è stato aggiunto in modo permanente e dopo tutto è andato bene!


2
Funziona come un fascino. È possibile risolvere il problema in una riga con sed -e '8d' /home/myuser/.ssh/known_hosts, sostituendo il numero di riga 8e il nome file con quelli visualizzati sul sistema.
Alex P. Miller,

Il mio problema con questo approccio era che è un po 'confuso se si known_hosts:8riferisce a un valore con indice zero o meno. Buono a sapersi che è una mappatura 1: 1 ...
Daniel F

Ho notato che questo succede se usi una porta non standard come il 2022. In tal caso, devi farlossh-keygen -R [hostname]:2022
Alexander Malfait il

Se cancello ~/.ssh/known_hosts, ricevo il messaggio che non è possibile stabilire l'autenticità e "Sei sicuro di voler continuare a connetterti". Rispondere "Sì" tenta e non riesce a connettersi. Se provo a connettermi una seconda volta, ottengo lo stesso errore della chiave host ECDSA con cui ho iniziato.
Aaron Franke

19

Faccio molte ricerche tra i miei computer LAN e i miei due account di web hosting, quindi ho risolto tutti i tipi di probabilità e termina con SSH, compresi i problemi di autenticazione ssh -vper vedere dove e cosa è andato storto.

Avendo appena risolto questo problema e non essere soddisfatto delle risposte, volevo davvero sapere "perché" me stesso ...

Il trigger per il mio caso è: installato il nuovo sistema operativo del server al lavoro e al momento dell'installazione del pacchetto openssh-server, un nuovo set di chiavi host è stato generato sul server di lavoro. In precedenza, tutti i miei sistemi operativi server erano Ubuntu e questa volta è cambiato in Debian (e sospetto che ci sia una differenza sfumata nelle autorizzazioni).

Quando tutti i sistemi operativi erano Ubuntu e reinstallo il sistema operativo di un server, al primo SSH, ottengo questo tipo di avviso, che preferisco rispetto all'avviso silenzioso sopra!

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    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 the RSA host key has just been changed.
The fingerprint for the RSA key sent by the remote host is
06:ea:f1:f8:db:75:5c:0c:af:15:d7:99:2d:ef:08:2a.
Please contact your system administrator.
Add correct host key in /home/user/.ssh/known_hosts to get rid of this message.
Offending key in /home/user/.ssh/known_hosts:4
RSA host key for domain.com has changed and you have requested strict checking.
Host key verification failed.

Quindi apro ~/.ssh/known_hostssul computer l'avvio di ssh, elimino quella riga, riconnetto e questo succede:

chris@home ~ $ ssh work
The authenticity of host '[work]:11122 ([99.85.243.208]:11122)' can't be established.
ECDSA key fingerprint is 56:6d:13:be:fe:a0:29:ca:53:da:23:d6:1d:36:dd:c5.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '[work]:11122 ([99.85.243.208]:11122)' (ECDSA) to the list of known hosts.
Linux rock 3.2.0-4-amd64 #1 SMP Debian 3.2.51-1 x86_64

Quel po ': 11122 è il numero di porta da cui instrado SSH sul firewall

Ho controllato i backup da un precedente server Ubuntu e ho fatto una differenza rispetto alla mia nuova installazione Debian:

Ubuntu:                                            Debian:
# Package generated configuration file             # Package generated configuration file
# See the sshd(8) manpage for details              # See the sshd_config(5) manpage for details

# What ports, IPs and protocols we listen for      # What ports, IPs and protocols we listen for
Port 22                                            Port 22
# Use these options to restrict which interface    # Use these options to restrict which interfaces
#ListenAddress ::                                  #ListenAddress ::
#ListenAddress 0.0.0.0                             #ListenAddress 0.0.0.0
Protocol 2                                         Protocol 2
# HostKeys for protocol version 2                  # HostKeys for protocol version 2
HostKey /etc/ssh/ssh_host_rsa_key                  HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_dsa_key                  HostKey /etc/ssh/ssh_host_dsa_key
------------------------------------------------   HostKey /etc/ssh/ssh_host_ecdsa_key
#Privilege Separation is turned on for security    #Privilege Separation is turned on for security
UsePrivilegeSeparation yes                         UsePrivilegeSeparation yes

Quindi sì, probabilmente, l'host ha iniziato a usare le chiavi ecdsa di recente, che di recente in base alle modifiche di Ubuntu, darei la colpa a un aggiornamento. Il passaggio di Ubuntu dal solido sistema operativo Linux su cui ho contato è il motivo per cui ho installato Debian questa volta.

Ho letto un security.SE q / a su ecdsa e ho già rimosso quella riga dal sshd_configmio nuovo server Debian. (e corse service ssh restart)


2
+1 per il simpatico blocco di confronto side-by-side. Potresti aggiungere un URL che chiacchiera "significa che Ubuntu si allontana dal solido sistema operativo Linux"?
bgoodr,

@bgoodr è la mia opinione e si basa esclusivamente sulla configurazione del mio file server RAID più volte negli ultimi anni. : / Merda per la risposta, ma inizia a cercare su google ubuntu debian servere vedrai cosa intendo.
Chris K,

1
@ChrisK, signore, siete un capo. Grazie per la risposta dettagliata, ma concisa.
sargas,

6

Il prompt si verifica ogni volta perché gli indirizzi IP cambiano continuamente quando si utilizza l'indirizzamento dinamico. Prova a utilizzare l'IP statico, quindi devi aggiungere la chiave solo una volta.


1
Buon punto, mi sono perso dove qualcuno ha menzionato ips dinamico?
Chris K,

6

ssh-keygen -f "/root/.ssh/known_hosts" -R 192.168.1.123

Questo dovrebbe sostituire le chiavi esistenti in known_hosts.old e crearne una nuova. Questa soluzione ha funzionato per me nello stesso scenario


3

Ho aggiunto le seguenti righe al mio ~ / .ssh / config, disabilitando così il controllo rigoroso dell'host per tutti gli indirizzi .local. (con l'assegnazione dell'indirizzo DHCP, gli indirizzi IP dei miei computer locali cambiano sempre)

host *.local
    StrictHostKeyChecking no

Ricevi comunque l'avvertimento, che per me va bene.


2

Stai usando lo stesso utente per la connessione?

Se si è connessi a un PC locale come l'utente John e si è connessi al server B come l'utente Adolf @ B e tutto è OK, ciò non significa che tutto sia OK se si è connessi al PC locale come l'utente Jane e ci si connette al server B come utente Adolf @ B .

Se si desidera accedere al server B come utente Beda dal PC A senza password, provare questo comando, tutto dal PC A :

ssh-keygen -t rsa

Questo comando genera la chiave e memorizza la chiave nel file. Si prega di lasciare la passphrase vuota.

ssh Beda@B mkdir -p .ssh

Questo comando crea la directory, se non esistono già. Altrimenti, non stampare un messaggio di errore.

cd ~/.ssh

Questo comando modifica la directory nella home directory degli utenti ./ssh.

cat id_rsa.pub | ssh Beda@B 'cat >> .ssh/authorized_keys'

Questo comando stampa il file id_rsa.pub (la tua chiave pubblica) in authorized_keys sul server.

IMPORTANTE: Beda è il tuo nome utente sul server a cui ti stai connettendo, B è l'IP del tuo server.

Ora puoi connetterti al server B senza password o passphrase:

ssh Beda@B

1
O semplicemente usa ssh-copy-id per popolare un file authorized_keys con la tua chiave id_rsa.pub senza tutta la seccatura extra.
BlakBat,

1

Il thread qui può aiutare.

In sostanza, si desidera rimuovere entrambe le chiavi RSA ed ECDSA per quell'host, quindi utilizzarle ssh-keyscanper reinserirle nel known_hostsfile in modo da non causare questo conflitto. Ha funzionato per me quando ho avuto lo stesso problema.


1

Domanda: Cosa sta causando questo, ...?

Quindi la chiave host del server ssh è cambiata. Cosa ha causato il cambiamento? È difficile da dire. Ecco alcune ipotesi:

  • Sshd su myserver ha iniziato a usare le chiavi ECDSA, quindi è un nuovo tipo di chiave?
  • MyServer è stato recentemente reinstallato?
  • Recentemente è stato reinstallato sshd su myserver in modo da generare una nuova chiave host ssh?
  • Qualcuno ha rigenerato o sostituito la chiave host sshd?
  • L'indirizzo IP di myserver è cambiato in modo che un host diverso risponda a quell'indirizzo IP?

Domanda: ... e come posso ripararlo?

Come altri hanno già risposto, rimuovere la chiave host ECDSA memorizzata nella cache per myserver che il proprio account ha memorizzato nella cache.


2
Un buon consiglio, ma in realtà non risponde alla domanda. Non prova nemmeno a rispondere alla domanda.
Boatcoder

1

Questo errore mi ha infastidito per molto tempo. Per qualche ragione ha fatto la differenza se avrei fatto un

ssh host

o

ssh host.domain

https://askubuntu.com/questions/87449/how-to-disable-strict-host-key-checking-in-ssh

quindi mi ha indicato l'opzione di modificare il file di configurazione. Vedi il mio script https://askubuntu.com/a/949731/129227 lì per automatizzare il processo.


1
Utilizzando i valori di configurazione CanonicalizeHostnamee CanonicalDomainspermetterebbe di evitare la rimozione di controllo rigoroso e renderebbe ssh considerare host e host.domain ad essere lo stesso.
BlakBat,

0

L'ho risolto su un Chromebook disinstallando e reinstallando Secure Shell ... Funzionava come un fascino.


Questo è eccessivo. Vedi una soluzione più semplice nella mia risposta qui.
Alex Yursha,

0

Ecco come rimuovere un'impronta digitale host nota (dal known_hostsfile) su un sistema operativo Chrome:

Trova l'indice della voce host offensiva nell'output ssh quando la connessione non riesce. Ad esempio, nella riga sotto l'indice offensivo è 7 :

Offending ECDSA key in /.ssh/known_hosts:7

Aprire la console JavaScript ( CTRL+ Shift+ J) della finestra Secure Shell e digitare quanto segue, sostituendolo INDEXcon il valore appropriato (ad esempio 7 ):

term_.command.removeKnownHostByIndex(INDEX);

Questa soluzione è stata presa in prestito dal Blog di Leo Gaggl .

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.