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

244

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?

Ben Scheirman
źródło
1
Możesz nam powiedzieć, z jakiego rodzimego systemu plików korzysta C: \ Users \ Ben \. Wygląda na to, że system plików nie obsługuje rzeczywistych uprawnień lub mapowania między powłoką a systemem plików nie działają poprawnie. Czy możesz zmienić uprawnienia za pomocą list kontroli dostępu systemu Windows?
Chen Levy,
Korzystam z systemu Windows 7. Mogę zmienić uprawnienia do tego, ale jakie to powinny być? Wszystkie dokumenty github / ssh mówią, że potrzebujesz 0600, ale nie mam pojęcia, co to oznacza w listach ACL systemu Windows.
Ben Scheirman,
2
Uh ... trochę sidenote tu, ale przeskakiwanie do katalogu na 600 to zły pomysł. Katalogi (i pliki wykonywalne) są zawsze o jedną cyfrę wyższe (700 nie 600, 755 nie 644). Wykonanie tego w katalogu spowoduje, że będzie on niepubliczny. Zobacz dartmouth.edu/~rc/help/faq/permissions.html do bardziej szczegółowych wyjaśnień.
Mark Embling
Czy jesteś przeciwny używaniu PuTTY?
Greg Bacon
jeśli to rozwiąże mój problem, to nie, ale jestem ciekawy, dlaczego ta konfiguracja nie działa dla mnie.
Ben Scheirman

Odpowiedzi:

361

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.

Koby
źródło
2
Ta odpowiedź dotyczy w szczególności używania cygwin lub msysgit (ponieważ msysgit używa podzbioru cygwin lub ewentualnie mingw32). Problemem jest pozwolenie na plik. Git lubi pracować z (głównie) uprawnieniami do Linuksa (prawdopodobnie produktem ubocznym grupy docelowej). Korzystanie z git.exe w powłoce Winodws jest znane z problemów, radziłbym trzymać się msysgit. Przynajmniej dopóki GitSharp nie będzie w pełni działał.
Koby
2
Nie działa to na Windowsie 8 i mojej instalacji cygwina z Jan'14, ponieważ po chmod 700 pokazuje plik jako rwxrwx ---. Uprawnienia grupy, które mają być ustawione na cokolwiek, na co ustawiłem uprawnienia użytkownika i nie mogę używać moich kluczy.
Dean Hiller
1
@DeanHiller, powinno wyglądać pozwolenie 700 -rwx------. Więc to, co wyświetlasz, nie jest poprawne, jeśli poprawnie wykonałeś komendę chmod.
Koby
5
@Koby nie, to był błąd związany z pracą ... muszę użyć chgrp -R Users ~ / .ssh, a następnie chmod teraz działa i faktycznie poprawnie zmienia uprawnienia ..... znany błąd, który w końcu znalazłem inny post.
Dean Hiller
2
Mogę sprawdzić, czy istnieje jakiś błąd w GitBash dla Windows, w którym albo NIE można ustawić poprawnych uprawnień za pomocą chmod, albo uprawnienia nie są poprawnie odczytane. chmod 600 id_rsd; ls -l id_rs -> -rwx-r - r--
Charlweed
74

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
kittikun
źródło
Z jakiegokolwiek powodu mapowanie uprawnień systemu Windows na uprawnienia podobne do cygwin / * nix jest nieco rozmyte. Mimo że usunąłem uprawnienia wszystkich innych użytkowników po stronie Windows, cygwin nadal zastosował je dla mnie, użytkownika , do innej grupy o nazwie None. (Przypuszczam, że jest to standardowa procedura, gdy grupa nie została wyraźnie zdefiniowana). Ta zmiana na jawną grupę Usersrzekomo pozwoliła cygwinowi rozdzielić uprawnienia, i mogłam w końcu ustawić 600 zamiast automatycznego 660.
t-mart
3
To jest prawdziwa poprawna odpowiedź. Ten, który został głosowany jako poprawna odpowiedź - myślę, że ludzie, którzy głosowali na to, byli użytkownikami Linuksa i nie zdawali sobie sprawy, że poprawnie wykonywał polecenie. Miałem dzisiaj ten sam problem z cygwinem. Dzięki!
michaelday
Przed zastosowaniem tego rozwiązania, kiedy użyłem chmod 600git, narzekałem, że moje uprawnienia były nadal 0660. Naprawienie własności grupy powoduje, że chown ma zastosowanie poprawnie.
Guilherme Rodrigues,
1
Zaktualizowałem Cygwin i zadziałało. Musieli naprawić błąd.
Duncan Calvert,
17

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.

Tuncay Göncüoğlu
źródło
3
To nie działało dla mnie. Nadal pojawia się komunikat „NIEBEZPIECZNY PLIK KLUCZA PRYWATNEGO”. Chciałem tylko poinformować Cię na wypadek, gdyby ktoś napotkał ten wątek z podobnymi wynikami.
Luc
Pracował dla mnie. To jest jednak dziwne. Już nawet nie używam Cygwina. Poza tym, jak do cholery to rozgryzłeś?
gamut
13

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).
Steve Clay
źródło
Szwy nie trzeba nadrobić plik c:\Documents and Settings\<username>\.ssh\configponieważ zostały zastąpione c:\Program Files\Git\bin\ssh.exe z c:\cygwin\bin\ssh.exe. Dobrze ?
爱国者
Zgadzam się z komentarzem „dużo frustracji”. W przypadku gitolitu wykonałem następujące kroki, kopiując cygwin / bin / cyg * do mojego katalogu Git (PortableGit - lub - Program Files / Git) i stwierdziłem, że mogę wtedy użyć git z Git-Bash, ale nie cygwin bash. Dodanie katalogów bin PortableGit i Cygwin do mojej PATH również działało z ograniczonym sukcesem ... ale nadal musiałem przenieść PortableGit / bin / ssh.exe {,. Bak}, aby nie został przypadkowo użyty (nawet jeśli jest to taki sam jak c: /cygwin/bin/ssh.exe). Zasadniczo ssh.exe należy uruchomić z katalogu cygwin z powodu innych zależności, które nie zostały skopiowane.
Michael
Chociaż teraz działa dla mnie, następną próbą byłoby dodanie GIT i Cygwina do PATH i przeniesienie ssh.exe Gita na bok, aby użyć ssh.exe cygwina (z katalogu bin cygwina).
Michael
Dodaj LogLevel DEBUGdo pliku .ssh \ config, aby uzyskać dane wyjściowe debugowania z procesu ssh.exe uruchomionego przez git.exe.
knb
Dzięki - to rozwiązanie zadziałało dla mnie! W szczególności z c: \ cygwin \ bin \ skopiowałem ssh.exe, cygcrypto-0.9.8.dll, cygwin1.dll, cygminires.dll i cygz.dll do C: \ Program Files \ Git \ bin \.
nexus-bytes
10

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
Brett Pennings
źródło
1
To było dla mnie, ale teraz mam nowy problem, że ssh nie lubi mojego hasła, żadnego hasła, które podam mój plik klucza.
Jason Southwell,
7

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.

diannaL
źródło
6

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.

alex.m
źródło
4

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

Andrzej
źródło
3

Rozwiązuję to działając:

chmod 400 ~/.ssh/id_rsa

Mam nadzieję pomóc. Powodzenia.

CristianOrellanaBak
źródło
1
Zmiana uprawnień na 400, jak wspomniał Cristian, byłaby bezpieczniejsza.
SylvesterAbreuLoreto,
2

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

chriskhan
źródło
2

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.

daramarak
źródło
1

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 [email protected]: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 [email protected]
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.

alexandrul
źródło
ciekawy. Wygląda na to, że używasz opcji kitu?
Ben Scheirman
1

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

Michael Bosworth
źródło
1

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
Christy Hotney
źródło
1

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

tohokami
źródło
0

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.

J Wynia
źródło
0

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.

l3x
źródło
0

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.

Sam Kenny
źródło
0

Wpisz na terminalu:

chmod -Rf 700 ~/.ssh/

I spróbuj ponownie.

João Paulo Cercal
źródło
0

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

PhilT
źródło
0

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)

Abdull
źródło
0

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.

Han Pengbo
źródło
0

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.
Jasper Citi
źródło
0

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.

Jack_Hu
źródło
0

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

Andy Brown
źródło