Próbuję połączyć się ze zdalnym repozytorium Git, które znajduje się na moim serwerze internetowym i sklonować je na moim komputerze.
Używam następującego formatu dla mojej komendy:
git clone ssh://[email protected]/repository.git
Działa to dobrze dla większości członków mojego zespołu. Zwykle po uruchomieniu tego polecenia Git wyświetli monit o podanie hasła użytkownika, a następnie uruchom klonowanie. Jednak podczas pracy na jednym z moich komputerów pojawia się następujący błąd:
Weryfikacja klucza hosta nie powiodła się.
fatal: Nie można odczytać ze zdalnego repozytorium.
Nie używamy kluczy SSH do łączenia się z tym repozytorium, więc nie jestem pewien, dlaczego Git szuka takiego na tym konkretnym komputerze.
ssh://
Odpowiedzi:
Łączysz się za pomocą protokołu SSH, jak wskazano w
ssh://
prefiksie na sklonowanym adresie URL. Korzystając z SSH, każdy host ma klucz. Klienci zapamiętują klucz hosta powiązany z określonym adresem i odmawiają połączenia, jeśli klucz hosta wydaje się zmieniać. Zapobiega to atakom człowieka w środku.Klucz hosta dla domeny.com zmienił się. Jeśli nie wydaje ci się to podejrzane , usuń stary klucz z lokalnej pamięci podręcznej, edytując,
${HOME}/.ssh/known_hosts
aby usunąć wiersz dla domeny.com lub pozwalając narzędziu SSH zrobić to za CiebieStąd zapisz zaktualizowany klucz, wykonując go samodzielnie
lub, równoważnie, niech
ssh
zrobi to za ciebie następnym połączeniu zgit fetch
,git pull
lubgit push
(albo nawet zwykły ol”ssh domain.com
) odpowiadając Tak po pojawieniu się monituPowodem tego monitu jest to, że domena.com nie jest już dostępna
known_hosts
po usunięciu i prawdopodobnie nie w systemie/etc/ssh/ssh_known_hosts
, więcssh
nie ma sposobu, aby dowiedzieć się, czy host na drugim końcu połączenia to tak naprawdę domena.com. (Jeśli wprowadzono niewłaściwy klucz/etc
, osoba z uprawnieniami administratora będzie musiała zaktualizować plik ogólnosystemowy).Gorąco zachęcam do rozważenia możliwości uwierzytelnienia użytkowników za pomocą kluczy. W ten sposób
ssh-agent
można przechowywać kluczowy materiał dla wygody (zamiast wszystkich osób, które muszą wprowadzać swoje hasło dla każdego połączenia z serwerem), a hasła nie są przesyłane przez sieć.źródło
sudo ssh-keygen -R domain.com
może zmienić nazwę istniejącegoknown_hosts
plikuknown_hosts.old
i utworzyć kopię, którą będzie można odczytać tylko przez root . (-rw------- root root
) Możesz to łatwochown
przywrócić do odpowiedniego użytkownika, ale możesz także zmarnować popołudniowe debugowanie, dlaczego git jest uszkodzony. : DAre you sure you want to continue connecting (yes/no)?
. Nie popełniaj tego samego błędu co ja. Musisz wpisaćyes
. Po prostu naciśnięcieJak już wcześniej odpowiedziałem w Klonowanie git repo powoduje błąd - weryfikacja klucza hosta nie powiodła się. fatal: Zdalny koniec nieoczekiwanie się rozłączył , dodaj GitHub do listy autoryzowanych hostów:
ssh-keyscan -t rsa github.com >> ~/.ssh/known_hosts
źródło
Miałem podobny problem, ale używając kluczy SSH. Na podstawie powyższej odpowiedzi Tupy doszedłem do wniosku, że problem polega na tym, że plik znany_hosts nie jest obecny lub github.com nie jest obecny na liście znanych hostów. Oto kroki, które podjąłem, aby go rozwiązać -
mkdir -p ~/.ssh
ssh-keyscan -t rsa github.com >> ~/.ssh/known_hosts
ssh-keygen -t rsa -C "user.email"
$ cat ~/.ssh/id_rsa.pub
i skopiuj go.źródło
touch
Komenda nie powiedzie się w przypadku~/.ssh
katalogu nie istnieje, więc nadal wymagane krok 1. Poza tym nie potrzebujesztouch
pliku przed użyciem>>
przekierowania. Zostanie utworzony, jeśli to konieczne (ale tylko plik, a nie cała ścieżka, więc nadalmkdir -p
jest potrzebny).-p
Make opcja to działa w przypadku katalog już istnieje.ssh-keyscan
którego brakuje w dokumentach Github po dodaniu nowego klucza ssh.Dockerfile
brakiem pozwolenia. Dodanie tutaj drugiego kroku rozwiązało ten problem! Dziękujemy za wspaniałą pracęDzieje się tak, ponieważ github nie jest obecnie na twoich znanych hostach.
Powinien zostać wyświetlony monit o dodanie github do znanych hostów. Jeśli tak się nie stało, możesz uruchomić ponownie,
ssh -T [email protected]
aby otrzymać monit.źródło
Dla mnie po prostu musiałem wpisać „tak” w odpowiedzi na pytanie „Czy na pewno chcesz kontynuować łączenie (tak / nie)?” zamiast naciskać Enter.
źródło
Mam ten sam problem w nowo zainstalowanym systemie, ale był to problem udev. Nie było
/dev/tty
węzła, więc musiałem zrobić:źródło
Jeśli korzystasz z biurowego intranetu (w innym przypadku niebezpiecznego), który jest zawsze chroniony przez zapory ogniowe, po prostu wpisz następujące wiersze w ~ / .ssh / config
Host *
StrictHostKeyChecking no
UserKnownHostsFile = / dev / null
źródło
To, co zadziałało, to najpierw dodać mój klucz SSH do nowego komputera, postępowałem zgodnie z instrukcjami GitLab - dodaj klucz SSH . Zauważ, że skoro jestem na Win10, musiałem wykonać wszystkie te polecenia w Git Bash na Windowsie (nie działało to w zwykłej powłoce cmd DOS).
Z drugiej strony w Git Bash musiałem zrobić
git clone
repozytorium, z którym miałem problemy, aw moim przypadku musiałem sklonować go pod inną nazwą, ponieważ miałem go już lokalnie i nie chciałem stracić swoich zobowiązań. Na przykładNastępnie dostałem monit o dodanie go do listy znanych hostów, pytanie może być następujące:
Wpisałem „tak” i w końcu zadziałało, zazwyczaj powinieneś otrzymać komunikat podobny do tego:
Uwaga : jeśli korzystasz z systemu Windows, upewnij się, że używasz Git Bash do wszystkich poleceń, to nie działało w zwykłej powłoce cmd lub PowerShell, naprawdę musiałem to zrobić w Git Bash.
Na koniec usunąłem repozytorium drugiego klonu (
myRepo2
w tym przykładzie) i wróciłem do mojego pierwszego repo i mogłem w końcu zrobić wszystkie rzeczy Git jak zwykle w moim ulubionym edytorze VSCode.źródło
Jeśli używasz git dla Windows.
Klient GUI dodaje klucz do ciebie
~/.ssh/known_hosts
. Łatwiej jest to zapamiętać, jeśli nie robisz tego często, a także unikasz konieczności używania wiersza poleceń git (standardowe wiersze poleceń systemu Windows nie mająssh-keyscan
pliku wykonywalnego.źródło
Gdy serwer zdalny chce połączyć się z prywatnym repozytorium, uwierzytelnia się za pośrednictwem ssh. Utwórz parę klucz prywatny-publiczny za pomocą ssh-keygen lub jeśli masz już klucz publiczny-prywatny. skopiuj i wklej klucz publiczny w Ustawieniach prywatnego repozytorium.
YourPrivateRepo -> Ustawienia -> Wdróż klucze -> Dodaj klucz wdrażania -> Wklej klucz publiczny.
Teraz zdalny serwer będzie mógł połączyć się z prywatnym repozytorium.
UWAGA: Klucze wdrażania mają dostęp tylko do odczytu repozytorium. Musisz wyraźnie zezwolić na dostęp do zapisu.
źródło
Oznacza to, że klucz zdalnego hosta został zmieniony (może to być zmiana hasła hosta),
Twój terminal zaproponował wykonanie tego polecenia jako użytkownik root
Musisz usunąć tę nazwę hosta z listy hostów na komputerze / serwerze. Skopiuj sugerowane polecenie i wykonaj jako użytkownik root.
Spróbuj ponownie, mam nadzieję, że to zadziała.
źródło
Na pytanie:
Are you sure you want to continue connecting (yes/no)?
Rodzaj tak jak odpowiedź
W ten sposób rozwiązałem mój problem. Ale jeśli spróbujesz po prostu nacisnąć przycisk Enter, to nie zadziała!
źródło
Możesz użyć swojego „git url” w formacie URL „https” w pliku Jenkinsfile lub gdziekolwiek chcesz.
git url: 'https://github.com/jglick/simple-maven-project-with-tests.git'
źródło
Napotkałem ten sam błąd w DockerFile podczas kompilacji, gdy obraz był publiczny. Niewiele zmodyfikowałem w Dockerfile.
źródło
Miałem podobny problem, niestety użyłem interfejsu GitExtensions i zapomniałem, że napisałem hasło. Z HMI .... zapomnij! Nie wpisuj hasła podczas generowania klucza!
źródło
Dostałem tę wiadomość, gdy próbowałem
git clone
repozytorium, które nie było moje. Rozwiązaniem było rozwidlenie, a następnie sklonowanie.źródło