Ik probeer verbinding te maken met een Remote Git-repository die op mijn webserver woont en deze op mijn machine kon klonen.
Ik gebruik het volgende formaat voor mijn opdracht:
git clone ssh://[email protected]/repository.git
Dit heeft goed gewerkt voor de meeste van mijn teamleden. Meestal na het uitvoeren van deze opdracht zal Git vragen om het wachtwoord van de gebruiker en voert u vervolgens het klonen uit. Bij het uitvoeren van een van mijn machines krijg ik de volgende foutmelding:
Host-toetsverificatie mislukt.
fataal: kon niet lezen van afstandsbediening
repository.
We gebruiken geen SSH-toetsen om verbinding te maken met deze repository, dus ik weet niet zeker waarom Git er op zoek is op deze specifieke machine.
Antwoord 1, Autoriteit 100%
Zoals ik eerder in Cloning Git Repo Oorzaken Fout – Host-toetsverificatie is mislukt. FATAL: het externe einde hing onverwacht , voeg GitHub toe aan de lijst met bekende hosts:
ssh-keyscan -t rsa github.com >> ~/.ssh/known_hosts
Antwoord 2, Autoriteit 50%
U verbindt via het SSH-protocol, zoals aangegeven met de ssh://voorvoegsel op uw kloon-URL. Met SSH heeft elke host een sleutel. Klanten onthouden de hostcode die is gekoppeld aan een bepaald adres en weigeren om verbinding te maken als een hosttoets lijkt te veranderen. Dit voorkomt de mens in de middelste aanvallen.
De hostcode voor domein.com is gewijzigd. Als dit niet fishy voor u lijkt , verwijdert u de oude sleutel van uw lokale cache door ${HOME}/.ssh/known_hostste bewerken om de regel voor domein.com te verwijderen of een SSH-hulpprogramma laten doen met u
ssh-keygen -R domain.com
Neem vanaf hier de bijgewerkte toets op door het zelf te doen met
ssh-keyscan -t rsa domain.com >> ~/.ssh/known_hosts
of, equivalent, laat sshDoe het voor u de volgende keer dat u verbinding maakt met git fetch, git pull, OF git push(of zelfs een effen ol ‘ssh domain.com) door Ja te antwoorden wanneer daarom wordt gevraagd
De authenticiteit van de host 'Domain.com (A.B.C.D)' kan niet worden vastgesteld. RSA Sleutel Vingerafdruk is XX: XX: ...: xx. Weet u zeker dat u wilt doorgaan met aansluiten (ja / nee)?
De reden voor deze prompt is Domain.com is niet langer in uw known_hostsnadat u het hebt verwijderd en vermoedelijk niet in de /etc/ssh/ssh_known_hosts, dus sshheeft geen manier om te weten of de host aan de andere kant van de verbinding echt domein.com is. (Als de verkeerde toets in /etc, zal iemand met administratieve privileges het systeembrede bestand bijwerken.)
Ik moedig je sterk aan om te overwegen dat gebruikers ook met sleutels authenticeren. Op die manier, ssh-agentkan sleutelmateriaal opslaan voor gemak (in plaats van iedereen die haar wachtwoord moet invoeren voor elke verbinding met de server) en wachtwoorden niet over het netwerk.
Antwoord 3, Autoriteit 15%
Ik had het soortgelijke kwestie, maar met behulp van SSH-sleutels. Van het antwoord van Tupy, hierboven, kwam ik erachter dat het probleem is bij het bekende_hosts-bestand dat niet aanwezig is of Github.com niet aanwezig is in de lijst met bekende gastheren. Hier zijn de stappen die ik volgde om het op te lossen –
mkdir -p ~/.sshssh-keyscan -t rsa github.com >> ~/.ssh/known_hostsssh-keygen -t rsa -C "user.email"- Open de openbare sleutel met deze opdracht
$ cat ~/.ssh/id_rsa.puben kopieer het. - Voeg de ID_RSA.PUB -toets toe aan SSH-toetsenlijst op uw GitHub-profiel.
Antwoord 4, Autoriteit 11%
Dit gebeurt omdat GitHub momenteel niet in uw bekende gastheren staat.
U moet worden gevraagd om GitHub toe te voegen aan uw bekende gastheren. Als dit niet is gebeurd, kunt u ssh -T [email protected]uitvoeren om de prompt opnieuw te ontvangen.
Antwoord 5, Autoriteit 4%
Voor mij hoefde ik alleen maar “ja” in te typen bij de prompt met de vraag “Weet u zeker dat u door wilt gaan met verbinden (ja/nee)?” in plaats van gewoon op Enter te drukken.
Antwoord 6, autoriteit 2%
Als u zich op een kantoorintranet bevindt (anders gevaarlijk) dat altijd wordt beschermd door firewalls, hoeft u alleen de volgende regels in uw ~/.ssh/configte plaatsen.
Host *
StrictHostKeyChecking no
UserKnownHostsFile=/dev/null
Antwoord 7, autoriteit 2%
Ik kreeg hetzelfde probleem op een nieuw geïnstalleerd systeem, maar dit was een udev-probleem. Er was geen /dev/tty-knooppunt, dus ik moest het volgende doen:
mknod -m 666 /dev/tty c 5 0
Antwoord 8, autoriteit 2%
Wanneer gevraagd:
Are you sure you want to continue connecting (yes/no)?
Typ jaals antwoord
Zo heb ik mijn probleem opgelost. Maar als je gewoon op de enter-knop probeert te drukken, zal het niet werken!
Antwoord 9
Wat voor mij werkte, was om eerst mijn SSH-sleutel van de nieuwe computer toe te voegen, ik volgde deze instructies van GitLab – voeg SSH-sleutel toe. Merk op dat aangezien ik Win10 gebruik, ik al deze commando’s in Git Bash op Windows moest doen (het werkte niet in gewone DOS cmd Shell).
Aan de andere kant moest ik in Git Bash een git clonedoen van de repo waar ik problemen mee had, en in mijn geval moest ik het naar een andere naam klonen omdat ik het al had lokaal en wilde mijn commits niet kwijtraken. Bijvoorbeeld
git clone ssh://git@gitServerUrl/myRepo.git myRepo2
Toen kreeg ik de prompt om het toe te voegen aan de lijst met bekende hosts, de vraag zou deze kunnen zijn:
Weet u zeker dat u door wilt gaan met verbinden (ja/nee)?
Ik typte “ja” en het werkte uiteindelijk, normaal gesproken zou je een bericht moeten krijgen dat lijkt op dit:
Waarschuwing: ‘[your repo link]’ (ECDSA) permanent toegevoegd aan de lijst met bekende hosts.
Opmerking: als je Windows gebruikt, zorg er dan voor dat je Git Bash gebruikt voor alle commando’s, dit werkte niet in de gewone cmd-shell of powershell, ik moest dit echt doen in Git Bash .
Ten slotte verwijderde ik de tweede kloonrepo (myRepo2in het voorbeeld) en ging terug naar mijn eerste repo en ik kon eindelijk alle Git-dingen doen zoals normaal in mijn favoriete editor VSCode.
Antwoord 10
Als je git voor Windows gebruikt.
- Open de Git GUI.
- Open de lokale git-repository in git GUI.
- Voeg de afstandsbediening toe of druk op als de afstandsbediening al bestaat.
- Antwoord “ja” op de vraag of je wilt doorgaan.
De GUI-client voegt de sleutel voor u toe aan ~/.ssh/known_hosts. Dit is gemakkelijker te onthouden als je het niet vaak doet en vermijdt ook de noodzaak om de git-opdrachtregel te gebruiken (de standaard Windows-opdrachtregels hebben niet het uitvoerbare bestand ssh-keyscan.
Antwoord 11
Als de externe server verbinding wil maken met de privé-repo, wordt deze geverifieerd via ssh.
Maak het privé-openbare sleutelpaar met ssh-keygen of als u al over de openbaar-privésleutel beschikt. kopieer en plak de openbare sleutel in de instellingen van de privérepo.
YourPrivateRepo -> Instellingen -> Sleutels implementeren -> Implementatiesleutel toevoegen -> Plak de openbare sleutel.
Nu zou de externe server verbinding kunnen maken met de privérepo.
OPMERKING: De implementatiesleutels hebben alleen toegang voor het lezen van de repo. Moet expliciet schrijftoegang toestaan.
Antwoord 12
Ik had dezelfde fout in DockerFile tijdens het bouwen terwijl de afbeelding openbaar was. Ik heb weinig wijzigingen aangebracht in Dockerfile.
RUN git clone https://github.com/kacole2/express-node-mongo-skeleton.git /www/nodejs
Dit zou zijn omdat het gebruik van de [email protected]:… syntaxis uiteindelijk > door SSH te gebruiken om te klonen, en in de container is uw persoonlijke sleutel niet > beschikbaar. Je zult RUN git clone > https://github.com/edenhill/librdkafka.gitin plaats daarvan.
Antwoord 13
De hier genoemde oplossingen zijn geweldig, het enige ontbrekende punt is: wat als de bestandsnamen van uw openbare en privésleutel verschillen van de standaard?
Maak een bestand met de naam “config” onder ~/.ssh en voeg de volgende inhoud toe
Host github.com
IdentityFile ~/.ssh/github_id_rsa
Vervang github_id_rsadoor uw privésleutelbestand.
Antwoord 14
Dit betekent dat uw externe hostsleutel is gewijzigd (mogelijk een wijziging van het hostwachtwoord),
Uw terminal stelde voor om deze opdracht uit te voeren als rootgebruiker
$ ssh-keygen -f "/root/.ssh/known_hosts" -R [www.website.net]
Je moet die hostnaam verwijderen uit de hosts-lijst op je pc/server. Kopieer dat voorgestelde commando en voer het uit als rootgebruiker.
$ 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
Probeer het opnieuw, hoop dat dit werkt.
Antwoord 15
Je kunt https gebruiken in plaats van ssh voor git clone of git pull of git push
ex:
git clone https://github.com/user/repo.git
Antwoord 16
De reden lijkt te zijn dat de openbare sleutel van de externe host niet is opgeslagen of verschilt van de opgeslagen sleutel. (Let op beveiligingsproblemen, zie het antwoord van Greg Bacon voor details.)
Ik was gewend om git clonete gebruiken en me in dit geval te vragen:
The authenticity of host 'host.net (10.0.0.42)' can't be established.
ECDSA key fingerprint is 00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00.
Are you sure you want to continue connecting (yes/no)?
Ik weet niet zeker waarom deze fout in plaats daarvan wordt gegenereerd. Dit kan de configuratie van je shell zijn of het git SSH-commando.
Hoe dan ook, je kunt dezelfde prompt krijgen door ssh [email protected]uit te voeren.
Antwoord 17
Een ander alternatief werkte voor mij, in plaats van de SSH-link te klonen
[email protected]:upendra/mycode.git
er is een optie om http-link te selecteren
http://gitlab.company.net:8888/upendra/mycode.git
Dus ik gebruikte de http-link om te klonen voor Visual Studio en het werkte voor mij
Antwoord 18
Een kleine toevoeging aan Tupy’s antwoord, je moet mogelijk het poortnummer voor je repositoryhost toevoegen:
ssh-keyscan -p 8888 -t rsa domain.com >> ~/.ssh/known_hosts
Als je een andere machine hebt die wel externe toegang heeft, kun je het poortnummer vinden door ~/.ssh/known_hosts te bekijken:
[user]$ less ~/.ssh/known_hosts
[domain.com]:8888,[000.00.000.000]:8888 ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCi...
Antwoord 19
Als je geen Windows-sessie gebruikt om de code bij te werken, en je gebruikt PortableGit, moet je de omgevingsvariabele HOMEPATHinstellen voordat je het git-commando uitvoert.
Dit voorbeeld past beter voor ander gebruik, maar ik denk dat het een goede proof-of-concept is voor dit bericht.
$env:HOMEPATH="\Users\Administrator";C:\path\to\PortableGit\bin\git.exe -C C:\path\to\repository.git pull'
Antwoord 20
Pushing naar Git geeft foutcode 403 fataal terug: HTTP-verzoek mislukt
Controleer of er een factureringsprobleem is.
Google Cloud stopt met het uploaden van bestanden naar https://source.cloud.google.com/
Dit probleem is verdwenen nadat het betalingsprobleem was opgelost.
Maar heb de sleutels niet veranderd.
Bedankt
Antwoord 21
U kunt uw “git-url” in ‘https’-URL-indeling gebruiken in het Jenkins-bestand of waar u maar wilt.
git url: 'https://github.com/jglick/simple-maven-project-with-tests.git'
Antwoord 22
Als u MSYS2-terminals (op Windows*) en een wachtwoordzin gebruikt, kan het ook zijn dat de terminal de ‘Voer wachtwoordzin’ niet correct vraagt, waardoor de toegang tot SSH wordt geweigerd.
Als je Windows gebruikt, kun je in plaats daarvan Git Bash of Powershell gebruiken om de prompt te krijgen en op de juiste manier verbinding te maken. (Ik ben momenteel op zoek naar een oplossing voor MSYS.)
*Niet zeker of relevant.
Antwoord 23
Probleem:
Verificatie van hostsleutel mislukt.
fataal: kon niet lezen van externe repository.
Zorg ervoor dat u over de juiste toegangsrechten beschikt
en de repository bestaat.
Oplossing:ik heb alle instellingen gecontroleerd en ook de belangrijkste instellingen in GitHub. Ten slotte heb ik de Git-URL gewijzigd van "[email protected]:palvsv/travelo-moon.git"in "https://github.com/palvsv/travelo-moon.git"in .configbestand "yourprojectdirectory/.git/config"en het werkt.
Antwoord 24
Voor mij hernoem ik het bestand “bekende_hosts” naar “bekende_hosts.del” voor back-up. en voer dan git clone xxx opnieuw uit en typ “yes”. Ik zal nieuwe “bekende_hosts” maken
Antwoord 25
Controleer ook de machtigingen voor het bekende_hosts-bestand – zowel die van de gebruiker (~/.ssh/known_hosts) als de globale (/etc/ssh/ssh_known_hosts).
In mijn geval stond de oude host in /etc/ssh/ssh_known_hosts. Toen ik als root verwijderde met sudo ssh-keygen -f /etc/ssh/ssh_known_hosts -R THE_HOSTveranderde het de rechten voor dat bestand in 0600, dus SSHing naar THE_HOST als root werkte, maar voor elke andere gebruiker het is mislukt met “Host key-verificatie mislukt”. De oplossing was:
sudo chmod 644 /etc/ssh/ssh_known_hosts
Antwoord 26
Ik had hetzelfde probleem, helaas gebruikte ik de GitExtensions HMI en vergat ik dat ik een wachtwoordzin had geschreven.
Met HMI… vergeet het maar! Voer geen wachtwoordzin in wanneer u uw sleutel genereert!
Antwoord 27
Ik kreeg dit bericht toen ik probeerde een repo die niet van mij was te git clone. De oplossing was om te forken en vervolgens te klonen.