Mój problem polega na tym, że nie mogę pchać ani pobierać z GitLab. Jednak mogę klonować (przez HTTP lub SSH). Otrzymuję ten błąd, gdy próbuję pchać:
Odmowa uprawnień (publickey) fatalna: nie można odczytać ze zdalnego repozytorium
Ze wszystkich wątków, które sprawdziłem, oto co zrobiłem:
- Skonfiguruj klucz SSH na moim komputerze i dodałem klucz publiczny do GitLab
- Gotowe config --global dla nazwy użytkownika i adresu e-mail
- Sklonowano przez SSH i HTTP, aby sprawdzić, czy to rozwiąże problem
- Wykonano polecenie ssh -T [email protected]
Będziemy bardzo wdzięczni, jeśli masz jakieś wskazówki, jak rozwiązać mój problem.
ssh -vvvv [email protected]
aby sprawdzić, czy odbierze klucz SSHsudo git clone [email protected]:project/somethiing.git
, w przeciwnym razie ssh będzie szukał/root/.ssh
zamiast przesłanego klucza~/.ssh/id_rsa
Odpowiedzi:
Znalazłem to po wielu poszukiwaniach. U mnie zadziała idealnie.
ssh-keygen
.ssh
folder.id_rsa.pub
. Otwórz go w notatniku. Skopiuj z niego cały tekst.Teraz spróbuj i na pewno zadziała.
źródło
type %userprofile%\.ssh\id_rsa.pub | clip
ssh-add filename
(ze ścieżką, jeśli nie w katalogu rsa) po wykonaniu powyższych krokówKrok 1: Dodano plik konfiguracyjny w
~/.ssh/config
pliku, który wygląda jakKrok 2: Po prostu sklonuj repozytorium git BEZ sudo.
Dokumentacja: https://gitlab.com/help/ssh/README#working-with-non-default-ssh-key-pair-paths
źródło
id_rsa_gitlab
inną niż domyślna, jak w przykładzie Fedo, będziesz musiał dostarczyć plik konfiguracyjny. Fajny artykuł Gitlab na ten temat: gitlab.com/help/ssh/…Hostname
, abyHost
dokonać tej pracyMyślę, że prostym rozwiązaniem jest dodanie klucza prywatnego do agenta uwierzytelniającego (jeśli nie masz klucza
~/.ssh/id_rsa
),Po prostu pozwalasz się tym
ssh-agent
zająć.Dodatkowo możesz dodać go na stałe .
źródło
.pub
rozszerzenia.W moim przypadku nie zadziałało to w WSL (podsystemie Windows dla Linuksa).
Kiedy zaczynam WSL, muszę
eval $(ssh-agent -s)
ssh-add ~/.ssh/id_rsa
Teraz połączenie działa.
Możemy to przetestować
ssh -T [email protected]
uwagi:
źródło
upewnij się, że nie jesteś uruchomiony
sudo git clone [email protected]:project/somethiing.git
, w przeciwnym razie/root/.ssh
zamiast przesłanego klucza będzie szukać ssh~/.ssh/id_rsa
źródło
Jest na to bardzo proste rozwiązanie: zamiast pracować z ssh - przejdź do https. aby to zrobić: w folderze swojego projektu masz tam folder .git - masz plik konfiguracyjny - otwórz go w edytorze tekstu i zmień linię
do
źródło
jeśli jesteś w systemie Linux lub Macox, po prostu spróbuj tego w terminalu:
jeśli nic nie zwróci, spróbuj tego:
musi stworzyć tożsamość w ~ / .ssh / id_rsa
po ponownej próbie:
musi zwrócić twoją tożsamość, więc po ponownej próbie sklonowania musi działać
Uwaga: nie zapomnij dodać klucza ssh w swoim profilu gitlab
dzięki
źródło
W moim przypadku nie był to problem z gitlabem, ale z konfiguracją sshd. Serwer ssh nie zezwalał na połączenie z wyjątkiem listy użytkowników. Na tej liście nie było użytkownika git, który łączył się zdalnie z gitlabem. Więc sprawdź to zanim cokolwiek innego.
Możesz sprawdzić konfigurację serwera ssh w
/etc/ssh/sshd_config
. Jeśli masz linię z opcjąAllowUsers
, dodaj do niej git:źródło
Mam gitlab działający z Dockerem, oto co zrobiłem, aby naprawić mój problem.
Okazało się, że wewnątrz docker / var / log / gitlab / sshd / current było wiele wystąpień wiadomości:
Po czym zmieniłem własność tego pliku z 99: users na git: users z:
źródło
Kroki do wykonania, pojawił się ten sam błąd, ale naprawiłem go. Gitlab chce ssh-rsa, więc poniżej znajduje się kod do uruchomienia ssh dla rsa
ssh-keygen -o -t rsa -b 4096 -C "[email protected]"
[email protected] to adres e-mail Twojego konta gitlab
Poprosi Cię o wpisanie, więc po prostu naciśnij Enter po wyświetleniu poniższego kodu,
Wprowadź plik, w którym chcesz zapisać klucz (/home/yourDesktopName/.ssh/id_rsa):
Pojawi się monit o ponowne wprowadzenie, więc po prostu naciśnij Enter po wyświetleniu poniższego kodu,
Wpisz hasło (puste, jeśli nie ma hasła):
Zostanie ponownie wyświetlony monit o ostatnie wejście, więc po prostu naciśnij Enter po wyświetleniu poniższego kodu,
Wprowadź ponownie to samo hasło:
Pokażesz swoje generowanie ssh-rsa.
Zaloguj się do swojego konta Gitlab i przejdź do prawego paska nawigacyjnego, a na lewym pasku bocznym otrzymasz klucz ssh. Wejdź w to.
Spójrz na znak zachęty z prośbą o wejście, otrzymasz ścieżkę ssh-rsa.
Przejdź do folderu SSH i pobierz plik id_rsa.pub
Otwórz go, weź klucz i skopiuj wklej do Gitlab i prawie gotowe.
Sprawdź przez:
ssh -T [email protected]
Dostaniesz:
Welcome to GitLab, @joy4!
Gotowe.
źródło
Wcześniej było to dla mnie bardzo trudne, ale kiedy próbowałem, dodanie klucza ssh w systemach Mac i Linux stało się tak łatwe. Aby to zrobić, wykonaj kilka kroków i polecenie:
Uruchom polecenie
ssh-keygen
w tym terminalu i wprowadź je, aż pojawi się tam losowy obraz klucza.Następnie wprowadź jeszcze jedno polecenie w tym terminalu:
Wygeneruje twój klucz ssh. Klucz zaczyna się od
ssh-rsa
i kończy na.local
.ssh key
sekcja i wklej go tam. KliknijAdd
przycisk to zadziała.źródło
Miałem ten sam problem, rozwiązałem go dodając nowy klucz ssh:
ssh-keygen -t ed25519 -C "[email protected]"
xclip -sel clip < ~/.ssh/id_ed25519.pub
w moim przypadku w systemie Linux)settings=>ssh
kluczy i przejdź obok nowego kluczaźródło
Wprowadź ścieżkę, którą chcesz zapisać (np .: my-pc / Desktop / .ssh / ed25519)
Dodaj klucz publiczny do swojego gitlab ( Jak dodać klucz ssh do gitlab )
źródło
Głównie dwie rzeczy
Musisz mieć klucze id_rsa.pub i id_rsa (prywatne) w swoim folderze .ssh (który powinien znajdować się w twoim katalogu domowym, utwórz go, jeśli go tam nie ma, umieść klucze). To nie zadziała, jeśli nazwałeś swoje pliki kluczy inaczej
Zmień uprawnienia id_rsa na chmod 400 ~ / .ssh / id_rsa
źródło
Innym problemem, który może powodować takie zachowanie, jest konfiguracja z 2 możliwymi lokalizacjami% HOME%.
Używam komputera, na którym niektóre z moich dokumentów są przechowywane lokalnie, a niektóre na dysku sieciowym. Niektóre aplikacje myślą, że
C:\Users\<MyUserName>\
to moje%home%
, inne myślą, żeU:\
to dom.Okazało się,
ssh-keygen
że umieść mój klucz prywatny podC:\users\<MyUserName>\
spodemssh -T
issh -v
spójrz tam.Więc wszystko wydaje się działać dobrze, z wyjątkiem tego
git clone
,git push
a inni szukają kluczaU:\
. Co się nie udaje, więc pojawia się wspomniany błąd.Zajęło mi godzinę, zanim się dowiedziałem, ale ostatecznie rozwiązanie było proste: skopiowałem wszystko od
C:\Users\<MyUserName>\.ssh
doU:\.ssh
źródło
Rozwiązałem w ten sposób ...
Wygenerowano klucz dla systemu Windows za pomocą tego polecenia:
ale problem polegał na tym, że po uruchomieniu tego polecenia wyskoczyło wiersz: "Wpisz plik, w którym ma zostać zapisany klucz (/c/Users/xxx/.ssh/id_rsa):" Tutaj podałem tylko nazwę pliku, z powodu której mój klucz był zapisywany w moim pwd, a nie w podanej lokalizacji. Kiedy zrobiłem "git clone", zakładałem, że klucz znajduje się w lokalizacji "/c/Users/xxx/.ssh/id_rsa", ale nie został znaleziony, dlatego generował błąd.
W czasie generowania klucza zostały wygenerowane 2 pliki o nazwach „plik1” i „plik1.pub”. Zmieniłem nazwy obu tych plików na
i
i umieszczone zarówno w lokalizacji
"/c/Users/xxx/.ssh/"
źródło
Podejdź do terminala i ponownie zregeneruj klucz ssh. Rodzaj
ssh-keygen
. Zapyta Cię, gdzie chcesz go zapisać, wpisz ścieżkę.Następnie skopiuj klucz publiczny na platformę gitlabs. Zwykle zaczyna się od ssh-rsa.
źródło
Problem dla mnie polegał na tym, że przełączyłem się
UsePAM
zyes
nano
w pliku konfiguracyjnym SSH pod/etc/ssh/sshd_config
. DziękiUsePAM yes
wszystko działa idealnie.źródło
Znalazłem rozwiązanie w pomocy gitlab .
Mam nadzieję, że niektórym z was może to pomóc!
źródło
Jak dodać klucz SSH do konta gitlab w systemie Ubuntu?
Pojawi się klucz SSH. Skopiuj te i
Przejdź do swojego konta gitlab.
Klucz SSH zostanie dodany!
(Uwaga: jeśli masz klucz SSH do generowania podglądów i odmowę dostępu (klucz publiczny). Usuwasz klucz ssh do podglądu i generujesz nowy, a następnie dodajesz git nazwa użytkownika i adres e-mail na swoim terminalu)
źródło
Rozwiązałem
[email protected]: Permission denied (publickey)
problem, postępując zgodnie z instrukcjamicat ~/.ssh/id_rsa.pub
id_rsa.pub
(klucz publiczny) do swojego getlab `Setting -> SSH Keyscat ~/.ssh/id_rsa
id_rsa
(klucz prywatny) do `Code_repo-> git_auth-> id_rsaUWAGA: Uważaj na użytkownika maszyny, jeśli używasz
root
użytkownika w swoim DockerFile lub gdziekolwiek indziej, a następnie użyjsudo su
przed uruchomieniem powyższych poleceń, aby uzyskać klucze publiczne i prywatne użytkownika root.źródło
W naszym przypadku nie był to problem po stronie użytkownika / klienta, ale po stronie serwera Gitlab.
Uruchamiamy lokalną instancję Gitlab CE 12.9 na CentOS 7.1.
Odkryliśmy, że na serwerze plik .ssh / authoris_keys nie aktualizował się poprawnie. Użytkownicy tworzą swoje klucze SSH (zgodnie z przewodnikiem po Gitlab) i dodają je do serwera Gitlab, ale serwer nie aktualizuje autoryzowanych_kluczy , więc zawsze spowoduje to błędy odmowy uprawnień.
Obejściem polegało na odbudowaniu pliku busy_keys przez uruchomienie:
To zadziała dla każdego, kto doda swoje klucze przed uruchomieniem zadania prowizji. Dla kolejnych użytkowników, którzy dodadzą swoje klucze, ktoś musi ponownie ręcznie uruchomić zadania rake.
Bardziej trwałe rozwiązanie było nie używać authorized_keys pliku i użyć zamiast tego indeksowany wyszukiwanie w bazie danych Gitlab :
Domyślnie (cóż, domyślny w naszej instalacji), plik Write to allowed_keys był zaznaczony w obszarze administracyjnym> ustawienia optymalizacji wydajności . Więc odznaczyliśmy to i zamiast tego użyliśmy bazy danych Gitlab.
Po skonfigurowaniu wyszukiwania indeksowanego i usunięciu zaznaczenia pliku Write to author_keys, dostęp SSH stał się OK.
źródło
Dla każdego, kto używa systemu Windows 10 i nic innego dla niego nie działa:
W moim przypadku musiałem sklonować repozytorium za pomocą https zamiast ssh i pojawiło się okno z pytaniem o moje dane uwierzytelniające. Potem wszystko działa dobrze.
źródło
Wiem, odpowiadam bardzo późno i nawet StackOverflow potwierdził, czy naprawdę chcę odpowiedzieć. Odpowiadam, ponieważ nikt tak naprawdę nie opisał rzeczywistego problemu, więc chciałem podzielić się tym samym.
Podstawy
Po pierwsze, zrozum, co jest tutaj pilotem. Zdalny to GitLab, a twój system jest lokalny, więc kiedy mówimy o zdalnym
origin
, dowolny adres URL ustawiony w wynikachgit remote -v
jest twoim zdalnym adresem URL.Protokoły
Zasadniczo Git clone / push / pull działa głównie na dwóch różnych protokołach (są też inne) -
Kiedy klonujesz repozytorium (lub zmieniasz zdalny adres URL) i używasz adresu URL HTTPs, takiego jak https://gitlab.com/wizpanda/backend-app.git to używa pierwszego protokołu, tj. Protokołu HTTP.
Jeśli sklonujesz repozytorium (lub zmienisz zdalny adres URL) i użyjesz adresu URL, takiego jak
[email protected]:wizpanda/backend-app.git
wtedy, używa protokołu SSH.Protokół HTTP
W tym protokole każda zdalna operacja, tj. Klonowanie, wypychanie i ściąganie, wykorzystuje proste uwierzytelnianie, tj. Nazwę użytkownika i hasło pilota (w tym przypadku GitLab), co oznacza, że dla każdej operacji musisz wpisać swoją nazwę użytkownika i hasło, które mogą być uciążliwe .
Więc kiedy push / pull / clone, GitLab / GitHub uwierzytelnia cię za pomocą twojej nazwy użytkownika i hasła i pozwala ci wykonać operację.
Jeśli chcesz tego spróbować, możesz przełączyć się na adres URL protokołu HTTP, uruchamiając polecenie
git remote set-url origin <http-git-url>
.Aby tego uniknąć, możesz skorzystać z protokołu SSH.
Protokół SSH
Proste połączenie SSH działa na parach kluczy publiczny-prywatny. W twoim przypadku GitLab nie może Cię uwierzytelnić, ponieważ do komunikacji używasz adresu URL SSH. Teraz GitLab musi Cię w jakiś sposób znać. W tym celu musisz utworzyć parę kluczy publiczny-prywatny i przekazać klucz publiczny GitLab.
Teraz, gdy push / pull / clone with GitLab, GIT (wewnętrznie SSH) domyślnie zaoferuje Twój klucz prywatny GitLab i potwierdzi Twoją tożsamość, a następnie GitLab pozwoli Ci wykonać operację.
Nie będę więc powtarzał kroków, które już podał Muhammad, powtórzę je teoretycznie.
~/.ssh
nazwanaid_rsa.pub
(klucz publiczny) iid_rsa
(klucz prywatny).Porady
Zawsze powinieneś tworzyć silny klucz rsa z co najmniej 2048 bajtami. Więc polecenie może być
ssh-keygen -t rsa -b 2048
.https://gitlab.com/help/ssh/README#generating-a-new-ssh-key-pair
Myśl ogólna
Obie metody mają swoje wady i zalety. Po wpisaniu powyższego tekstu poszedłem poszukać więcej na ten temat, ponieważ nigdy czegoś o tym nie czytałem.
Znalazłem ten oficjalny dokument https://git-scm.com/book/en/v2/Git-on-the-Server-The-Protocols, który mówi o tym więcej. Chodzi mi o to, że czytając błąd i przemyślając błąd, możesz stworzyć własną teorię lub zrozumienie, a następnie porównać z niektórymi wynikami Google, aby rozwiązać problem :)
źródło
Dodałem moje
~/.ssh/id_rsa.pub
do listy znanych kluczy SSH w moich ustawieniach GitLab https://gitlab.com/profile/keys . To rozwiązało problem. :-)źródło
Używam Ubuntu 18.04 i faktycznie był to problem z uprawnieniami na moim lokalnym komputerze. Problem zniknął, gdy ustawiłem uprawnienia do odczytu / zapisu do mojego folderu .git.
źródło
Cóż, miałem ten sam problem i po wypróbowaniu odpowiedzi zaproponował @Khan. Jednak udało mi się to tylko zmienić, zmieniając pierwotny adres URL w pliku .git / config na adres https: https://gitlab.com/mygitlabusername/mygitproject.git
Ponieważ dostęp przez ssh jest zabroniony, doszedłem do wniosku, że używanie https nie powinno stanowić problemu. Będzie jednak prosić o nazwę użytkownika i hasło przy każdym wypychaniu do repozytorium at
źródło
Użyj,
git config credential.helper store
jeśli Twoja witryna korzysta z TLS / SSL. Mam nadzieję, że to zadziałaźródło
Wydaje się, że istnieją różnice między tymi dwoma sposobami dostępu do repozytorium git, tj. Przy użyciu SSH lub HTTPS. U mnie napotkałem błąd, ponieważ próbowałem przesłać moje lokalne repozytorium za pomocą SSH.
Problem można po prostu rozwiązać, klikając przycisk klonowania na stronie docelowej projektu i kopiując link HTTPS i zastępując go linkiem SSH pojawiającym się w formacie „git @ gitlab…”.
źródło
Zmień uprawnienia :: chmod 400 ~ / .ssh / id_rsa Pomogło mi to.
źródło