"Aggiungi la chiave host corretta in known_hosts" / più chiavi host ssh per nome host?


147

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?


9
Questa è la chiave host che sta generando l'errore. Un host dovrebbe avere una sola chiave. Questo non ha nulla a che fare con le chiavi client o utente. Hai un indirizzo IP che galleggia tra host distinti o qualcosa del genere?
David Schwartz,

4
Nel mio caso so che passerò molto tra i due tasti nel prossimo futuro mentre giocherò con alcune cose. Sembra che ciò sarebbe utile anche nell'unico IP con la situazione di più host che suggerisci. Principalmente voglio solo sapere se questo è possibile per la mia educazione oltre a qualsiasi applicazione pratica particolare.
Samuel Edwin Ward,

Risposte:


148
  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)
    

12
Questo ha funzionato! Tuttavia, sto usando "HashKnownHosts", quindi la voce sembrava un po 'fuori posto. Fortunatamente ssh_config (5) mi ha indicato ssh-keygen (1) che ha spiegato che posso usare "ssh-keygen -H" per eseguire l'hashing delle voci non cancellate. Grazie!
Samuel Edwin Ward,

2
Questo "funziona" ma non stai verificando la chiave, quindi sei vulnerabile agli attacchi di mitigazione ...
JasperWallace,

3
@JasperWallace, fintanto che il primo passo viene effettuato tramite una connessione protetta (ad esempio utilizzando localhost) dovrebbe essere piuttosto sicuro, credo
solo il

3
C'è un modo per raccogliere tutti i tipi di chiave dal server? A volte non sai se sono RSA, DSA, ECDSA, RSA1 ... ecc.
Sopalajo de Arrierez

3
@SopalajodeArrierez la stessa manpage dice anche che puoi separare i tipi con virgole, quindi fallo ssh-keyscan -t rsa1,dsa,rsa,ecdsa,ed25519 server_ip- ma l'unica ragione per trovare rsa1e le dsachiavi è identificare i server che devono essere aggiornati / riconfigurati
kbolino,

94

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).


11
"come aggiungere la nuova chiave host senza rimuovere quella precedente."
Samuel Edwin Ward,

4
Questa è la soluzione migliore!
Thomas Decaux,

8
In che modo questo ha 19 voti? Non si avvicina a rispondere alla domanda posta ...
Molomby,

2
La tua domanda viene in secondo luogo quando cerco su Google "git ssh aggiorna automaticamente la chiave host". Questa risposta è ciò che stavo cercando. Aprire una nuova domanda con esattamente quello che voglio potrebbe chiuderlo come duplicato.
Jason Goemaat,

Anche l'
hostname

18

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


Questa "fusione"? meldmerge.org
Samuel Edwin Ward

è la fusione :) apt-get / yum Il nome dell'installazione è semplicemente combinato
Segna

Ho fatto una variante del tuo suggerimento che ha funzionato bene - invece di cp, mv, quindi ssh, quindi cat ~ / .ssh / known_hosts.bak ~ / .ssh / known_hosts> tmp; mv tmp ~ / .ssh / known_hosts
Peter N Lewis,

6

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.


1
La gente di OpenSSH è diventata saggia con me, questa scappatoia non funziona più nelle versioni più recenti.
Mike,

Puoi usare CheckHostIP noin ~/.ssh/configper poter ancora usare la scappatoia. Puoi anche definire i tuoi alias lì in modo da non dover giocherellare /etc/hostse definire CheckHostIP nosolo per questi 3 nomi host.
GnP,

3

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.


Questa è di gran lunga la risposta più utile! Sebbene non offra esplicitamente un modo per risolvere la domanda originale se una chiave host era già stata modificata, tutte le altre risposte non sono sicure poiché non verificano la nuova chiave host. Questa opzione consente di eseguire il rollover sicuro su nuove chiavi host.
Jaap Eldering,

1

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

StrictHostKeyChecking non sembra aiutare in questo caso; apparentemente specifica solo il comportamento quando l'host non si trova nel file known_hosts. Citato qui: gossamer-threads.com/lists/openssh/dev/45349#45349
Samuel Edwin Ward,

Funziona qui Riceverai l'avviso, ma il login continua.
Sven

È strano. Stai utilizzando l'autenticazione con password? Stai usando OpenSSH?
Samuel Edwin Ward,

1

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!


4
Se si cancella l'intero known_hostsfile ogni volta, si annullerà la maggior parte della sicurezza fornita da ssh.
Kasperd,

Anzi, direi che su una rete interna sicura, è più sicuro capire il tuo codice e aggirare la sicurezza piuttosto che copiarlo senza pensarci. Su una rete esterna la situazione sarebbe diversa.
Aaron,

-1

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.


-3

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.


2
Alcune ulteriori informazioni sul perché ciò accada sarebbero utili alla risposta.
Ha disegnato Khoury

-4

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


4
"Ma quello che vorrei è che ssh accettasse sia la vecchia chiave che la nuova chiave." La tua risposta non lo fa.
Samuel Edwin Ward,
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.