Errore Git: "Verifica chiave host non riuscita" durante la connessione al repository remoto


223

Sto cercando di connettermi a un repository Git remoto che risiede sul mio server Web e clonarlo sulla mia macchina.

Sto usando il seguente formato per il mio comando:

git clone ssh://username@domain.com/repository.git

Questo ha funzionato bene per la maggior parte dei membri del mio team. Di solito, dopo aver eseguito questo comando, Git richiederà la password dell'utente, quindi eseguirà la clonazione. Tuttavia, durante l'esecuzione su una delle mie macchine viene visualizzato il seguente errore:

Verifica chiave host non riuscita.

fatale: impossibile leggere dal repository remoto.

Non stiamo usando le chiavi SSH per connetterci a questo repository, quindi non sono sicuro del motivo per cui Git ne sta verificando uno su questo particolare computer.


2
Si sta utilizzando SSH per connettersi a questo repository, si noti come l'URL inizia conssh://
Brandon

Ho un problema simile . Qualcuno può aiutarmi per favore? Sono bloccato :(
SepSol il

Risposte:


164

Ti stai collegando tramite il protocollo SSH, come indicato dal ssh://prefisso sull'URL del clone. Usando SSH, ogni host ha una chiave. I clienti ricordano la chiave host associata a un determinato indirizzo e si rifiutano di connettersi se una chiave host sembra cambiare. Ciò impedisce agli attacchi intermedi dell'uomo.

La chiave host per domain.com è stata modificata. Se questo non ti sembra complicato , rimuovi la vecchia chiave dalla cache locale modificando ${HOME}/.ssh/known_hostsper rimuovere la riga per domain.com o lasciando che un'utilità SSH lo faccia per te

ssh-keygen -R domain.com

Da qui, registra la chiave aggiornata eseguendola tu stesso

ssh-keyscan -t rsa domain.com >> ~/.ssh/known_hosts

o, equivalentemente, lasciare che sshlo faccia per voi la prossima volta che ti connetti con git fetch, git pullo git push(o anche una pianura ol' ssh domain.com) rispondendo Sì quando richiesto

L'autenticità dell'host "domain.com (abcd)" non può essere stabilita.
L'impronta digitale della chiave RSA è XX: XX: ...: XX.
Sei sicuro di voler continuare a connetterti (sì / no)?

Il motivo di questo prompt è domain.com non è più nel tuo known_hostsdopo averlo eliminato e presumibilmente non nel sistema /etc/ssh/ssh_known_hosts, quindi sshnon ha modo di sapere se l'host all'altro capo della connessione è davvero domain.com. (Se è stata inserita la chiave sbagliata /etc, qualcuno con privilegi di amministratore dovrà aggiornare il file a livello di sistema.)

Ti incoraggio vivamente a prendere in considerazione la possibilità di autenticare gli utenti anche con le chiavi. In questo modo, è ssh-agentpossibile archiviare il materiale chiave per comodità (piuttosto che chiunque debba inserire la propria password per ogni connessione al server) e le password non passano attraverso la rete.


3
Curiosità, l'esecuzione sudo ssh-keygen -R domain.compuò rinominare il known_hostsfile esistente known_hosts.olde creare una copia leggibile solo da root . ( -rw------- root root) Puoi facilmente chowntornare indietro all'utente appropriato, ma potresti anche sprecare un pomeriggio nel debug del motivo per cui git è rotto. : D
Andrew Rueckert,

1
Are you sure you want to continue connecting (yes/no)?. Non fare lo stesso mio errore. Devi digitare yes.
Premendo

307

Come ho già risposto in precedenza nella clonazione di repository git provoca errori - La verifica della chiave host non è riuscita. fatale: l'estremità remota si è bloccata in modo imprevisto , aggiungere GitHub all'elenco degli host autorizzati:

ssh-keyscan -t rsa github.com >> ~/.ssh/known_hosts


3
Questo è il modo più sicuro, a meno di avere già la chiave presente. Ciò presuppone che tu lo esegua una sola volta, non tutte le volte che ti connetti al server.
Zenexer,

Il repository di adattamento privato della mia azienda utilizza ecdsa come chiave, quindi se la soluzione non funziona, forse è perché l'algoritmo non è corretto
Fendy,

8
Questa dovrebbe essere la risposta accettata. Grazie per avermi salvato la giornata.
Keyur,

ha funzionato anche per me, mi chiedevo perché non potevo clonare il mio repository
StackAttack

Qualcuno ha segnalato questo post (in modo errato). Dalla recensione .
Wai Ha Lee,

55

Ho avuto il problema simile, ma, usando le chiavi SSH. Dalla risposta di Tupy, sopra, ho capito che il problema è che il file known_hosts non è presente o github.com non è presente nella lista degli host conosciuti. Ecco i passaggi che ho seguito per risolverlo:

  1. mkdir -p ~/.ssh
  2. ssh-keyscan -t rsa github.com >> ~/.ssh/known_hosts
  3. ssh-keygen -t rsa -C "user.email"
  4. aprire la chiave pubblica con questo comando $ cat ~/.ssh/id_rsa.pub e copiarla.
  5. Aggiungi la chiave id_rsa.pub all'elenco delle chiavi SSH sul tuo profilo GitHub.

1
@OJFord FYI: ho modificato la risposta originale in modo da rendere obsoleto il tuo commento. TBH e con tutto il rispetto non era del tutto corretto in primo luogo. Il touchcomando fallirebbe nel caso in cui la ~/.sshdirectory non esistesse, quindi il passaggio 1 era ancora necessario. Inoltre non è necessario touchil file prima di utilizzare il >>reindirizzamento. Se necessario, verrà creato (ma solo il file, non l'intero percorso, quindi mkdir -pè ancora necessario). L' -popzione lo fa funzionare nel caso in cui la directory esista già.
Tad Lispy,

1
È il numero 2 ssh-keyscanche manca ai documenti di Github quando si aggiunge una nuova chiave ssh.
Phil Andrews,

1
Avevo problemi con la Dockerfilemancanza di autorizzazione. L'aggiunta del secondo passaggio qui risolto questo problema! Grazie per l'ottimo lavoro
Spencer Pollock,

37

Questo sta accadendo perché github non è attualmente nei tuoi host conosciuti.

Ti verrà richiesto di aggiungere github ai tuoi host conosciuti. Se ciò non è avvenuto, è possibile eseguire ssh -T git@github.comnuovamente per ricevere il prompt.


2
Questa è la risposta giusta se non ti viene mai richiesto.
Matthias Hagemann,

15

Per me, ho dovuto digitare "sì" al prompt che chiede "Sei sicuro di voler continuare a connetterti (sì / no)?" anziché semplicemente premere Invio.


Questa risposta mi ha portato a rendermi conto che dovevo clonare manualmente il mio repository sul mio server di build per digitare "yes" e ottenere il mio server bitbucket aggiunto ai miei known_hosts
Sashah,

1
@Sashah Se tutto ciò di cui hai bisogno è il server bitbucket in known_hosts, puoi modificare il file manualmente. Non è necessario clonare il repository se questo è l'unico motivo per farlo.
Apprendista di codice

7

Ho avuto lo stesso problema su un sistema appena installato, ma questo era un problema udev. Non c'era /dev/ttynodo, quindi ho dovuto fare:

mknod -m 666 /dev/tty c 5 0

1
Ha funzionato per me perché / dev / tty è stato creato come file, molto strano! (quindi devi rimuoverlo e poi ricrearlo con mknod)
Doomsday,

@Geoffroy, ho rimosso / dev / tty e ora quando eseguo sudo, ho riscontrato questo errore: sudo: scusa, devi avere un tty per eseguire sudo
Milad,

@ xe4me Non ho mai detto che dovresti rimuoverlo, a seconda del sistema effettivamente richiesto. Il riavvio dovrebbe risolverlo.
Geoffroy,

@Geoffroy, in realtà il primo commentatore, disse che dovevo rimuovere e ricreare: d No, il riavvio non funzionava, dovevo dirlo alla radice, lo aggiustò: d
Milad

6

Se ti trovi in ​​una Intranet per ufficio (altrimenti pericolosa) che è sempre protetta dai firewall, inserisci semplicemente le seguenti righe nella tua ~ / .ssh / config

Host *
StrictHostKeyControllo no
UserKnownHostsFile = / dev / null


2
Questo è ancora pericoloso, con i nostri firewall senza aziende. Come fai a sapere che stai parlando con il vero github senza verificare la chiave del server?
Mnebuerquo,

1
Negli ambienti aziendali i repository git locali sono utilizzati principalmente, mai uno open source. Nel peggiore dei casi, la configurazione .ssh nella parte superiore del file può avere linee di configurazione relative all'host esplicito github affinché ssh scelga corrispondenze più specifiche.
domenica

5

Quello che ha funzionato per me è stato aggiungere prima la mia chiave SSH del nuovo computer, ho seguito queste istruzioni da GitLab: aggiungi la chiave SSH . Nota che da quando sono su Win10, ho dovuto eseguire tutti questi comandi in Git Bash su Windows (non funzionava nella normale shell cmd DOS).

Poi di nuovo in Git Bash, ho dovuto fare uno git clonedei repository con cui avevo problemi, e nel mio caso ho dovuto clonarlo con un nome diverso poiché lo avevo già localmente e non volevo perdere i miei impegni. Per esempio

git clone ssh://git@gitServerUrl/myRepo.git myRepo2

Quindi ho ricevuto la richiesta di aggiungerlo all'elenco degli host conosciuti, la domanda potrebbe essere questa:

Sei sicuro di voler continuare a connetterti (sì / no)?

Ho digitato "sì" e alla fine ha funzionato, in genere dovresti ricevere un messaggio simile a questo:

Avviso: aggiunto in modo permanente "[il tuo repo link]" (ECDSA) all'elenco degli host conosciuti.

Nota : se sei su Windows, assicurati di usare Git Bash per tutti i comandi, questo non ha funzionato nella normale shell cmd o powershell, in Git Bash dovevo davvero farlo.

Alla fine ho cancellato il secondo repository clone ( myRepo2nell'esempio) e sono tornato al mio primo repository e finalmente ho potuto fare tutte le cose di Git come normali nel mio editor preferito VSCode.


In effetti, il mio prompt di Cygwin sembra quasi esattamente come il mio prompt di Git Bash, ma funziona solo nel prompt di Git Bash!
Josiah Yoder,

3

Se stai usando git per Windows.

  • Apri la GUI di git.
  • Aprire il repository git locale nella GUI di git.
  • Aggiungi il telecomando o premi se il telecomando esiste già.
  • Rispondi "sì" alla domanda se vuoi continuare.

Il client della GUI aggiunge la chiave per te ~/.ssh/known_hosts. Questo è più facile da ricordare se non lo fai spesso ed evita anche la necessità di utilizzare la riga di comando git (le righe di comando standard di Windows non hanno l' ssh-keyscaneseguibile.


2

Quando il server remoto vuole connettersi al repository privato, si autenticherà tramite ssh. Crea la coppia di chiavi privata-pubblica con ssh-keygen o se hai già la chiave pubblica-privata. copia e incolla la chiave pubblica nelle Impostazioni del repository privato.

YourPrivateRepo -> Impostazioni -> Distribuisci chiavi -> Aggiungi chiave di distribuzione -> Incolla la chiave pubblica.

Ora il server remoto sarebbe in grado di connettersi al repository privato.

NOTA: le chiavi di distribuzione hanno accesso solo per la lettura del repository. È necessario consentire esplicitamente l'accesso in scrittura.


1

Significa che la chiave dell'host remoto è stata modificata (potrebbe essere la modifica della password dell'host),

Il tuo terminale ha suggerito di eseguire questo comando come utente root

$ ssh-keygen -f "/root/.ssh/known_hosts" -R [www.website.net]

Devi rimuovere quel nome host dall'elenco degli host sul tuo PC / server. Copia quel comando suggerito ed eseguilo come utente root.

$ sudo su                                                        // Login as a root user

$ ssh-keygen -f "/root/.ssh/known_hosts" -R [www.website.net]    // Terminal suggested command execute here
Host [www.website.net]:4231 found: line 16 type ECDSA
/root/.ssh/known_hosts updated.
Original contents retained as /root/.ssh/known_hosts.old

$ exit                                                           // Exist from root user

Riprova, spero che funzioni.


Nota: a seconda della shell, potrebbe essere necessario sfuggire alle parentesi quadre \ [e \] o utilizzare le virgolette.
Phlarx,

1

Quando viene richiesto:

Are you sure you want to continue connecting (yes/no)?

Digitare yes come risposta

È così che ho risolto il mio problema. Ma se provi a premere semplicemente il pulsante Invio, non funzionerà!


0

Puoi usare il tuo "git url" nel formato URL 'https "nel file Jenkins o dove vuoi.

git url: 'https://github.com/jglick/simple-maven-project-with-tests.git'


0

Ho riscontrato lo stesso errore all'interno di DockerFile durante la fase di creazione mentre l'immagine era pubblica. Ho apportato poche modifiche a Dockerfile.

 RUN git clone  https://github.com/kacole2/express-node-mongo-skeleton.git /www/nodejs

Questo perché usando git@github.com: ... la sintassi finisce> usando SSH per clonare, e all'interno del contenitore, la tua chiave privata non è> disponibile. Dovrai invece utilizzare RUN git clone> https://github.com/edenhill/librdkafka.git .


-1

Ho avuto il problema simile, purtroppo ho usato l'HMI GitExtensions e ho dimenticato di aver scritto una passphrase. Con HMI .... dimenticalo! Non inserire la passphrase quando generi la tua chiave!


-4

Ho ricevuto questo messaggio quando ho provato a git cloneun repository che non era mio. La correzione consisteva nel fork e quindi nel clonare.

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.