2012-05-05 19:05:56 +0000 2012-05-05 19:05:56 +0000
315
315

Come correggere l'avviso sulla chiave host ECDSA

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

Attenzione: la chiave host ECDSA per ‘myserver’ differisce dalla chiave per l'indirizzo IP ‘192.168.1.123’

Cosa sta causando questo, e come posso correggerlo? Ho provato a cancellare la directory .ssh sulla macchina remota, ed eseguire ssh-keygen -R "myserver" localmente, ma questo non risolve l'errore.

Risposte (13)

459
459
459
2012-05-05 20:20:21 +0000

Rimuovere la chiave cache per 192.168.1.123 sulla macchina locale:

ssh-keygen -R 192.168.1.123
69
69
69
2014-03-11 18:52:18 +0000

Nel mio caso ssh-keygen -R ... non ha risolto il problema dell'avviso. Avevo 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
``` &001 


ho semplicemente modificato manualmente `~/.ssh/known_hosts` e cancellato la riga 8 (la "chiave offensiva"). Ho provato a ricollegarmi, l'host è stato aggiunto in modo permanente, e tutto è andato bene dopo!
19
19
19
2014-01-16 08:12:11 +0000

Faccio un sacco di ssh-ing tra i miei computer LAN e i miei due account di webhosting, quindi ho risolto tutti i tipi di problemi e finisce con SSH, compresi i problemi di autenticazione utilizzando ssh -v per vedere dove e cosa è andato storto.

Avendo appena risolto questo problema e non essendo soddisfatto delle risposte, volevo davvero sapere “perché” io stesso…

Il trigger per il mio caso è: installato un nuovo sistema operativo server al lavoro e dopo aver installato il pacchetto openssh-server, un nuovo set di chiavi host sono state generate sul server del lavoro. In precedenza, tutti i sistemi operativi del mio server erano Ubuntu e questa volta è cambiato in Debian (e sospetto che ci sia una differenza sfumata nei permessi).

Quando tutti i sistemi operativi erano Ubuntu e reinstallavo il sistema operativo di un server, al primo SSH che vi entravo, ottengo questo tipo di avviso, che preferisco all'avviso silenzioso di cui 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.
``` ```
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

Poi apro ~/. ssh/known_hosts sul computer che avvia il ssh, cancello quella linea, mi riconnetto e questo accade:

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

Quel bit circa :11122 è il numero di porta da cui instrado SSH sul firewall

Ho controllato i backup da un precedente server Ubuntu e mi sono confrontato con la mia nuova installazione di Debian:

&001

Quindi sì, probabilmente, l'host ha iniziato ad usare le chiavi ecdsa recentemente, che in base ai cambiamenti di Ubuntu ultimamente, darei la colpa ad un aggiornamento. L'allontanamento di Ubuntu dal sistema operativo linux su cui contavo è il motivo per cui ho installato Debian questa volta.

Ho letto un security.SE q/a su ecdsa e ho già rimosso quella linea da sshd_config il mio nuovo server Debian. (e ho eseguito service ssh restart)

7
7
7
2014-01-16 09:06:57 +0000

Il prompt si verifica ogni volta perché gli indirizzi IP cambiano continuamente quando si utilizza l'indirizzamento dinamico. Provate ad usare l'IP statico, quindi dovete aggiungere la chiave solo una volta.

6
6
6
2015-05-14 18:16:42 +0000

ssh-keygen -f “/root/.ssh/noti_hosts” -R 192.168.1.123

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

4
4
4
2018-03-15 12:23:28 +0000

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 delle mie macchine locali cambiano in continuazione)

host *.local
    StrictHostKeyChecking no

.

2
2
2
2014-10-21 09:17:22 +0000

Stai usando lo stesso utente per la connessione?

Se sei connesso ad un PC locale come utente John e connesso al server B come utente Adolf@B e tutto è OK, non significa che tutto è OK se sei connesso ad un PC locale come utente Jane e connesso al server B come utente Adolf@B.

Se volete effettuare il login sul server B come utente Beda dal PC A senza password, provate questo comando, tutto dal PC A:

ssh-keygen -t rsa
``` ```
ssh Beda@B mkdir -p .ssh

Questo comando genera la chiave e memorizza la chiave nel file. Lasciare passphrase vuoto.

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

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

ssh Beda@B
``` &001 


Questo comando cambia la directory in home directory degli utenti ./ssh. 



&001 &001 


Questo comando stampa il file **id\_rsa. pub** (la vostra chiave pubblica) in **authorized\_keys** sul server. 


IMPORTANTE: Beda è il vostro nome utente sul server che state collegando, B è il vostro IP del server. 


Ora, potete collegarvi al server B senza password o passphrase: 


&001
1
1
1
2012-08-07 15:42:41 +0000

Domanda: Cosa sta causando tutto questo, …?

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

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

Domanda: … e come si risolve?

Come altri hanno già risposto, rimuovere la chiave host ECDSA per myserver che il vostro account ha messo in cache.

1
1
1
2012-12-20 16:47:41 +0000

La filettatura qui può aiutare.

Essenzialmente, si desidera rimuovere sia le chiavi RSA che ECDSA per quell'host, quindi usare ssh-keyscan per rimetterle nel file known_hosts in modo da non causare questo conflitto. Per me ha funzionato quando ho avuto lo stesso problema.

1
1
1
2017-08-25 12:43:26 +0000

Questo errore mi ha dato fastidio per molto tempo. Per qualche ragione faceva la differenza se facevo un

ssh host

o

ssh host.domain

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

mi ha poi indicato la possibilità di modificare il file di configurazione. Vedere il mio script https://askubuntu.com/a/949731/129227 lì per automatizzare il processo.

0
0
0
2015-05-18 23:26:58 +0000

Ho sistemato questo su un Chromebook disinstallando e reinstallando Secure Shell… Ha funzionato a meraviglia.

0
0
0
2020-02-23 01:54:19 +0000

Al mio fianco questo accade a causa di qualcosa che considero un bug ssh dei client più recenti (OpenSSH_7.9p1 e superiori), quando si cerca di imparare una chiave server ecdsa più sicura dove è già nota una chiave di tipo rsa più vecchia. Presenta quindi questo messaggio fuorviante!

Non conosco una buona soluzione per questo, l'unica soluzione che ho trovato è quella di rimuovere tutte le “buone ma vecchie chiavi rsa” in modo che il client possa ri-imparare le “nuove chiavi ecdsa più sicure”. Quindi:

  1. Il primo passo è quello di rimuovere tutte le buone vecchie chiavi RSA ( Attenzione! Questo perde la protezione contro il MitM ):

  2. Il secondo passo poi è quello di riapprendere tutte le chiavi host, che deve essere fatto manualmente collegandosi ad ogni IP di nuovo utilizzando ssh.


Ecco quello che osservo:

$ sftp test@136.243.197.100
Connected to test@136.243.197.100
sftp> 

$ sftp test@valentin.hilbig.de
Connected to test@valentin.hilbig.de.
sftp>
``` ```
$ sftp test@gcopy.net
Warning: the ECDSA host key for 'gcopy.net' differs from the key for the IP address '136.243.197.100'
Offending key for IP in /home/test/.ssh/known_hosts:45
Matching host key in /home/test/.ssh/known_hosts:44
Are you sure you want to continue connecting (yes/no)?

Ora provate a collegarvi ad un nuovo alias di questo stesso buon server già conosciuto:

$ ssh-keygen -R 136.243.197.100
# Host 136.243.197.100 found: line 45
/home/test/.ssh/known_hosts updated.
Original contents retained as /home/test/.ssh/known_hosts.old

Si prega di dare un'occhiata all'indirizzo IP. È lo stesso IP di cui sopra! Quindi sembra che la (buona) chiave dell'IP (noto) sia improvvisamente offensiva (non lo è, in quanto il client ssh mescola due chiavi incompatibili, vedi sotto).

Ora proviamo a sistemarlo:

$ sftp test@gcopy.net
Warning: Permanently added the ECDSA host key for IP address '136.243.197.100' to the list of known hosts.
Connected to test@gcopy.net.

$ sftp test@valentin.hilbig.de
Warning: the RSA host key for 'valentin.hilbig.de' differs from the key for the IP address '136.243.197.100'
Offending key for IP in /home/test/.ssh/known_hosts:45
Matching host key in /home/test/.ssh/known_hosts:10
Are you sure you want to continue connecting (yes/no)?
``` ```
$ sftp -v test@valentin.hilbig.de

Proviamo di nuovo:

debug1: kex: host key algorithm: rsa-sha2-512

WTF? Cosa è successo qui? La nuova chiave nuova appresa dal server si guasta di nuovo? E il problema ha anche cambiato lato?

No, non è la chiave, né il server. Tutto è corretto!

È il client ssh che non riesce a verificare la chiave corretta! La voce 45 in known_hosts ora porta una chiave di tipo ecdsa-sha2-nistp256 mentre la chiave, che è stata estratta dal server dal client, è di tipo rsa-sha2-512 (e quindi non può corrispondere all'altra chiave!).

$ sftp -v test@gcopy.net
``` ```
debug1: kex: host key algorithm: ecdsa-sha2-nistp256

mostra:

Warning: the RSA host key for 'valentin.hilbig.de' differs from the key for the IP address '136.243.197.100'
Offending key for IP in /home/test/.ssh/known_hosts:45
Matching host key in /home/test/.ssh/known_hosts:10

mentre

awk 'NR==45 { print $2 }' /home/test/.ssh/known_hosts
awk 'NR==10 { print $2 }' /home/test/.ssh/known_hosts

mostra:

ecdsa-sha2-nistp256
ssh-rsa

A quanto pare il client ssh ha un bug da qualche parte! Non è in grado di gestire una chiave host esistente in più di una variante! Oppure cade nella trappola di richiedere una variante obsoleta di una chiave.

Come risolvere?

Non ne ho davvero idea. Questo probabilmente può essere risolto solo a monte.

Ma c'è una soluzione manuale ma maldestra:

Bisogna rimuovere manualmente tutte le tracce della vecchia chiave del tipo rsa. La chiave in questione è mostrata nell'uscita, ma non è segnata direttamente come il problema:

ssh-keygen -R valentin.hilbig.de
# Host valentin.hilbig.de found: line 10
/home/test/.ssh/known_hosts updated.
Original contents retained as /home/test/.ssh/known_hosts.old

controllo:

$ sftp test@valentin.hilbig.de
The authenticity of host 'valentin.hilbig.de (136.243.197.100)' can't be established.
ECDSA key fingerprint is SHA256:tf7lwe10C2p1lK2UG9p//m/4sUBCpX+i9k5Ub63c6Os.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'valentin.hilbig.de' (ECDSA) to the list of known hosts.
Connected to test@valentin.hilbig.de.
sftp> 

$ sftp test@gcopy.net
Connected to test@gcopy.net.
sftp> 

sftp test@136.243.197.100
Connected to test@136.243.197.100.
sftp>

&001 &001

Quindi qui la chiave host matching è quella offensiva e la chiave offensiva è quella giusta che deve essere tenuta! Quindi togliamo quella sbagliata (corrispondente):

&001 &001

Ora ricontrolliamo:

&001 &001

YAY! Il problema è finalmente risolto. Ma con diverse 100 voci in .ssh/known_hosts, questa “soluzione” diventa davvero una grande PITA (e un Error Prone Security Nightmare su Elm Street. YMMV.)

0
0
0
2017-07-24 07:55:39 +0000

Ecco come rimuovere un'impronta digitale nota dell'host (da file known_hosts) su un sistema operativo Chrome:

Trovare l'indice della voce host offesa nell'uscita ssh quando la connessione non riesce. Per esempio nella riga sottostante l'indice offendente è 7 :

Offending ECDSA key in /.ssh/known_hosts:7
``` ```
term_.command.removeKnownHostByIndex(INDEX);

Apri la console JavaScript (CTRL+Shift+J) della finestra Secure Shell e digita quanto segue, sostituendo INDEX con il valore appropriato (per esempio 7 ):

&001 &001

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