Uprawnienia klucza prywatnego SSH przy użyciu Git GUI lub ssh-keygen są zbyt otwarte

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?

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

cd ~/.ssh
chmod 700 id_rsa

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.

Wystąpił błąd w chmod cygwina, patrz:

/superuser/397288/using-cygwin-in-windows-8-chmod-600-does-not-work-as-expected

chgrp -Rv Users ~/.ssh/* 
chmod -vR 600 ~/.ssh/id_rsa

W systemach * nix oczywistą poprawką jest chmod 600 id_rsaOFC, 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.

Mam XP, co pozwoliło Git Bash na komunikację z Githubem (po dużej frustracji):

1. skopiuj c:\cygwin\bin\cyg*(~ 50 plików) doc:\Program Files\Git\bin\
2. kopiuj c:\cygwin\bin\ssh.exedo c:\Program Files\Git\bin\(nadpisywanie)

3. Utwórz plik c:\Documents and Settings\<username>\.ssh\configzawierający:

   Host github.com
       User git
       Hostname github.com
       PreferredAuthentications publickey
       IdentityFile "/cygdrive/c/Documents and Settings/<username>/.ssh/id_rsa"
   

4. (opcjonalnie) Użyj, ssh -v git@githubaby zobaczyć połączenie debugowane.

5. Spróbuj push!

Tło: Ogólny problem stanowi połączenie tych dwóch:

• BŁĄD: mingw32 widzi wszystkie pliki jako 644 (inne / możliwe do odczytania przez grupę) i nic, co próbowałem w mingw32, cygwin lub Windows, nie mogłoby tego naprawić.
• Wersja SSH mingw32 nie zezwala na to dla kluczy prywatnych (ogólnie dobra polityka na serwerze).

W systemie Windows 7 za pomocą Git znalezionego tutaj (używa MinGW, a nie Cygwin):

1. W Eksploratorze Windows kliknij prawym przyciskiem myszy plik id_rsa i wybierz Właściwości
2. Wybierz kartę Zabezpieczenia i kliknij Edytuj ...
3. Zaznacz pole Odmów obok Pełna kontrola dla wszystkich grup Z WYJĄTKIEM administratorów
4. Ponów polecenie Git

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.

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:

-r - r ----- 1 alex Brak 1766 8 marca 13:04 /home/alex/.ssh/id_rsa

Potem zauważyłem, że grupa to None, więc po prostu pobiegłam

chown alex: Administrators ~ / .ssh / id_rsa

Następnie mogłem z powodzeniem zmienić uprawnienia za pomocą chmod 400 i uruchomić git push.

DLA UŻYTKOWNIKÓW MAC:

Zmień ustawienia pliku pary kluczy, wpisując to w terminalu:

chmod og-r *filename.pem*

(upewnij się, że znajdujesz się we właściwym katalogu lub poprawna nazwa pliku ścieżki w poleceniu).

Rozwiązuję to działając:

chmod 400 ~/.ssh/id_rsa

Mam nadzieję pomóc. Powodzenia.

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

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.

Gram teraz z Git 1.6.5 i nie mogę odtworzyć konfiguracji:

Administrator@WS2008 /k/git
$ ll ~/.ssh
total 8
drwxr-xr-x    2 Administ Administ     4096 Oct 13 22:04 ./
drwxr-xr-x    6 Administ Administ     4096 Oct  6 21:36 ../
-rw-r--r--    1 Administ Administ        0 Oct 13 22:04 c.txt
-rw-r--r--    1 Administ Administ      403 Sep 30 22:36 config_disabled
-rw-r--r--    1 Administ Administ      887 Aug 30 16:33 id_rsa
-rw-r--r--    1 Administ Administ      226 Aug 30 16:34 id_rsa.pub
-rw-r--r--    1 Administ Administ      843 Aug 30 16:32 id_rsa_putty.ppk
-rw-r--r--    1 Administ Administ      294 Aug 30 16:33 id_rsa_putty.pub
-rw-r--r--    1 Administ Administ     1626 Sep 30 22:49 known_hosts

Administrator@WS2008 /k/git
$ git clone git@github.com:alexandrul/gitbook.git
Initialized empty Git repository in k:/git/gitbook/.git/
remote: Counting objects: 1152, done.
remote: Compressing objects: 100% (625/625), done.
remote: Total 1152 (delta 438), reused 1056 (delta 383)s
Receiving objects: 100% (1152/1152), 1.31 MiB | 78 KiB/s, done.
Resolving deltas: 100% (438/438), done.

Administrator@WS2008 /k/git
$ ssh git@github.com
ERROR: Hi alexandrul! You've successfully authenticated, but GitHub does not pro
vide shell access
Connection to github.com closed.

$ ssh -v
OpenSSH_4.6p1, OpenSSL 0.9.8e 23 Feb 2007

chmod nie modyfikuje również uprawnień do plików dla moich kluczy.

Środowisko:

• Windows Server 2008 SP2 w systemie plików NTFS
• użytkownik: administrator
• zmienne środowiskowe:
  • PLINK_PROTOCOL = ssh
  • HOME = / c / profile / home

Aktualizacja: Git 1.6.5.1 również działa.

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:

1. Zainstaluj cygwin.

2. Zamień msysgit ssh.exe na ssh.exe cygwina.

3. Używając cygwin bash, chmod 600 plik klucza prywatnego, który był dla mnie „id_rsa”.

4. 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

Udało mi się to naprawić, wykonując dwie czynności, chociaż może nie być konieczne wykonanie kroku 1.

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)

2. 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/

1. następnie dodaj klucz:
   heroku keys: add ~ / .ssh / id_heroku.pub

Dla mnie sztuczka polegała na zaktualizowaniu zmiennej środowiskowej CYGWIN za pomocą: „ tty nodosfilewarning ”. Nie musiałem nawet przesuwać klucza.

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.

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.

ssh-keygen -t rsa

Skopiuj zawartość klucza publicznego do schowka. (Poniżej pokazano, jak należy to zrobić na komputerze Mac).

cat ~/.ssh/id_rsa.pub | pbcopy

Przejdź do swojego konta na github i dodaj ten klucz.

Name: My new public key
Key: <PASTE>

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.

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.

Wpisz na terminalu:

chmod -Rf 700 ~/.ssh/

I spróbuj ponownie.

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).

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ę na UNPROTECTED PRIVATE KEY FILEostrzeżenie.

Rozwiązałem ten problem po uruchomieniu następującego polecenia:

setfacl -s u::rw-,g::---,o:--- ~/.ssh/id_rsa

( inna odpowiedź na inne pytanie daje więcej kontekstu)

Odpowiedź @ Koby nie działa dla mnie, więc dokonuję niewielkiej zmiany.

cd ~/.ssh
chmod 700 id_rsa.pub

To działa dobrze dla mnie na komputerze Mac.

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:

1. Zainstaluj najnowszą wersję OpenSSH ze strony http://www.mls-software.com/opensshd.html
2. where.exe ssh

(Uwaga: „.exe”, jeśli używasz programu PowerShell)

Możesz zobaczyć coś takiego:

C:\Windows\System32\OpenSSH\ssh.exe
C:\Program Files\OpenSSH\bin\ssh.exe
C:\opscode\chefdk\embedded\git\usr\bin\ssh.exe

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ść:

1. Kliknij prawym przyciskiem myszy przycisk Windows -> Ustawienia -> „Edytuj zmienne środowiska systemowego”
2. Na karcie „Advance” kliknij „Zmienne środowiskowe ...”
3. W obszarze Zmienne systemowe edytuj „Ścieżka”.
4. Wybierz „C: \ Program Files \ OpenSSH \ bin” i „Przenieś w górę”, aby pojawił się na górze.
5. Kliknij OK
6. Uruchom ponownie konsolę, aby zastosować nowe zmienne środowiskowe.

W moim systemie jest trochę bałaganu z bash / cygwin / git / msysgit / może-więcej ...

chmodnie miał wpływu na klucz ani na configplik.

Potem zdecydowałem się podejść do tego z Windows, który działał.

1. Kliknij prawym przyciskiem myszy plik, którego uprawnienia wymagają naprawy.
2. Wybierz Properties.
3. Wybierz Securityzakładkę.
4. Kliknij w Advancedpobliżu dołu.
5. Kliknij Change, obok Ownergóry.
6. Wpisz „My-Awesome-Username” (oczywiście zmień ją na obecną nazwę użytkownika systemu Windows), a Check Namesnastępnie kliknij , a następnie OK.
7. W obszarze Permission entries:podświetl każdego użytkownika, który nie jest „My-Awesome-Username”, i wybierz Remove. Powtarzaj tę czynność, dopóki nie pozostanie tylko „My-Awesome-Username”.
8. Wybierz „My-Awesome-Username” i kliknij Editponiżej.
9. Upewnij się, że Type:u góry jest ustawiona opcja Allow, a następnie zaznacz pole wyboru obokFull control .

10. Hit OK, Apply, OK,OK .

11. 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.

Ż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_profilepowoduje, że jest to domyślny login:

eval $(ssh-agent -s)
cat ~/.ssh/id_rsa | ssh-add -k -

Teraz mogę wykonywać polecenia git push i pull za pomocą pilotów ssh.