Ostatnio nie byłem w stanie sklonować ani naciskać na github i próbuję znaleźć podstawową przyczynę.
To jest w systemie Windows
Mam cygwin + git oraz msysgit.
Msysgit został zainstalowany z następującymi opcjami:
- OpenSSH
- Użyj Git z wiersza polecenia systemu Windows
To daje mi 4 środowiska, w których mogę spróbować użyć git w:
- Windows cmd monit
- PowerShell
- Git Bash
- Cygwin
Jakoś udało mi się dostać do pozycji, w której kiedy próbuję sklonować repozytorium za pomocą msysgit, cmd.exe lub Powershell, pojawia się następujący błąd:
> Initialized empty Git repository in
> C:/sandbox/SomeProject/.git/
> @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
> @ WARNING: UNPROTECTED PRIVATE KEY FILE! @
> @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
> Permissions 0644 for
> '/c/Users/Ben/.ssh/id_rsa' are too
> open. It is recommended that your
> private key files are NOT accessible
> by others. This private key will be
> ignored. bad permissions: ignore key:
> /c/Users/Ben/.ssh/id_rsa Permission
> denied (publickey). fatal: The remote
> end hung up unexpectedly
Korzysta z folderu .ssh w moim folderze c: \ users \ ben \, z którego korzysta msysgit. Podejrzewam, że cygwin działa, ponieważ folder .ssh znajduje się w innym miejscu, ale nie jestem pewien, dlaczego
W Git Bash sprawdzam uprawnienia:
$ ls -l -a ~/.ssh
Co daje mi:
drwxr-xr-x 2 Ben Administ 0 Oct 12 13:09 .
drwxr-xr-x 34 Ben Administ 8192 Oct 12 13:15 ..
-rw-r--r-- 1 Ben Administ 1743 Oct 12 12:36 id_rsa
-rw-r--r-- 1 Ben Administ 399 Oct 12 12:36 id_rsa.pub
-rw-r--r-- 1 Ben Administ 407 Oct 12 13:09 known_hosts
Te uprawnienia są najwyraźniej zbyt zrelaksowane. Jak oni to osiągnęli, nie mam pojęcia.
Mogę spróbować je zmienić ...
$ chmod -v -R 600 ~/.ssh
co mówi mi:
mode of `.ssh' changed to 0600 (rw-------)
mode of `.ssh/id_rsa' changed to 0600 (rw-------)
mode of `.ssh/id_rsa.pub' changed to 0600 (rw-------)
mode of `.ssh/known_hosts' changed to 0600 (rw-------)
Ale wydaje się, że nie ma żadnego efektu. Nadal pojawia się ten sam błąd i robię
$ ls -l -a ~/.ssh
daje takie same uprawnienia jak poprzednio.
AKTUALIZACJA:
Próbowałem naprawić uprawnienia do tych plików w cygwin, a cygwin poprawnie zgłasza swoje uprawnienia, gitbash nie: alt text http://cdn.cloudfiles.mosso.com/c54102/app7962031255448924.jpg
Wszelkie pomysły na to, jak naprawdę mogę naprawić te uprawnienia?
Odpowiedzi:
Zmieniłeś uprawnienia do całego katalogu, co zgadzam się ze Splash to zły pomysł. Jeśli pamiętasz, jakie są pierwotne uprawnienia do katalogu, spróbuję przywrócić je do tego, a następnie wykonaj następujące czynności
w folderze .ssh. Spowoduje to ustawienie pliku id_rsa na rwx (odczyt, zapis, wykonanie) tylko dla właściciela (ciebie) i zerowy dostęp dla wszystkich innych.
Jeśli nie pamiętasz oryginalnych ustawień, dodaj nowego użytkownika i utwórz dla niego zestaw kluczy SSH, tworząc w ten sposób nowy folder .ssh, który będzie miał domyślne uprawnienia. Możesz użyć tego nowego folderu .ssh jako odniesienia do uprawnień do zresetowania folderu .ssh i plików.
Jeśli to nie zadziała, spróbuję odinstalować msysgit, usunąć WSZYSTKIE foldery .ssh na komputerze (tylko dla bezpieczeństwa), a następnie ponownie zainstalować msysgit z pożądanymi ustawieniami i spróbować zacząć od nowa (choć myślę, że powiedziałeś mi już tego próbowałeś).
Edytowano: Właśnie znalazłem ten link za pośrednictwem Google - Naprawa „OSTRZEŻENIE: NIEBEZPIECZNY PRYWATNY PLIK! na Linuksie Chociaż jest on ukierunkowany na Linuksa, może pomóc, ponieważ mówimy o uprawnieniach Liunx i tym podobnych.
źródło
-rwx------
. Więc to, co wyświetlasz, nie jest poprawne, jeśli poprawnie wykonałeś komendę chmod.Wystąpił błąd w chmod cygwina, patrz:
/superuser/397288/using-cygwin-in-windows-8-chmod-600-does-not-work-as-expected
źródło
None
. (Przypuszczam, że jest to standardowa procedura, gdy grupa nie została wyraźnie zdefiniowana). Ta zmiana na jawną grupęUsers
rzekomo pozwoliła cygwinowi rozdzielić uprawnienia, i mogłam w końcu ustawić 600 zamiast automatycznego 660.chmod 600
git, narzekałem, że moje uprawnienia były nadal0660
. Naprawienie własności grupy powoduje, że chown ma zastosowanie poprawnie.W systemach * nix oczywistą poprawką jest
chmod 600 id_rsa
OFC, ale w Windows 7 musiałem chwilę uderzyć głową o ścianę, ale potem znalazłem magiczne rozwiązanie:przejdź do Mój komputer / Kliknij prawym przyciskiem myszy / Właściwości / Zaawansowane ustawienia systemu / Zmienne środowiskowe i USUŃ zmienną (ewentualnie ze środowiska systemowego i użytkownika):
CYGWIN
Zasadniczo jest to wada mingw32 używana przez git windows binary, ponieważ zawsze widzi wszystkie pliki 644 i wszystkie foldery 755. Usunięcie zmiennej środowiskowej nie zmienia tego zachowania, ale najwyraźniej informuje ssh.exe, aby zignorował problem. Jeśli ustawisz odpowiednie uprawnienia do swojej id_rsa za pomocą ustawień bezpieczeństwa eksploratora (naprawdę nie ma potrzeby, aby był tam inny użytkownik niż twój własny, nie „wszyscy”, nie „administratorzy”, nie „system”. Żaden. Tylko ty) , nadal będziesz bezpieczny.
Teraz, dlaczego mingw32, inny system niż Cygwin, spowodowałoby żadnej użycie zmiennej środowiskowej Cygwin, jest poza mną. Wygląda mi na błąd.
źródło
Mam XP, co pozwoliło Git Bash na komunikację z Githubem (po dużej frustracji):
c:\cygwin\bin\cyg*
(~ 50 plików) doc:\Program Files\Git\bin\
c:\cygwin\bin\ssh.exe
doc:\Program Files\Git\bin\
(nadpisywanie)Utwórz plik
c:\Documents and Settings\<username>\.ssh\config
zawierający:(opcjonalnie) Użyj,
ssh -v git@github
aby zobaczyć połączenie debugowane.Tło: Ogólny problem stanowi połączenie tych dwóch:
źródło
c:\Documents and Settings\<username>\.ssh\config
ponieważ zostały zastąpionec:\Program Files\Git\bin\ssh.exe
zc:\cygwin\bin\ssh.exe
. Dobrze ?LogLevel DEBUG
do pliku .ssh \ config, aby uzyskać dane wyjściowe debugowania z procesu ssh.exe uruchomionego przez git.exe.W systemie Windows 7 za pomocą Git znalezionego tutaj (używa MinGW, a nie Cygwin):
źródło
OK, więc oto jak w rzeczywistości wymusiłem zmianę w moich plikach Windows dotyczących samych uprawnień w Win7: Znajdź swój klucz ssh w Eksploratorze Windows: C: \ Users [twoja_nazwa_użytkownika] .ssh \ id_rsa
Kliknij prawym przyciskiem myszy plik> Właściwości> karta Zabezpieczenia> przycisk Zaawansowane> Zmień uprawnienia
Teraz usuń wszystkich, którzy tak naprawdę nie są Twoją nazwą użytkownika. Dotyczy to również Administratora i użytkowników Systemu. W tym momencie możesz uzyskać dialog na temat dziedziczenia uprawnień - wybierz opcję, która NIE dziedziczy - ponieważ chcemy tylko zmienić ten plik.
Kliknij OK i zapisz do końca.
Walczyłem z tym przez kilka dni, ponieważ moje okna nie zmieniły uprawnień do plików z linii poleceń. W ten sposób jest to faktycznie wykonywane - zamiast korzystania z ekscytujących obejść, które mogą mieć dziwne konsekwencje.
źródło
Zmiana uprawnień do plików z Właściwości, wyłączenie dziedziczenia i uruchomienie chmod 400 nie działało dla mnie. Uprawnienia do mojego pliku klucza prywatnego były następujące:
Potem zauważyłem, że grupa to None, więc po prostu pobiegłam
Następnie mogłem z powodzeniem zmienić uprawnienia za pomocą chmod 400 i uruchomić git push.
źródło
DLA UŻYTKOWNIKÓW MAC:
Zmień ustawienia pliku pary kluczy, wpisując to w terminalu:
(upewnij się, że znajdujesz się we właściwym katalogu lub poprawna nazwa pliku ścieżki w poleceniu).
źródło
Rozwiązuję to działając:
Mam nadzieję pomóc. Powodzenia.
źródło
Po tym, jak ostatnio omawiałem problem i jest to jeden z najlepszych wyników Google, pomyślałem, że skorzystam z prostego obejścia udokumentowanego w dyskusji tutaj: http://code.google.com/p/msysgit/issues/detail?id = 261 # c40
Po prostu wymaga zastąpienia pliku mysys ssh.exe programem cygwin ssh.exe
źródło
Ostatnio miałem ten sam problem na Windows XP. Próbowałem chmod 700 na moim pliku ~ / .ssh / id_rsa, ale nie działało. Kiedy spojrzałem na uprawnienia za pomocą ls -l na ~ / .ssh / id_rsa, zauważyłem, że moje efektywne uprawnienia wciąż wynosiły 644.
Potem przypomniałem sobie, że uprawnienia Windows również dziedziczą uprawnienia z folderów, a folder był nadal otwarty dla wszystkich. Rozwiązaniem mogłoby być również ustawienie uprawnień do folderu, ale myślę, że lepszym sposobem byłoby powiadomienie systemu o ignorowaniu dziedziczenia dla tego pliku. Można to zrobić za pomocą opcji zaawansowanej na karcie bezpieczeństwa we właściwościach pliku i odznaczając „dziedzicz po uprawnieniach nadrzędnych ...”
Może to być pomocne dla osób z tym samym problemem.
źródło
Gram teraz z Git 1.6.5 i nie mogę odtworzyć konfiguracji:
chmod nie modyfikuje również uprawnień do plików dla moich kluczy.
Środowisko:
Aktualizacja: Git 1.6.5.1 również działa.
źródło
Jest to szczególnie problematyczny problem w systemie Windows, gdzie nie wystarczy po prostu poprawnie przeskoczyć pliki. Musisz skonfigurować swoje środowisko.
W systemie Windows zadziałało to dla mnie:
Zainstaluj cygwin.
Zamień msysgit ssh.exe na ssh.exe cygwina.
Używając cygwin bash, chmod 600 plik klucza prywatnego, który był dla mnie „id_rsa”.
Jeśli nadal nie działa, przejdź do Panelu sterowania -> Właściwości systemu -> Zaawansowane -> Zmienne środowiskowe i dodaj następującą zmienną środowiskową. Następnie powtórz krok 3.
Wartość zmiennej
CYGWIN sbmntsec
źródło
Udało mi się to naprawić, wykonując dwie czynności, chociaż może nie być konieczne wykonanie kroku 1.
skopiuj z cygwin ssh.exe i całą cyg * .dll do katalogu bin Gita (może to nie być konieczne, ale zrobiłem krok, ale to samo nie naprawiło)
postępuj zgodnie z instrukcjami z: http://zylstra.wordpress.com/2008/08/29/overcome-herokus-permission-denied-publickey-problem/
Dodałem kilka szczegółów do mojego pliku ~ / .ssh / config:
Host heroku.com
Nazwa hosta heroku.com
Port 22
Tożsamości Tylko tak
IdentityFile ~ / .ssh / id_heroku
TCPKeepAlive tak Brandon
użytkownika
Musiałem użyć użytkownika jako mojego adresu e-mail dla heroku.com Uwaga: oznacza to, że musisz utworzyć klucz, wykonałem to, aby utworzyć klucz, a gdy pojawi się monit o nazwę klucza, pamiętaj, aby podać id_heroku http: / /help.github.com/win-set-up-git/
heroku keys: add ~ / .ssh / id_heroku.pub
źródło
Dla mnie sztuczka polegała na zaktualizowaniu zmiennej środowiskowej CYGWIN za pomocą: „ tty nodosfilewarning ”. Nie musiałem nawet przesuwać klucza.
źródło
Nie jest to bezpośrednia odpowiedź na podstawowe pytanie, ale na twoje pytanie, jak działa folder cygwin ... Zasadniczo cygwin umieszcza wszystkie „twoje” pliki pod odpowiednikiem c: \ cygwin \ home \ nazwa użytkownika. Traktuje ten folder dla dowolnych ustawień użytkownika, a nie dla katalogu użytkownika systemu Windows.
źródło
O ile nie istnieje powód, dla którego chcesz zachować tę parę kluczy prywatny / publiczny (id_rsa / id_rsa.pub) lub cieszyć się waleniem głową w ścianę, zalecam po prostu ich odtworzenie i aktualizację klucza publicznego na github.
Zacznij od wykonania kopii zapasowej katalogu ~ / .ssh.
Wpisz następujące i odpowiedz „y”, czy chcesz nadpisać istniejące pliki.
Skopiuj zawartość klucza publicznego do schowka. (Poniżej pokazano, jak należy to zrobić na komputerze Mac).
Przejdź do swojego konta na github i dodaj ten klucz.
Wyjdź z terminala i uruchom ponownie nowy.
Jeśli otrzymujesz bezsensowne komunikaty o błędach, takie jak „Wprowadź hasło” dla klucza publicznego, gdy nigdy go nie wprowadziłeś, zastanów się nad tym od początku. Jak widać powyżej, nie jest to skomplikowane.
źródło
Nigdy nie udało mi się sprawić, by git działał całkowicie w Powershell. Ale w powłoce git bash nie miałem żadnych problemów związanych z uprawnieniami i nie musiałem ustawiać chmod itp. Po dodaniu ssh do Github byłem gotowy do pracy.
źródło
Wpisz na terminalu:
I spróbuj ponownie.
źródło
Czy skopiowałeś plik klucza z innego komputera?
Właśnie stworzyłem
id_rsa
plik na komputerze klienckim, a następnie wkleiłem klucz, który chciałem. Brak problemów z uprawnieniami. Nic do ustawienia. Po prostu zadziałało. Działa również, jeśli używasz PuTTYgen do utworzenia klucza prywatnego.Prawdopodobnie jakiś problem z ukrytą grupą, jeśli kopiujesz go z innego komputera.
Testowany na dwóch komputerach z systemem Windows 8.1. Za pomocą Sublime Text 3 skopiuj i wklej klucz prywatny. Korzystanie z Git Bash (Git-1.9.4-Preview20140611).
źródło
Po uaktualnieniu mojej instalacji Cygwin do wersji około lutego 2015 r. (
1.7.34(0.285/5/3) 2015-02-04 12:14 x86_64 Cygwin
) Nagle natknąłem się naUNPROTECTED PRIVATE KEY FILE
ostrzeżenie.Rozwiązałem ten problem po uruchomieniu następującego polecenia:
( inna odpowiedź na inne pytanie daje więcej kontekstu)
źródło
Odpowiedź @ Koby nie działa dla mnie, więc dokonuję niewielkiej zmiany.
To działa dobrze dla mnie na komputerze Mac.
źródło
Miałem ten sam problem w systemie Windows 10, gdy próbowałem SSH do Vagrant box. To wydaje się być błędem w starej wersji OpenSSH. Co dla mnie zadziałało:
(Uwaga: „.exe”, jeśli używasz programu PowerShell)
Możesz zobaczyć coś takiego:
Zauważ, że w powyższym przykładzie najnowsza wersja OpenSSH jest druga na ścieżce, więc nie będzie działać.
Aby zmienić kolejność:
źródło
W moim systemie jest trochę bałaganu z bash / cygwin / git / msysgit / może-więcej ...
chmod
nie miał wpływu na klucz ani naconfig
plik.Potem zdecydowałem się podejść do tego z Windows, który działał.
Properties
.Security
zakładkę.Advanced
pobliżu dołu.Change
, obokOwner
góry.Check Names
następnie kliknij , a następnieOK
.Permission entries:
podświetl każdego użytkownika, który nie jest „My-Awesome-Username”, i wybierzRemove
. Powtarzaj tę czynność, dopóki nie pozostanie tylko „My-Awesome-Username”.Edit
poniżej.Type:
u góry jest ustawiona opcjaAllow
, a następnie zaznacz pole wyboru obokFull control
.Hit
OK
,Apply
,OK
,OK
.Spróbuj teraz jeszcze raz ...
Wydaje się, że czasami próbny bash nie może kontrolować własności pliku. Jest to szczególnie dziwne, ponieważ jest generowane ze skryptu próbnego. Domyśl.
źródło
Żadne z sugerowanych tutaj obejść (chmod / chgrp / setfacl / windows perms) nie działało dla mnie z msys64 na korporacyjnej maszynie wirtualnej z systemem Windows 7. W końcu obejrzałem ten problem, używając agenta ssh z kluczem podanym na stdin. Dodanie tego do mojego
.bash_profile
powoduje, że jest to domyślny login:Teraz mogę wykonywać polecenia git push i pull za pomocą pilotów ssh.
źródło