Sto provando a scrivere su un computer che controllo, ricevo il messaggio familiare:

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    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 RSA key sent by the remote host is
[...].
Please contact your system administrator.
Add correct host key in /home/sward/.ssh/known_hosts to get rid of this message.
Offending RSA key in /home/sward/.ssh/known_hosts:86
RSA host key for [...] has changed and you have requested strict checking.
Host key verification failed.

Ho davvero cambiato la chiave. E ho letto alcune decine di post che affermano che il modo per risolvere questo problema è eliminare la vecchia chiave dal known_hostsfile.

Ma quello che vorrei è che ssh accettasse sia la vecchia chiave che la nuova chiave. La lingua nel messaggio di errore (" Add correct host key") suggerisce che dovrebbe esserci un modo per aggiungere la chiave host corretta senza rimuovere quella precedente.

Non sono stato in grado di capire come aggiungere la nuova chiave host senza rimuovere quella precedente.

Questo è possibile o il messaggio di errore è semplicemente fuorviante?

1. ottenere la chiave rsa del server, dove si server_iptrova l'indirizzo IP del server, ad esempio 192.168.2.1:

   $ ssh-keyscan -t rsa server_ip
   

   Risposta del campione:

   # server_ip SSH-2.0-OpenSSH_4.3
   server_ip ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAwH5EXZG...
   

2. e sul client, copia l'intera riga di risposta server_ip ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAwH5EXZG...e aggiungi questa chiave in fondo al tuo ~/.ssh/known_hostsfile:

   server_ip ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAqx9m529...(the offending key, and/or the very bottom of the `known_hosts` file)
   server_ip ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAwH5EXZG... (line you're adding, copied and pasted from above)
   

Rimuovere la voce da known_hosts utilizzando:

ssh-keygen -R *ip_address_or_hostname*

Ciò rimuoverà l'IP o il nome host problematico dal file known_hosts e tenterà di riconnettersi.

Dalle pagine man:

-R hostname
Rimuove tutte le chiavi appartenenti al nome host da un file known_hosts. Questa opzione è utile per eliminare gli host con hash (vedi l'opzione -H sopra).

Un modo molto semplice è:

cp ~/.ssh/known_hosts ~/.ssh/known_hosts.bak

Quindi modifica known_hosts per cancellare la chiave originale, quindi ssh sull'host usando:

ssh name@computer

Aggiungerà automaticamente la nuova chiave; quindi confrontare i due file. Un programma come Meld è un buon modo per confrontare i due file. Quindi unire i file per far sì che known_hosts contenga entrambe le chiavi

La mia "ragione" per mantenere due chiavi è che il sistema di destinazione è multiboot, anche se oso dire che c'è un modo di sincronizzare le chiavi attraverso le installazioni, sembra più semplice consentire più chiavi.

MODIFICA 2015/06

Dovrei aggiungere, rivisitandolo ora, che noto un modo ancora più semplice [purché la voce sia identificabile, normalmente dal nome host / indirizzo IP piuttosto a parte il messaggio di errore che fa riferimento alla sua posizione specifica];

1. Modifica known_hosts per aggiungere temporaneamente # all'inizio della voce "old" in known_hosts
2. Connetti [ssh all'host], accetta la richiesta di aggiungere 'automaticamente' la nuova chiave
3. Quindi modificare di nuovo known_hosts per rimuovere il #

C'è anche l'opzione HostKeyAlias ​​come in

ssh -o HostKeyAlias=mynewaliasforthemachine name@computer

successivamente, dopo che il client ssh ha aggiunto la nuova chiave sotto l'alias, è possibile modificare known_hosts per sostituire il nome host / indirizzo IP "reale" per l'alias o connettersi sempre a quella incarnazione di quell'host con l'opzione alias

Ho lo stesso problema con un raspberry pi che avvio con diversi sistemi (sistema dev per la compilazione di binari arm, project, xbmc, ecc.) E ho riscontrato lo stesso problema. Usano DHCP su una rete locale e il mio router ha sempre riutilizzato lo stesso IP poiché l'indirizzo MAC era lo stesso. L'ho risolto usando nomi di dominio diversi nel mio file hosts:

10.10.10.110 pi-dev
10.10.10.110 pi-xbmc
10.10.10.110 pi-etc

Il file known_hosts salva le impronte digitali in base al nome host, quindi anche se è lo stesso indirizzo IP, ogni nome host univoco ottiene una voce diversa.

Mi sono stancato di aggiungere i nomi ai file host ogni volta che ho usato un nuovo sistema, quindi ho trovato un modo ancora più pigro usando zeri iniziali su indirizzi IP come:

$ ssh pi@10.10.10.110
$ ssh pi@010.10.10.110
$ ssh pi@10.010.10.110

Ogni variazione dell'indirizzo IP (non canonico) ottiene la propria voce in known_hosts.

Se sia il tuo client che il tuo server hanno OpenSSH 6.8 o versioni successive, puoi usare l' UpdateHostKeys yesopzione nel tuo ssh_configo ~/.ssh/config. Per esempio:

Host *
    UpdateHostKeys yes

Questo fa sì che SSH memorizzi tutte le chiavi host che il server deve known_hostse, quando un server cambia o rimuove una chiave host, anche la chiave viene cambiata o rimossa nel tuo known_hosts.

Non vedo perché vuoi lavorare con due chiavi, ma puoi sicuramente aggiungere più di una chiave valida al ~/.ssh/known_hostsfile, ma dovrai farlo manualmente.

Un'altra soluzione potrebbe essere quella di utilizzare l' StrictHostKeyChecking=noopzione per questo host specifico:

ssh -o StrictHostKeyChecking=no user@host

che potresti inserire in un alias nel tuo ~/.profileo qualcosa di simile.

alias hc=ssh -o StrictHostKeyChecking=no user@host

Se sei solo su una rete locale, allora ...

Una soluzione semplice è cancellare il vecchio file chiave e sostituirlo con uno vuoto. Ciò ti consentirà di autorizzare nuovamente tutte le tue connessioni con nuove chiavi. Se hai chiavi ssh memorizzate per siti esterni alla tua rete locale, devi assicurarti che la tua connessione iniziale sia sicura come hai fatto la prima volta che ti sei connesso a quel server.

per esempio

cp known_hosts known_hosts.old
rm known_hosts
nano known_hosts

Quindi premere spazio, backspace cntl + xe 'y' per salvare il nuovo buffer (file). È una cattiva pratica, ma va bene fornire che non si sta regolarmente lanciando fuori dalla rete locale (ad es. Un server uni o di lavoro)

Su una rete locale sicura questo è sicuro perché non puoi semplicemente ottenere un uomo in mezzo all'attacco.

È sempre meglio usare il codice che capisci!

Così tante risposte, ma così tante che rinunciano alla protezione disattivando totalmente il controllo rigoroso dell'host, o distruggendo informazioni sull'host non correlate o costringendo l'utente ad accettare interattivamente le chiavi, possibilmente in un momento successivo, quando è inaspettato.

Ecco una semplice tecnica che ti consente di lasciare il controllo rigoroso dell'host, ma aggiorna la chiave in modo controllato, quando prevedi che cambi:

• Rimuovi la vecchia chiave e aggiorna con un solo comando

  ssh-keygen -R server.example.com && \
      ssh -o StrictHostKeyChecking=no server.example.com echo SSH host key updated.
  

• Ripeti con gli indirizzi IP o altri nomi host se li usi.

Il vantaggio di questo approccio è che reindirizza il server esattamente una volta. La maggior parte delle versioni di ssh-keygen sembra non restituire un errore se il server che si tenta di eliminare non esiste nel file hosts noto, se questo è un problema per te, utilizzare i due comandi in sequenza.

Questo approccio verifica anche la connettività ed emette un bel messaggio per i log nel comando ssh (che accede, aggiorna la chiave host e restituisce la chiave host SSH aggiornata, quindi esce immediatamente.

Se la tua versione di ssh-keygen restituisce un codice di uscita diverso da zero e preferisci gestirlo senza errori, indipendentemente dalla connessione precedente, utilizza semplicemente i due comandi in sequenza, ignorando eventuali errori nel comando ssh-keygen.

Se si utilizza questa tecnica, non è mai necessario variare il comando ssh o disattivare il controllo host tranne durante quel comando ssh. Puoi essere sicuro che le future sessioni di ssh funzioneranno senza conflitti o dovranno accettare esplicitamente una nuova chiave, purché il comando ssh sopra sia stato eseguito senza errori.

Ho avuto lo stesso problema.

Non ho fatto altro sudo nano /home/user/.ssh/ host_allowche cancellare la chiave.

Quando sono tornato sul server ha aggiunto una nuova chiave.

Usa il comando sed per rimuovere la linea offensiva

OUTPUT: as show in above example
Offending key in /home/user/.ssh/known_hosts:86

Rimuovere la linea 86 come indicato negli host noti.

CODE: 
sed -i '86d' /home/user/.ssh/known_hosts

La prossima volta quando si accede usando ssh, il sistema aggiungerà automaticamente una nuova chiave.

versioni più recenti di ssh

uso:

ssh-keygen -R <hostname|ip address>

Rimuoverà la voce del nome host e prenderà il backup di vecchio .known_hostcomeknown_hosts.old