Słynny „BŁĄD: odmowa dostępu do .git użytkownikowi”

Próbowałem googlować i przeczytać https://help.github.com/en/articles/connecting-to-github-with-ssh i różne, różne przewodniki. Nie mogę git push -u origin masterlub git push origin master(to samo polecenie).

Konto git mam od co najmniej 2 lat. Udało mi się utworzyć repozytoria i push -u origin masterdobrze na moim laptopie, ale na tym komputerze mam problemy.

Oto, czego próbowałem:

1. Skonfigurowałem nazwę użytkownika git

2. Skonfigurowałem adres e-mail użytkownika git

3. Umieściłem zawartość mojego /home/meder/.ssh/id_rsa.pub na stronie konta github. Sprawdziłem, że nie wkleiłem żadnych spacji

4. Utworzyłem plik ~ / .ssh / config z następującą zawartością:

  Host github.com
  User git
  Hostname github.com
  PreferredAuthentications publickey
  IdentityFile ~/.ssh/id_rsa

Chmodowałem .ssh do 700, id_rsa 600

5. Dodałem właściwe zdalne źródło bez robienia literówek :git remote add origin [email protected]:medero/cho.git

6. Aby potwierdzić # 5, oto mój plik .git / config. Katalog jest poprawny i nie jest to inny katalog:

[remote "origin"]
        fetch = +refs/heads/*:refs/remotes/origin/*
        url = [email protected]:medero/cho.git

7. ssh [email protected] -v daje mi pomyślne uwierzytelnienie

8. Jedną dziwną rzeczą jest to, że nazwa użytkownika, którą mnie wita, została tdo niego dołączona. Moja nazwa użytkownika github to mederonie medert.

Cześć mederot! Udało Ci się uwierzytelnić, ale GitHub nie zapewnia dostępu do powłoki.

9. Ja nie za serwerem proxy lub zapory

10. Klucz jest oferowany, oto wyjście z -v:

debug1: Host 'github.com' is known and matches the RSA host key.
debug1: Found key in /home/meder/.ssh/known_hosts:58
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey
debug1: Offering public key: /home/meder/.ssh/id_rsa
debug1: Remote: Forced command: gerve mederot
debug1: Remote: Port forwarding disabled.
debug1: Remote: X11 forwarding disabled.
debug1: Remote: Agent forwarding disabled.
debug1: Remote: Pty allocation disabled.
debug1: Server accepts key: { some stuff, dont know if i should share it

debug1: Remote: Forced command: gerve mederot
debug1: Remote: Port forwarding disabled.
debug1: Remote: X11 forwarding disabled.
debug1: Remote: Agent forwarding disabled.
debug1: Remote: Pty allocation disabled.
debug1: Authentication succeeded (publickey).

11. Oto polecenia, których użyłem

mkdir cho
git init
touch README
git add README
git commit -m 'test'
git remote add origin [email protected]:medero/cho.git
git push -u origin master

12. Nie chcę tworzyć nowego klucza SSH.

13. Jeśli git clone przy użyciu ssh i edytuję, zatwierdzam i git push, otrzymuję dokładnie to samo.

14. Oto rzeczywisty błąd:

$ git push
ERROR: Permission to medero/cho.git denied to mederot.
fatal: The remote end hung up unexpectedly

15. Skonfigurowałem nazwę użytkownika github i token github:

$ git config --global github.user medero $ git config --global github.token 0123456789yourf0123456789token Ustawia token GitHub dla wszystkich instancji git w systemie

16. Potwierdziłem, że moja nazwa użytkownika github NIE jest, mederota mój token Github JEST PRAWIDŁOWY na stronie mojego konta (sprawdzone pierwsze 2 znaki i ostatnie 2 znaki).

17. Aby potwierdzić # 16, ~ / .gitconfig zawiera

[github]
    token = mytoken...
    user = medero

18. Zrobiłem, ssh-key add ~/.ssh/id_rsajeśli to było konieczne ...

TEORIE:

Podejrzewam, że jest coś podejrzanego, ponieważ po uwierzytelnieniu przez ssh powitanie użytkownika jest, mederota nie medero, co jest moim kontem. Czy coś na moim koncie github mogło zostać nieprawidłowo zapisane w pamięci podręcznej?

Podejrzewam również dziwne zachowanie lokalnego buforowania ssh, ponieważ jeśli ja mv ~/.ssh/id_rsa KAKAi tak mv ~/.ssh/id_rsa.pub POOPOOzrobię ssh [email protected] -v, nadal uwierzytelnia mnie i mówi, że obsługuje mój /home/meder/.ssh/id_rsa, kiedy zmieniam jego nazwę ?! To musi być buforowane ?!

Zakładam, że w kroku 18 masz na myśli ssh-add ~/.ssh/id_rsa? Jeśli tak, to wyjaśnia to:

Podejrzewam również dziwne działanie lokalnego buforowania ssh, ponieważ jeśli i mv ~ / .ssh / id_rsa KAKA i mv ~ / .ssh / id_rsa.pub POOPOO i zrobię ssh [email protected] -v, nadal uwierzytelnia mnie i mówi, że służy mój /home/meder/.ssh/id_rsa, kiedy zmieniłem jego nazwę ?! To musi być buforowane ?!

... ponieważ ssh-agentbuforuje twój klucz.

Jeśli spojrzysz na GitHub, jest tam konto mederot . Czy na pewno nie ma to z tobą nic wspólnego? GitHub nie powinien zezwalać na dodanie tego samego klucza publicznego SSH do dwóch kont, ponieważ gdy używasz [email protected]:...adresów URL, identyfikuje użytkownika na podstawie klucza SSH. (To nie powinno być dozwolone jest potwierdzona tutaj ).

Podejrzewam więc (w kolejności malejącego prawdopodobieństwa), że zachodzi jeden z poniższych przypadków:

1. Utworzyłeś wcześniej konto mederot i dodałeś do niego swój klucz SSH.
2. Ktoś inny uzyskał kopię Twojego klucza publicznego i dodał go do konta mederot GitHub.
3. W GitHubie jest straszny błąd.

Jeśli nie ma 1, zgłosiłbym to do GitHub, aby mogli sprawdzić około 2 lub 3.

Więcej :

ssh-add -l sprawdź, czy istnieje więcej niż jeden identyfikator, jeśli tak, usuń go przez ssh-add -d "ten plik klucza"

Po kilku dniach szukania w Google stwierdziłem, że jest to jedyne pytanie podobne do mojej sytuacji.

Jednak właśnie rozwiązałem problem! Dlatego zamieszczam tutaj moją odpowiedź, aby pomóc każdemu, kto szuka tego problemu.

Oto co zrobiłem:

1. Otwórz „Keychain Access.app” (możesz go znaleźć w Spotlight lub LaunchPad)

2. Wybierz „Wszystkie elementy” w kategorii

3. Wyszukaj „git”

4. Usuń każdy stary i dziwny element

5. Spróbuj ponownie Push i po prostu DZIAŁAŁO

Jeśli problem pojawia się w systemie Windows, usuń poświadczenia z historii systemu Windows.

• Przejdź do Menedżera poświadczeń
• Przejdź do poświadczeń systemu Windows
• Usuń wpisy w obszarze Ogólne poświadczenia
• Spróbuj połączyć się ponownie.Tym razem powinien poprosić o poprawną nazwę użytkownika i hasło.

usuń poświadczenia z git

Na komputerze Mac, jeśli masz wiele loginów GitHub i nie używasz SSH, wymuś poprawne logowanie, używając:

git remote set-url origin https://[email protected]/username/repo-name.git

Działa to również, jeśli masz problemy z wypychaniem do prywatnego repozytorium.

To z powodu konfliktu.

Usuń wszystkie klucze z ssh-agent

ssh-add -d ~/.ssh/id_rsa
ssh-add -d ~/.ssh/github

Dodaj klucz github ssh

ssh-add   ~/.ssh/github

Teraz powinno działać.

Używam komputera Mac i problem został rozwiązany przez usunięcie rekordu github z aplikacji dostępu do pęku kluczy: Oto, co zrobiłem:

1. Otwórz „Keychain Access.app” (możesz go znaleźć w Spotlight lubLaunchPad)
2. Wybierz „Wszystkie elementy” w kategorii
3. Wyszukaj „git”
4. Usuń wszystkie stare i dziwne elementy Spróbuj ponownie wypchnąć i po prostu DZIAŁAŁO

Powyższe kroki zostały skopiowane z @spyar dla ułatwienia.

Uważam, że rozwiązanie jest takie samo, jak zapewnia @spyar, czyli aplikacja Dostęp do pęku kluczy przechowująca starą nazwę użytkownika.

Istnieją 2 rozwiązania tej sytuacji:

1. Usuń informacje w dostępie do pęku kluczy według
   • Otwórz aplikację Dostęp do pęku kluczy
   • Wyszukaj github
   • Usuń odpowiednie poświadczenia

Lub

2. Jeśli chcesz użyć klucza ssh . Po prostu zmień swój adres URL repozytorium z https

https://github.com/username/repo.git

w

[email protected]: nazwa użytkownika / repo.git

Mam nadzieję że to pomoże.

Niedawno napotkałem ten problem na starym repozytorium na moim komputerze, które zostało przesłane za pomocą protokołu HTTPS. kroki 5 i 6 rozwiązały mój problem przez ponowne ustawienie zdalnego adresu URL dla mojego repozytorium z używania adresu URL https na adres URL ssh

sprawdzanie, czy pilot używa adresu URL https

> git remote -v
origin  https://github.com/ExampleUser/ExampleRepo.git (fetch)
origin  https://github.com/ExampleUser/ExampleRepo.git (push)

następnie ustaw ponownie źródło, aby użyć adresu URL ssh

> git remote set-url origin [email protected]:ExampleUser/ExampleRepo.git

weryfikacja nowego pilota

> git remote -v
origin  [email protected]:ExampleUser/ExampleRepo.git (fetch)
origin  [email protected]:ExampleUser/ExampleRepo.git (push)

mógł teraz z powodzeniem git push -u origin

Nadal nie jestem pewien, jakie ustawienie zmieniłbym, co mogło spowodować niepowodzenie wypychania, gdy pilot jest ustawiony na https, ale to było rozwiązanie mojego problemu

Miałem ten sam problem co Ty. Po długim czasie spędzonym na wyszukiwaniu w Google odkryłem, że mój błąd był spowodowany przez wielu użytkowników, którzy dodali ten sam klucz do swoich kont.

Oto moje rozwiązanie: usuń klucz ssh niewłaściwego użytkownika (mogę to zrobić, ponieważ zły użytkownik jest również moim kontem). Jeśli niewłaściwy użytkownik nie jest Twoim kontem, być może będziesz musiał zmienić swój klucz SSH, ale nie sądzę, aby to się stało.

Myślę, że przyczyną problemu może być błędny wpis w nazwie Twojego konta.

Ten problem jest również spowodowany:

Jeśli korzystasz z Maca / Linuksa i używasz 'ControlMaster' w swoim ~ / .ssh / config, może być uruchomionych kilka głównych procesów sterujących ssh.

Aby je znaleźć, biegnij:

ps aux | grep '\[mux\]'

I zabij odpowiednich.

Ja też natknąłem się na to, co spowodowało to dla mnie, że podczas klonowania repozytorium, do którego wysyłałem swoje zmiany, podniosłem klonowany adres URL z karty incognito bez logowania się. (Nadal nie mam pojęcia, jak to działa). To z jakiegoś powodu doprowadziło do wybrania innego konta użytkownika. Kiedy spróbowałem ponownie z prawidłowo zalogowanej strony, działało jak zwykle.

Napotkałem ten błąd podczas używania Travis CI do wdrażania treści , co wiązało się z przesyłaniem zmian do repozytorium.

Ostatecznie rozwiązałem problem, aktualizując osobisty token dostępu GitHub powiązany z kontem Travis z public_repouprawnieniem dostępu do zakresu: