Git dice "Avviso: aggiunto permanentemente all'elenco degli host conosciuti"


192

Ogni volta che utilizzo git per interagire con un telecomando, ad esempio quando tira o spinge, mi viene mostrato il seguente messaggio:

Avviso: aggiunto in modo permanente '...' (RSA) all'elenco degli host conosciuti.

Come posso impedire la visualizzazione di questo fastidioso messaggio? È solo un fastidio: tutto funziona correttamente.


1
Intendi davvero ogni volta? Ti sta dando un prompt del modulo The authenticity of host '...' can't be established. RSA key fingerprint is .... Are you sure you want to continue connecting (yes/no)?o l'hai soppresso? Se lo è, è sempre la stessa impronta digitale? In caso contrario, è davvero spaventoso . L'opzione meno spaventosa sarebbe che in qualche modo non riesca effettivamente a scrivere nel file hosts, quindi riprova ogni volta. Dai un'occhiata ~/.ssh/known_hosts?
Cascabel,

1
Sì. <i> Ogni </i> volta. Tuttavia, non vedo il messaggio "Sei sicuro ..." - forse l'ho soppresso.
Donald Taylor,

L'host è elencato in ~/.ssh/known_hosts? (È elencato 5000 volte?) Esiste ~/.ssh/config/ contiene qualcosa (in particolare un valore per StrictHostKeyChecking)?
Cascabel,

L'host è elencato in quel file una volta ed è l'unica voce.
Donald Taylor,

2
Immagino che il contenuto del tuo known_hostsfile sia negativo. Dovrebbe essere la chiave host, su una linea terribilmente lunga. Se hai solo il nome host lì (ad esempio) non funzionerà. Ti consiglio di rimuovere questo file (se effettivamente contiene solo le informazioni per questo singolo host) e consentire a SSH di crearlo la prossima volta che ti connetti. Dopo dovrebbe essere silenzioso.
tripleee,

Risposte:


240

Soluzione: creare un ~/.ssh/configfile e inserire la riga:

UserKnownHostsFile ~/.ssh/known_hosts

Vedrai quindi il messaggio la prossima volta che accedi a Github, ma successivamente non lo vedrai più perché l'host viene aggiunto al known_hostsfile. Questo risolve il problema, piuttosto che nascondere il messaggio di registro.

Questo problema mi stava infastidendo da un po 'di tempo. Il problema si verifica perché il client OpenSSH compilato per Windows non controlla il file known_hosts~/.ssh/known_hosts

ssh -vvvvvvvvvvvvvvvvvvv git@github.com

debug3: check_host_in_hostfile: filename /dev/null
debug3: check_host_in_hostfile: filename /etc/ssh/ssh_known_hosts
debug3: check_host_in_hostfile: filename /dev/null
debug3: check_host_in_hostfile: filename /etc/ssh/ssh_known_hosts
Warning: Permanently added 'github.com,207.97.227.239' (RSA) to the list of known hosts.

9
Sì, non considero sopprimere avvisi o errori come una soluzione adeguata a un problema. ;)
Jeremiah Gowdy,

1
di recente, ho riscontrato lo stesso problema sulla mia macchina Ubuntu. Ha iniziato a comportarsi in questo modo dopo aver usato una chiave diversa (dalla mia impostazione predefinita ~/.ssh/id_rsa) per connettersi a un server. Come ho già detto @JeremiahGowdy debug3: load_hostkeys: loading entries for host "172.16.3.101" from file "/dev/null". Perché SSH inizia a utilizzare /dev/nullcome known_hosts dopo aver modificato la chiave?
m-ric,

6
Funziona alla grande! Alla fine lo stupido avvertimento si interruppe. A proposito su Windows, ~in ~/.ssh/configè la cartella principale dell'utente. Per aprirlo facilmente, premi Win-R , digita cmd Invio . Il prompt dei comandi dovrebbe già essere aperto nella cartella principale. Digitare cd .ssh Invio , quindi start . Invio per aprire la cartella in Esplora risorse. Quindi è possibile creare il file di configurazione in Blocco note (nessuna estensione .txt durante il salvataggio). (Gli utenti Pro possono eseguire l'eco direttamente su un nuovo file nel prompt dei comandi stesso ;)). Esegui un comando git che coinvolge il telecomando due volte (come git fetch) e il gioco è fatto.
ADTC

1
perché hai 20 v per ssh?
bubakazouba,

3
@bubakazouba Più v, più il registro è dettagliato, controlla i documenti per quello. Tre sarebbero sufficienti, venti sono un eccesso: D
Petr Mánek,

90

Aggiungi la seguente riga al tuo file di configurazione ssh ($ HOME / .ssh / config):

LogLevel=quiet

Se si esegue ssh dalla riga di comando, aggiungere la seguente opzione alla stringa di comando:

-o LogLevel=quiet

Ad esempio, quanto segue stampa la versione di gcc installata su machine.example.org (e nessun avviso):

ssh -o UserKnownHostsFile=/dev/null \
    -o StrictHostKeyChecking=no \
    -o LogLevel=quiet \
    -i identity_file \
    machine.example.org \
    gcc -dumpversion

1
L'aggiunta di "LogLevel = quiet" al file "config" ha funzionato. Grazie.
Donald Taylor,

3
Per mantenere la sicurezza, sarebbe bene inserire "LogLevel = quiet" all'interno di una sezione "Host".
Joe,

39
LogLevel=quietè una cattiva idea, vuole che vengano visualizzati tutti gli errori, vuole solo evitare questo specifico odioso errore. Probabilmente perché ha ingannato ssh da usare /dev/nullcome known_hostsfile, probabilmente perché voleva disattivare il known_hostscontrollo delle impronte digitali, ma non poteva, perché i signori ssh non glielo permettevano.
Elazar Leibovich,

@bukzor loglevel=errorvisualizza ancora "Connessione a <server> chiusa" quando la connessione viene interrotta, il che è davvero fastidioso per gli script.
Guss,

Ho annullato il voto in quanto non risolve davvero il problema. Lo nasconde e basta.
alaboudi,

60

Impostare LogLevelsu ERROR(non QUIET) nel ~/.ssh/configfile per evitare di vedere questi errori:

Host *
   StrictHostKeyChecking no
   UserKnownHostsFile /dev/null
   LogLevel ERROR

2
Nel mio caso ha funzionato meglio, oppure puoi specificare "-oLogLevel = ERROR" sulla riga di comando
Brad

5

Quel messaggio proviene da SSH, che ti avverte che ti stai connettendo a un host a cui non ti sei mai connesso prima. Non consiglierei di disattivarlo, poiché significherebbe che potresti perdere un avviso sulla modifica di una chiave host, che può indicare un attacco MITM sulla tua sessione SSH.


1
Ma mi collego ad esso 10-15 volte ogni giorno e continuo a ricevere questo avviso.
Donald Taylor,

@JackB. Guarda ~/.ssh/known_hostse vedi se il tuo host è lì.
Borealid,

La chiave sta cambiando per qualche motivo? Controllare l'impronta digitale nel file rispetto all'impronta digitale generata da ssh. Inoltre, la modalità della directory .ssh è impostata su 0700?
Jason Carreiro,

2
@JasonCarreiro, sono un ragazzo grande, so che nessuno tirerà l'attacco MITM nel mio rack, la sicurezza è un compromesso e voglio che i nuovi computer funzionino immediatamente con la chiave già condivisa, senza la necessità di gestire una CA o ssh-keyscan.
Elazar Leibovich,

4

Per eliminare i messaggi di avviso, sshè possibile aggiungere le seguenti righe a ~/.ssh/config:

Host *
LogLevel error

Ciò disabiliterà gli avvisi ma non i messaggi di errore. Come le altre impostazioni in ~/.ssh/configè possibile configurare il LogLevelsu base per host se si desidera un controllo più preciso.


2

Significa principalmente che ci sono cambiamenti per la chiave per quell'host ~/.ssh/known_hostse non lo aggiorna automaticamente. Pertanto ogni volta che ricevi questo messaggio di avviso.

Ciò accade spesso per la connessione alle macchine virtuali ricreate, che modifica la chiave con lo stesso indirizzo IP

Soluzione

Se hai una sola voce, puoi eliminare ~/.ssh/known_hosts file e, dopo la prima connessione, che la chiave sarà lì e nessun messaggio di avviso dopo quello.

Se si dispone di più voci, è possibile utilizzare il comando seguente per rimuovere

$ ssh-keygen -R <hostname>

Funziona bene per me


0

Se stai usando un repository da GitHub, considera invece di utilizzare la versione HTTPS dell'URL, per eludere completamente questo problema:

Fai clic sul pulsante HTTP e clona invece quell'URL

Se cloni il tuo repository dall'applicazione Windows GitHub, questo è ciò che utilizza per l'URL remoto. Forse sanno qualcosa che non sappiamo.


Nota: se si utilizza l'autenticazione con chiave privata, non è possibile utilizzare HTTP (S).
qwertzguy,

0

Ho la stessa domanda e ho scoperto che non c'è un .sshfile nel mio ~. Quindi creo solo la .sshdirectory sotto il ~percorso e il problema è stato risolto.



0

Aggiungi chiave ssh

ssh-keygen -t rsa -b 4096 -C "abc@abc.com"

eval "$(ssh-agent -s)"

ssh-add ~/.ssh/bitbucket_rsa

file di configurazione della cassa

crate ~/.ssh/config

aggiungi sotto la riga.

UserKnownHostsFile ~/.ssh/known_hosts

Quindi aggiungi la chiave pub e clona il tuo repository ... Fatto .....


0

Avevo riscontrato lo stesso errore nella VM del sistema operativo Linux / Cent ed era perché l'IP stava cambiando dopo il riavvio. Per ovviare a questo problema, ho definito un IP statico nella rete e ho aggiunto quella voce al file / etc / hosts. Per l'IP statico menzionare un valore di intervallo leggermente superiore. Ad esempio, se il tuo IP corrente (ipconfig / ifconfig) è 192.168.0.102, la prossima volta dopo il riavvio potrebbe diventare 192.168.0.103. Quindi definisci il tuo IP statico nelle impostazioni IPV4 come 192.168.0.181 che dovrebbe fare il trucco.


cerca di evidenziare le parole chiave e di essere chiaro con il formato che ti aiuterà a raggiungere la tua risposta per gli altri
Agilanbu,

0

Nel mio caso, è stato perché l'amministratore che ha impostato il server ha impostato queste opzioni ~/.ssh/config

StrictHostKeyChecking no
UserKnownHostsFile /dev/null

Che ha funzionato bene per la maggior parte dei casi non usando il ~/.ssh/known_hostsfile. Ma per il repository gitlab aziendale, ogni volta che dava "Avvertenza: aggiunto in modo permanente ... all'elenco di host noti".

La mia soluzione è stata quella di commentare la UserKnownHostsFile /dev/nulllinea, che ha permesso la creazione di ~/.ssh/known_hosts. Quindi non ha dato altri avvertimenti dopo quello.

Potresti anche avere voci vecchie / non valide nel tuo known_hosts.

# find entry in ~/.ssh/known_hosts
ssh-keygen -F <hostname>

# delete entry in ~/.ssh/known_hosts
ssh-keygen -R <hostname>

0

aggiungi la tua chiave privata a ssh-agent con:

ssh-add ~/.ssh/id_rsa

-1

Sto eliminando la mia soluzione a causa di continui downvotes.
Era la soluzione migliore senza effettivamente hackerare il codice sorgente del client SSH stesso.
Se qualcuno è interessato, controlla la cronologia delle modifiche.

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.